|Re: JDT throws ClassNotFoundException while instantiating ExecutableExtensionFactory [message #1720177 is a reply to message #1720160]
||Thu, 14 January 2016 22:11
| Erick Hagstrom
Registered: April 2014
Theory: it's a race condition.|
Scenario A: My plug-in activates before org.eclipse.jdt.core. My Activator needs SharedStatusModule from org.eclipse.xtext.ui.shared and loads it. There's no need to access org.eclipse.xtext.ui from .shared, so that optional dependency is dropped/ignored. Later, org.eclipse.jdt.core activates and creates CompilationParticipants. It finds org.eclipse.xtext.ui.shared, tries to make a ExecutableExtensionFactory, finds no BundleWire (or whatever it should be at that point) representing org.eclipse.xtext.ui so never looks there, eventually finds no AbstractGuiceAwareExecutableExtensionFactory, and fails. That's my original scenario.
Scenario B: org.eclipse.jdt.core activates before my plug-in and starts instantiating CompilationParticipants. It tries to create org.eclipse.xtext.ui.shared.internal.ExecutableExtensionFactory, recognizes that the dependency on org.ecliplse.xtext.ui is necessary, so it looks there, finds AbstractGuiceAwareExecutableExtensionFactory, and successfully creates everything. Later, my plug-in activates, looks for SharedStateModule, finds it, and they all execute happily ever after.
The only thing that happened when I added an additional type between my Factory and the AbstractGuiceAware one was to make my activation take just a beat longer, giving org.eclipse.jdt.core a chance to get to org.eclipse.xtext.ui.shared before I did. Or, if there's no multi-threading in there, it did nothing and I'm going to have intermittent problems with this depending on solar flares, phases of the moon, and whether a butterfly in Munich sneezes once or twice.
So, again, probably not your bug/issue. But does it sound plausible, if not necessarily reproducible? Where do I file it? (Bugzilla, yeah, but which product etc.?)
Powered by FUDForum
. Page generated in 0.01431 seconds