If I create a “Plugin Project” in Eclipse, it creates a default BundleActivator implementation that just sets the BundleContext in an unsynchronized static field.
Since it also creates a public static getter, this doesn’t look Thread-safe, because even if OSGi performs some synchronization when calling the Activator, how do I know that any of my code which would call the getter would also run inside the same synchronization block?
In a “normal” context, both the getters and setters need to be synchronized, or we must use a volatile, to be sure that whatever Thread calls the getter later actually sees the current state of the static field.
If the field was set only once, it would not be a problem, but I understand that bundles can be started and stopped several times during the lifetime of the JVM, and under those conditions, it would be thinkable that a Thread has already a cached version of the field, and would not see a change, due to the lack of synchronization.
I can’t imagine that Eclipse would generate plain wrong code by default, but I can’t see how this would work either.
I agree that the generated code is incorrect and it doesn’t surprise me at all that Eclipse PDE would generated incorrect code. There is no need for this static field, and in fact in most cases the activator itself is useless.