Very interesting, thanks for the feedback! Let me see whether I got it: 1. All statements below refer to Java 1.5.
2. fieldX = new SomeType(zzz) - This is thread-safe if SomeType is immutable. An immutable object features: - unmodifiable state - all fields are final and all fields hold immutable objects - proper construction: "this" is not escaped in the constructor. - LocatorFactoryImplEx is an immutable object 3. Construction and assigning different instances of LocatorFactoryImplEx() to locatorFactory is allowed 4. Running Jackrabbit under Java 1.4 has got threading issues because of the revised final as mentioned above. 5. > Actually, this internal field is the source of a potential data race: thread > A runs up to the point, when it has constructed LocatorFactoryImplEx but has > not yet assigned the internal field. Thread A gets on hold relative to > thread B. B runs through the getter and sees that locatorFactory is not > null, fetches the object, access the uninitialized internal field and voilà! > We have a mess. This is wrong for immutable objects like LocatorFactoryImplEx(). It only applies to mutable objects. Can I suggest to add a note in the doc that all those classes need to be immutable? Next, I gonna learn why the mutable resourceConfig in SimpleWebDavServlet.getResourceFactory() is fine for multiple threads... Marc
