Community
Participate
Working Groups
Created attachment 263596 [details] screenshot #1, workspace settings correct We have a standard Java project working under Eclipse. There are no plugins installed, just the basic "Java devel stuff" Eclipse package. There is no Maven or other special build tool involved; the "real" build is more complicated and happens elsewhere, Eclipse is just used as a convenient and useful development environment for part of the project. Nearly all settings are managed at the workspace level. Only one project-specific setting existed, and everything worked fine. Then we tried turning off the project-specific override. Everything still worked fine. Then we exited Eclipse, and nothing has worked since. Attachment #1 [details] (ebug_workspace_compliance) shows the workspace's Java -> Compiler screen. Everything is correct, including source = 1.8 and compliance = 1.8. It's not shown, but the "Installed JREs" correctly default to the JavaSE-1.8 Standard VM. Attachment #2 [details] (ebug_project_compliance) shows the project's Java Compiler screen. Everything is *supposed* to be inherited from the workspace, but incorrectly is defaulting to 1.4. Clicking the "Configure Workspace Settings..." link brings up correct workspace settings for 1.8 as before. Obviously, trying to build the project fails with parse errors. Clicking *any* of the sub-entries (Building, Errors/Warnings, etc) shows the correct "everything is disabled because project-specific settings are disabled" state. But clicking back on the project's Java Compiler screen then *changes* to the screen in attachment #3 [details] (ebug_project_compliance_after_subentries). Nothing has been changed -- only looking at different preferences -- but the screen is now displaying "use compliance from execution environment" and claiming 1.8 source compatibility. Building still fails, because it's still actually using 1.4 instead of 1.8 as it claims. Enabling project-specific settings and forcing a build works. After that, disabling the project-specific settings goes back to defaulting to 1.4 even though there is nothing anywhere saying "use 1.4". Bug 349697 may be related, but that's from four years ago. Similar bugs have been reported on other sites, but were always tracked down to an incorrect Maven or Ant setting, and there is no such tool involved here. It doesn't make a difference whether Eclipse itself is started with a -vm option or not; it only has the Java 1.8 environment to use for launching, and it does, but then screws up choosing its compiler. I've no idea what magical state has been lost in exiting and re-launching Eclipse, but workspace settings are simply being ignored. Maintaining project-specific settings isn't viable in the long term.
Created attachment 263597 [details] screenshot #2, project settings broken defaults
Created attachment 263598 [details] screenshot #3, project settings updated after clicking elsewhere, but ignored
I can reproduce using a fresh workspace (much to my own surprise).
When this happened for me, the per workspace compiler settings were almost empty at .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs Toggling the compliance to 1.7 -> OK -> then back to 1.8 fixed that file and all behaves well from thereon. It seems for a fresh workspace, Eclipse pretends the default compliance to be 1.8, whereas no per-workspace compliance has been set (causing the built-in default of 1.4 to apply). IIRC, the 1.8 default is determined based on the available VMs. Perhaps the result of investigating available VMs just isn't persisted? This could explain why initially all was well and restart - failing to find persisted settings - entered the bad state.
In the good case, when the first Java project is created in a fresh workspace, per-workspace compliance settings are persisted in this call chain: JavaCore.setOptions(Hashtable<String,String>) line: 5784 JavaRuntime.updateCompliance(IVMInstall) line: 2817 JavaRuntime.initializeVMs() line: 2776 JavaRuntime.getDefaultVMId() line: 548 JavaRuntime.getDefaultVMInstall() line: 493 NewJavaProjectWizardPageOne$JREGroup.getDefaultJVMName() line: 564 NewJavaProjectWizardPageOne$JREGroup.getDefaultJVMLabel() line: 598 NewJavaProjectWizardPageOne$JREGroup.<init>(NowJavaProjectWizardPageOne) line: 403 NewJavaProjectWizardPageOne.<init>() line: 1055 ... Afterwards the file .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs has this content: eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8 org.eclipse.jdt.core.compiler.compliance=1.8 org.eclipse.jdt.core.compiler.problem.assertIdentifier=error org.eclipse.jdt.core.compiler.problem.enumIdentifier=error org.eclipse.jdt.core.compiler.source=1.8 Either on some workspaces a project can be created without going through this path, or there exists another path that will later remove the per-workspace compliance settings. All this non-deterministic trouble with compliance settings much reminds me of bug 482991.
Fragments of a theory how writing the settings file could be bypassed: During JavaRuntime.initializeVMs() and inside JavaRuntime.updateCompliance() if 'isDefault' is set to false we will *not* write compliance related default settings. This would require that the following two got out of sync: JavaCore.getOptions() BundleDefaultsScope.INSTANCE.getNode(JavaCore.PLUGIN_ID) In the good case, both are initialized from JavaCorePreferenceInitializer.initializeDefaultPreferences() Inside there we eventually call defaultPreferences.put(optionName, (String)entry.getValue()) Inside put we eventually call DefaultPreferences.internalPut(String, String) Here preferences are propagated to the bundle defaults "if (isInitializingBundleDefaults())" Forcing the latter method to return false while processing any compliance related option will trigger the bug. Looking at the call chain from JavaCore.start() leading up to JavaCorePreferenceInitializer.initializeDefaultPreferences() I don't see how this could get broken, but maybe sync between options and preferences get's broken somehow after the fact ...
I have to give up for now, partly because I never again saw the bug occur without my intervention in the debugger.q Anyone trying this may want to use this: - launch into a fresh workspace - open the wizard for creating a new Java project - at this point look for .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs - if it contains compliance settings, abort and start over ... Anyway, I believe setting per-workspace compliance first to 1.7 then back to 1.8 is a viable workaround ...
(In reply to Stephan Herrmann from comment #7) > Anyway, I believe setting per-workspace compliance first to 1.7 then back to > 1.8 is a viable workaround ... OP here, I can confirm that this works for me, including surviving a restart of Eclipse. Thank you for all the time you've spent on this!
(In reply to J. Zufallig from comment #8) > (In reply to Stephan Herrmann from comment #7) > > Anyway, I believe setting per-workspace compliance first to 1.7 then back to > > 1.8 is a viable workaround ... > > OP here, I can confirm that this works for me, including surviving a restart > of Eclipse. Thank you for all the time you've spent on this! Thanks for confirming. Still a way to go to reliable functioning.
bulk move out of 4.8
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.
