Community
Participate
Working Groups
M2. I've just been getting some wierd grey screens in a Java editor, on one occasion with working left hand annotations. The error log shows that (my) Xtext editor has been activated from within a JDT editor. Hopefully the stack trace can identify why this profligacy has occurred. (My editor was not open at the time.) It seems to me that under the normal Eclipse lazy paradigm, the plugins for editor X should not be loaded until a corresponding edit starts; certainly not to perform hover decorations in editor Y. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NoClassDefFoundError: org/eclipse/qvtd/xtext/qvtimperative/QVTimperativeRuntimeModule) at org.eclipse.swt.SWT.error(SWT.java:4419) at org.eclipse.swt.SWT.error(SWT.java:4334) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:139) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4145) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3762) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:144) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:613) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Caused by: java.lang.NoClassDefFoundError: org/eclipse/qvtd/xtext/qvtimperative/QVTimperativeRuntimeModule at org.eclipse.qvtd.xtext.qvtimperative.ui.internal.QVTimperativeActivator.getRuntimeModule(QVTimperativeActivator.java:77) at org.eclipse.qvtd.xtext.qvtimperative.ui.internal.QVTimperativeActivator.createInjector(QVTimperativeActivator.java:63) at org.eclipse.qvtd.xtext.qvtimperative.ui.internal.QVTimperativeActivator.getInjector(QVTimperativeActivator.java:55) at org.eclipse.qvtd.xtext.qvtimperative.ui.QVTimperativeExecutableExtensionFactory.getInjector(QVTimperativeExecutableExtensionFactory.java:26) at org.eclipse.xtext.ui.guice.AbstractGuiceAwareExecutableExtensionFactory.create(AbstractGuiceAwareExecutableExtensionFactory.java:49) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:262) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.ide.registry.MarkerHelpRegistry.hasResolution(MarkerHelpRegistry.java:184) at org.eclipse.ui.internal.ide.registry.MarkerHelpRegistry.hasResolutions(MarkerHelpRegistry.java:160) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.hasCorrections(JavaCorrectionProcessor.java:146) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.hasCorrections(JavaCorrectionProcessor.java:136) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.canFix(JavaCorrectionProcessor.java:526) at org.eclipse.jface.text.quickassist.QuickAssistAssistant.canFix(QuickAssistAssistant.java:151) at org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess.hasQuickFix(DefaultMarkerAnnotationAccess.java:442) at org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess.getImage(DefaultMarkerAnnotationAccess.java:396) at org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess.paint(DefaultMarkerAnnotationAccess.java:264) at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint1(AnnotationRulerColumn.java:790) at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:541) at org.eclipse.jface.text.source.AnnotationRulerColumn.redraw(AnnotationRulerColumn.java:824) at org.eclipse.jface.text.source.AnnotationRulerColumn$6.run(AnnotationRulerColumn.java:807) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) ... 24 more
JDT supports various means to extend it. One being able to provide quick fixes for markers. If you declare a marker resolution generator in your plugin.xml without a markerType then that plugin will be activated, to check whether you have a resolution fro JDT markers. Please check your plugin.xml for "org.eclipse.ui.ide.markerResolution". It should have the markerTypes specified: E.g. for Xtend it looks like this : <extension point="org.eclipse.ui.ide.markerResolution"> <markerResolutionGenerator class="org.eclipse.xtend.ide.XtendExecutableExtensionFactory:org.eclipse.xtext.ui.editor.quickfix.MarkerResolutionGenerator" markerType="org.eclipse.xtend.ide.xtend.check.fast"> <attribute name="FIXABLE_KEY" value="true"> </attribute> </markerResolutionGenerator> <markerResolutionGenerator class="org.eclipse.xtend.ide.XtendExecutableExtensionFactory:org.eclipse.xtext.ui.editor.quickfix.MarkerResolutionGenerator" markerType="org.eclipse.xtend.ide.xtend.check.normal"> <attribute name="FIXABLE_KEY" value="true"> </attribute> </markerResolutionGenerator> <markerResolutionGenerator class="org.eclipse.xtend.ide.XtendExecutableExtensionFactory:org.eclipse.xtext.ui.editor.quickfix.MarkerResolutionGenerator" markerType="org.eclipse.xtend.ide.xtend.check.expensive"> <attribute name="FIXABLE_KEY" value="true"> </attribute> </markerResolutionGenerator> </extension>
Spot on. My plugin.xml has not been updated to track the new style that I see in plugin.xml_gen. Thanks. But. If plugin.xml as generated by an earlier Xtext is buggy, shouldn't the relevant plugin.xml fragment generator diagnose that the bad old style is in use? Or shouldn't there be a lightweight Xtext nature/builder that validates the MANIFEST.MF and plugin.xml for undesirable characteristics/xx_gen content that has not been incorporated. NB the UI plugin does not currently need the full Xtext plugin. Or perhaps this should be a warning from the JDT nature/builder.
The description is not buggy. It's just that it is not exclusive enough, to avoid unnecessary plugin activation :-) It isn't a big issues as the plug-in will usually be activated anyway eventually and also usually it doesn't quit with NoClassDefFoundErrors.
Bug 420431 sheds some more insight. java.lang.NoClassDefFoundError: org/eclipse/qvtd/xtext/qvtimperative/QVTimperativeRuntimeModule was a poor diagnosis of an inherited API breakage. However, the surprising activation of 'old-style' Xtext editors to 'help' JDT cannot be improving performance at all. OCL was contributing 5, and QVTd 4 'bad' editors. So whenever JDT allows 'help' there are nine plugin hierarchies to activate first time, and nine useless overheads each time. This might explain Bug 415284, where Papyrus is probably directly contributing more old-style Xtext editors, in addition to bad OCL ones. This is potentially a major scalability problem as Xtext gets more popular.
It doesn't happen with newer Xtext languages anymore. But if you really think we need a warning for this, it clearly belongs to used extension point. That is 'org.eclipse.ui.ide.markerResolution' should warn when contributions don't specify a markerType.
(In reply to Sven Efftinge from comment #5) > That is 'org.eclipse.ui.ide.markerResolution' should warn when contributions > don't specify a markerType. Bug 420439 raised.
Requested via bug 522520. -M.
