Community
Participate
Working Groups
We have a pseudo-headless Eclipse application which we use to compile some XText/Java code *without* starting workbench, but with the full set of IDE plugins. Not something one would recommend to do, but creating a really headless XText based application is too expensive. So we fake the Display instance and that works pretty good. We've just noticed, that even if we don't want to start PDE UI, it is initialized indirectly from JDT core because org.eclipse.pde.ds.annotations contributes DSAnnotationCompilationParticipant and at same time depends on org.eclipse.pde.ui, so as soon as JDT reads the CompilationParticipant extension, it triggers PDE UI load and this happens *not* on the UI thread in that case. I assume in the default IDE startup this shouldn't happen, but who knows. If this happens, the org.eclipse.pde.internal.ui.editor.text.ColorManager will not initialize "high contrast" preference properly (only supported on Windows). Stack: at Display.getHighContrast() at org.eclipse.pde.internal.ui.editor.text.ColorManager.initializeDefaults(ColorManager.java:50) at org.eclipse.pde.internal.ui.preferences.PreferenceInitializer.initializeDefaultPreferences(PreferenceInitializer.java:28) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper$1.run(PreferenceServiceRegistryHelper.java:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.runInitializer(PreferenceServiceRegistryHelper.java:304) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:134) at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:375) at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:225) at org.eclipse.core.internal.preferences.DefaultPreferences.load(DefaultPreferences.java:279) at org.eclipse.core.internal.preferences.EclipsePreferences.create(EclipsePreferences.java:370) at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:623) at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:766) at org.eclipse.core.internal.preferences.AbstractScope.getNode(AbstractScope.java:41) at org.eclipse.core.runtime.preferences.DefaultScope.getNode(DefaultScope.java:77) at org.eclipse.pde.internal.core.PDEPreferencesManager.<init>(PDEPreferencesManager.java:37) at org.eclipse.pde.internal.ui.PDEPlugin.getPreferenceManager(PDEPlugin.java:69) at org.eclipse.pde.internal.ui.shared.target.TargetStatus.initializeTargetStatus(TargetStatus.java:188) at org.eclipse.pde.internal.ui.PDEPlugin.start(PDEPlugin.java:210) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:782) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:775) at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732) at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005) at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357) at org.eclipse.osgi.container.Module.doStart(Module.java:584) at org.eclipse.osgi.container.Module.start(Module.java:452) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:471) at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:557) at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:331) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:39) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:190) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:934) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:246) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:63) at org.eclipse.jdt.internal.core.JavaModelManager$CompilationParticipants$1.run(JavaModelManager.java:466) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.jdt.internal.core.JavaModelManager$CompilationParticipants.getCompilationParticipants(JavaModelManager.java:459) at org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java:608) at org.eclipse.jdt.internal.core.builder.JavaBuilder.clean(JavaBuilder.java:301) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:843) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:228) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:271) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:324) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:327) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:379) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:400) at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:504) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:404)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/171793
The problem is a bit different: it executes the runnable with access to `Display.getHighContrast()` directly, without using Display.*Exec
*** This bug has been marked as a duplicate of bug 546205 ***
