On 10 Jan 2013, at 13:19, Kristian Rosenvold wrote: > 2013/1/10 Stuart McCulloch <[email protected]>: >> There's no guarantee that Plexus field injection will be synchronized, so if >> you're constructing an object in one thread and immediately handing it off >> to another >thread without any intervening synchronization then you should >> use volatile fields or ideally introduce a synchronized setter+getter in the >> outermost object. But even >without injection you'd want to do this if you >> were setting values in one thread and wanting another thread to see them. > > Ok, this means all the @plexus.requirement fields in wagon should be > volatile or similar. > >> One benefit of JSR330 is that you can use constructor injection along with >> final fields which avoids this kind of thread-visibility issue, since they >> are frozen and made > visible to other threads when the constructor >> completes. > > Constructor injection is king; too bad we can't have that and maven > 2.2.1 compatibility...?
Not unless we migrate maven2 over to the new container - but you could always introduce some sort of factory/clone step into the wagon code that constructed a new object for the other thread from the injected fields. >> PS. you can actually mark a private field as final and still have it >> injected, because the reflection code uses "setAccessible" to break through >> the encapsulation and >this also overrides the 'final-ness' as described in >> http://jeremymanson.blogspot.co.uk/2008/07/immutability-in-java-part-3.html >> while still preserving the thread->visibility effect of final - but this is >> not recommended as it obscures the actual intent. > > In one way kind of neat; since the statement has "both" > @plexus.requirement and final it's fairly obvious who sets it; > although the semantics are definitely not java101 ;) Do you know if > this works with old plexus too ? (2.2.1) It should also work with old Plexus, as that also uses setAccessible to break encapsulation - I seem to remember seeing some Plexus requirements that were already marked final --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
