Community
Participate
Working Groups
Created attachment 268652 [details] Screenshot of project and workspace settings. It happens that Eclipse recompiles projects and then shows thousands of phantom compile errors on each project. The errors are related to language contructs that are only available in newer Java versions (generic types, lambdas, etc.). The Java version configured and used throughout all projects and in the workspace is Java 8. The compiler compliance level also is 1.8 everywhere. However, in the failing project a greyed-out value of 1.4 is shown (see screenshot). The problem occurs regularly, about once a day. Fiddling around, cleaning and rebuilding projects helps. Unfortunately this usually takes much time, what renders Eclipse under Linux somewhat non-productive. Eclipse should not assume, or guess, or fall back to any settings that are not configured anywhere. System JDK installed from deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main # java -version java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) Workspace with ~70 dependent Java projects. OS: Debian Linux Jessie with Cinnamon Desktop
The problem also exists in Oxygen.
This reminds me of a problem we've intermittently seen in our tests, too (bug 482991). There the problem was indeed related to detecting/recognizing the current JVM. Could you please try if the problem also occurs when you directly install the Oracle JDK (vs. the repackaged version from that ppa)? Perhaps the JDK is not correctly recognized as 1.8. I've no idea what that installer does. Now that you've upgraded to Oxygen, you could also try the following "hack": launch Eclipse with the following vmarg: -Djdt.default.test.compliance=1.8 This property is intended only for tests, but if that prevents the bug from occurring in your case, we'd know better what is going on (and you'd have a workaround for now). Moving to JDT/Debug to seek their advice on VMs that are / are not recognized by JavaRuntime.initializeVMs()
I have exactly the same error and I have only seen it with Oxygen. I'm able to get around it by switching temporarily back to Java 7 for workspace settings.
(In reply to Per Digre from comment #3) > I have exactly the same error and I have only seen it with Oxygen. > > I'm able to get around it by switching temporarily back to Java 7 for > workspace settings. So the questions/suggestions from comment 2 are directed also at you :)
I suspect this has something to do with "not using Oomph". I had a similar annoying issue with "Build Automatically" never remembered as ON after restarting Eclipse. This went away when I set Oomph to record preferences. Prior to the release I had a "not using Oomph" issue with being stuck on Dark Theme, same resolution using Oomph. I will test comment #2 when I get back to work tomorrow :-)
Regarding comment #2 I am unable to reproduce the issue now. I suspect that having once recorded to Oomph will resolve future installations? This was the setup when it failed for me first time I used Oxygen. Eclipse for RCP and RAP Developers Version: Oxygen Release (4.7.0) Build id: 20170620-1800 C:\Users\psd.ESITO-PSD2>java -version java version "1.8.0_77" Java(TM) SE Runtime Environment (build 1.8.0_77-b03) Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
Oomph may help to avoid the issue, but I still suspect that in some situation the JVM is not correctly recognized in the first place - theory speaking :)
Thank you for your suggested workaround. Meanwhile I've reconfigured all the ~70 projects in the affected workspace to use project specific settings with Java 8 (1.8) compiler set explicitly. I hope to get some time to switch back all projects in order to test your workaround soon. With a directly installed JDK the problem also occurred. In fact I tried to switch back and forth between two installations as standard JDK in Eclipse to resolve the error. An argument against the theory of a badly installed JDK is the fact that another workspace on the same machine with even more projects never showed this error.
I've switched all projects in the affected workspace back to workspace settings and started Eclipse Oxygen with the suggested -Djdt.default.test.compliance=1.8 The workspace now ran for two days without showing the bug.
(In reply to Alexander Veit from comment #9) > I've switched all projects in the affected workspace back to workspace > settings and started Eclipse Oxygen with the suggested > > -Djdt.default.test.compliance=1.8 > > The workspace now ran for two days without showing the bug. Thanks! If that is indeed the situation that previously showed the bug, then indeed all is pointing to a problem with recognizing the current JVM. @Sarika, @Andrey, is there any logging of JVM detection that users could turn on for further analysis?
When you face the problem, can you see what do you have in this file - <Workspace>\.metadata\.plugins\org.eclipse.jdt.launching\.install.xml And do you have any value for "java.home" set in System property ?
The problem does not occur with -Djdt.default.test.compliance=1.8 set. However, my current .install.xml in the workspace affected is <?xml version="1.0" encoding="UTF-8" standalone="no"?> <dirs> <entry loc="/usr/lib/jvm/java-8-oracle" stamp="1494402901000"/> <entry loc="/java/jdk1.8.0_131" stamp="1496226655000"/> <entry loc="/usr/lib/jvm/jdk-8-oracle-x64" stamp="1478073855000"/> </dirs> The first two entries point to an existing directory. The third entry does not exist neither as a directory nor as a sysmolic link. The environment variable JAVA_HOME has the value /usr/lib/jvm/java-8-oracle. As far as I can see the system property java.home is not set explicitely.
(In reply to Alexander Veit from comment #12) > The problem does not occur with -Djdt.default.test.compliance=1.8 set. Thanks, this supports my theory that computing the default compliance might indeed be broken. I'll leave it to Sarika to comment on the other observations :)
(In reply to Stephan Herrmann from comment #10) > (In reply to Alexander Veit from comment #9) > > I've switched all projects in the affected workspace back to workspace > > settings and started Eclipse Oxygen with the suggested > > > > -Djdt.default.test.compliance=1.8 > > > > The workspace now ran for two days without showing the bug. > > Thanks! > If that is indeed the situation that previously showed the bug, then indeed > all is pointing to a problem with recognizing the current JVM. > > @Sarika, @Andrey, is there any logging of JVM detection that users could > turn on for further analysis? We need this. Created Bug 525841.
Again ran into the problem. This time non on Linux but on a Windows 7 machine. /--- .install.xml --- <?xml version="1.0" encoding="UTF-8" standalone="no"?> <dirs> <entry loc="C:\java\jdk8" stamp="1512223991417"/> </dirs> \-------------------- C:\java\jdk8 is a symlink (mklink /D c:\java\jdkk8 c:\java\jdk1.8.0_152). As far as I can tell -Djava.home is not set explicitely. But the environment variable JAVA_HOME is set to C:\java\jdk8.
(In reply to Sarika Sinha from comment #14) > (In reply to Stephan Herrmann from comment #10) > > (In reply to Alexander Veit from comment #9) > > > I've switched all projects in the affected workspace back to workspace > > > settings and started Eclipse Oxygen with the suggested > > > > > > -Djdt.default.test.compliance=1.8 > > > > > > The workspace now ran for two days without showing the bug. > > > > Thanks! > > If that is indeed the situation that previously showed the bug, then indeed > > all is pointing to a problem with recognizing the current JVM. > > > > @Sarika, @Andrey, is there any logging of JVM detection that users could > > turn on for further analysis? > > We need this. Created Bug 525841. @Sarika, after you closed the other bug as wontfix, can you recommend how users can provide us the information we need? Also, I'm not sure knowing which JVM was used is sufficient, we may also need to know (a) did we correctly figure out the version of that JVM? (b) did that JVM version help to set a good default compliance?
I will try to add some logs related to the identified JRE and the version.
(In reply to Stephan Herrmann from comment #16) > > @Sarika, after you closed the other bug as wontfix, can you recommend how > users can provide us the information we need? > > Also, I'm not sure knowing which JVM was used is sufficient, we may also > need to know (a) did we correctly figure out the version of that JVM? (b) > did that JVM version help to set a good default compliance? Working on this, I am planning to put these things ( If VM logging property is enabled)- 1. Log the version details and java home location when we populate the vm library cache 2. When the default vm is used - log the details Will this information be enough? Or some more information to be logged?
New Gerrit change created: https://git.eclipse.org/r/116424
Gerrit change https://git.eclipse.org/r/116424 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=48639e026d77b44f33518af32aafbee44575ef50
-Djdt.debug.launching.vmLogging=true can be used to enable VMLogging.
After updating to Eclipse Photon the problem occurs again. Setting -Djdt.debug.launching.vmLogging=true produces multiple entries in the error log: ``` Default Install retrieved:/usr/lib/jvm/java-8-oracle An exception stack trace is not available. eclipse.buildId=4.8.0.I20180611-0500 java.version=1.8.0_171 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product ``` The directory /usr/lib/jvm/java-8-oracle contains the installed Oracle JDK. The workaround with -Djdt.default.test.compliance=1.8 works in Photon.
Today the problem occurred with Eclipse 2019-09 and JDK 11. Despite JDK 11 being the one and only configured and also the default JDK, each project showed JDK 1.4 compliance. This time -Djdt.default.test.compliance=11 in eclipse.ini seems to fix the error. I wonder why Eclipse has no appropriate fallback value if this property is not present. Even more wondrous is the fact that the projects do not use workspace settings when "project specific settings" isn't checked.
May be the problem is with org.eclipse.jdt.launching.JavaRuntime.updateCompliance(IVMInstall) I am adding some new log statements to be enabled with -Djdt.debug.launching.vmLogging=true I am removing the previous log messages as they are not helping us. @Alexander Will you be able to test with new I build ?
New Gerrit change created: https://git.eclipse.org/r/151995
Gerrit change https://git.eclipse.org/r/151995 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=8011eb9bcca17b8aa2108470dceb5455d1262d6c
After upgrading to Eclipse 2020-09 (JDK 11) the error occurred again. Again each project showed JDK 1.4 compliance. And again -Djdt.default.test.compliance=11 in eclipse.ini fixes the error. I also set -Djdt.debug.launching.vmLogging=true. This showed the startup error eclipse.buildId=4.17.0.I20200902-1800 java.version=11.0.3-internal java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product -data D:\prj\ix-trunk-develop\workspace org.eclipse.jdt.launching Error Mon Sep 21 13:51:22 CEST 2020 Restoring vm library location:C:\java\jdk11 C:\java\jdk11 is a regular directory (no a symbolic link) in which JDK 11 is installed.
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.
