Community
Participate
Working Groups
Copied from bug 493761 comment 66: With bug 516143 fixed, launching with Java 9 works now out of the box, but now restarting fails with "java.lang.NoClassDefFoundError: javax/annotation/PostConstruct" This already used to work, if eclipse.ini had a manually added "--add-modules=java.se.ee". (Adding this to the current eclipse.ini doesn't make a difference) (Tested on a Mac, using I20170508-2000)
(In reply to Till Brychcy from comment #0) > With bug 516143 fixed, launching with Java 9 works now out of the box, but > now restarting fails with "java.lang.NoClassDefFoundError: > javax/annotation/PostConstruct" > > This already used to work, if eclipse.ini had a manually added > "--add-modules=java.se.ee". (Adding this to the current eclipse.ini doesn't > make a difference) > > (Tested on a Mac, using I20170508-2000) Till, Thanks for testing! I just tested I20170508-2000 on Windows and Linux and don't see the problem there, it could be specific to Mac though, I will test and confirm in some time.
(In reply to Arun Thondapu from comment #1) > I just tested I20170508-2000 on Windows and Linux and don't see the problem > there, it could be specific to Mac though, I will test and confirm in some > time. The problem is indeed reproducible on macOS but I'm not sure yet why this is happening, will try to find a solution tomorrow...
I have analysed the problem by adding some printf to /org.eclipse.equinox.executable/library/eclipse.c and /org.eclipse.equinox.executable/library/cocoa/eclipseCocoa.c. The problem is as follows: When eclipse is initially started, no -VM is set, so the launcher in findVMLibrary (in eclipseCocoa.c) calls getJavaHome (which asks /usr/libexec/java_home) to find "/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java" and invokes checkJavaVersion for that, which runs that command with "-version", recognizes it as modularVM and stores the result in the field isModularJVM. Then it invokes findLib and returns its result "/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/../lib/server/libjvm.dylib" as the result from findVMLibrary. Later this result is remembered for restarting as argument of -VM in getVMCommand (in eclipse.c after the comment /* Append VM and VMARGS to be able to relaunch using exit data */) In between, the method isModularVM is invoked, but it doesn't care about its args and just returns the value stored in the field isModularJVM. After relaunch, the VM is now set to "/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/../lib/server/libjvm.dylib", and checkJavaVersion is invoked for that, but it cannot run it as command so isModularJVM stays 0. Later, the call to isModularJVM returns 0 and therefore the Java 9 specific arguments are removed from the command line in adjustVMArgs (in eclipse.c)
New Gerrit change created: https://git.eclipse.org/r/96773
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/96773 Introduces a new option -modularVM If it is present, the isModularVM()-check is skipped, but assumed to return 1, so Java 9 specific options will be left alone. If it is not present and isModularVM() returns 1, it is added to the command line like -vm, so it will be present after restarting. Tested on macOS 10.12.4 with Java 1.8.0_112 and Java 9-ea+159
Gerrit change https://git.eclipse.org/r/96773 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ad13b29e1e8388dda5021e3c10824aa5c44d2e2a
New Gerrit change created: https://git.eclipse.org/r/96842
(In reply to Eclipse Genie from comment #6) > Gerrit change https://git.eclipse.org/r/96773 was merged to [master]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ad13b29e1e8388dda5021e3c10824aa5c44d2e2a > This patch did fix the restart issue with Java 9 on Mac but on further thoughts and discussion with Dani, I don't think we should go with this fix as we should not add a new command line option unless its necessary and meaningful and definitely not to fix a Mac only issue. I'll revert the fix and look for an alternative solution in RC1.
(In reply to Arun Thondapu from comment #8) > (In reply to Eclipse Genie from comment #6) > > Gerrit change https://git.eclipse.org/r/96773 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ad13b29e1e8388dda5021e3c10824aa5c44d2e2a > > > > This patch did fix the restart issue with Java 9 on Mac but on further > thoughts and discussion with Dani, I don't think we should go with this fix > as we should not add a new command line option unless its necessary and > meaningful and definitely not to fix a Mac only issue. > > I'll revert the fix and look for an alternative solution in RC1. Sure, no problem for me :-) Still I'd feel more comfortable if there was a way to turn off this automatic parameter removal. BTW, I'm not sure this is really a Mac only problem. Only the eclipseWin.c implementation of isModularVM looks like it could deduct the version from a shared library, so this might also be a problem on other Unix-likes if a user uses one of the other values allowed for -vm as documented in https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html
Gerrit change https://git.eclipse.org/r/96842 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=538fd0e85f51ad87f66345bbf704f0163d7acb8e
I already get the NoClassDefFoundError on the first run when I pass the Java 9 libjvm.dylib as -vm argument: $ eclipse-SDK-I20170510-2000.app/Contents/MacOS/eclipse -consolelog -vm /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/../lib/server/libjvm.dylib
(In reply to Markus Keller from comment #11) > I already get the NoClassDefFoundError on the first run when I pass the Java > 9 libjvm.dylib as -vm argument: > > $ eclipse-SDK-I20170510-2000.app/Contents/MacOS/eclipse -consolelog -vm > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/../lib/server/ > libjvm.dylib Yes. Like I wrote, this problem probably also exists on linux etc. With my patch you'd be able to start with eclipse-SDK-I20170510-2000.app/Contents/MacOS/eclipse -consolelog -modularVM -vm /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/../lib/server/libjvm.dylib (BTW: I'm not happy with the "-modularVM" name, I just wanted to keep it close to the c variable name)
(In reply to Arun Thondapu from comment #8) > I'll revert the fix and look for an alternative solution in RC1. Haven't found a fix yet, will try for RC2. (In reply to Till Brychcy from comment #12) > Yes. Like I wrote, this problem probably also exists on linux etc. I'm not able to actually test this scenario on Linux because using the libjvm.so from Java 9 to launch eclipse does not seem to work at all, the workspace selection dialog appears and then the application freezes with a blank black window. However, using Java 8's libjvm.so is still working as expected, so this seems to be a problem with the Java 9 VM itself but I haven't really investigated that part.
*** Bug 517040 has been marked as a duplicate of this bug. ***
I don't have a proper fix for this yet and its a bit too late for Oxygen now, moving to Oxygen.1 release.
(In reply to Arun Thondapu from comment #15) > I don't have a proper fix for this yet and its a bit too late for Oxygen > now, moving to Oxygen.1 release. I dont't think that's acceptable. Java 9 is still scheduled for July 27th, months before Oxygen.1 My proposed fix is WAY better than not fixing this.
I second that! Any user installing Java9 on its system will not be able to restart/switch workspaces. Any even temporary workaround needs to considered instead of moving this to .1
(In reply to Till Brychcy from comment #16) > My proposed fix is WAY better than not fixing this. Introducing an extra command line argument is a no go. If you can provide a better fix, then we can consider this. Please also note that the Java 9 command line arguments are still in flux and can also cause trouble (bug 516911). > Java 9 is still scheduled for July 27th, months before Oxygen.1 To be fair "months" == two months. Anyway, If you haven't seen it already, there will be a Java 9 release on July 27 which can deal with that issue.
New Gerrit change created: https://git.eclipse.org/r/97971
(In reply to Dani Megert from comment #18) > (In reply to Till Brychcy from comment #16) > > My proposed fix is WAY better than not fixing this. > > Introducing an extra command line argument is a no go. If you can provide a > better fix, then we can consider this. (In reply to Eclipse Genie from comment #19) > New Gerrit change created: https://git.eclipse.org/r/97971 Other solution, that avoids an extra command line argument: skip java 9 argument removal, if -vm is present Tested on macOS 10.12.4 with Java 1.8.0_112 and Java 9-ea+159
Arun's review comment from https://git.eclipse.org/r/#/c/97971/ >This breaks starting eclipse with Java 8 on Linux and Windows when specifying the JVM >using the -vm argument because the Java 9 specific arguments do not get removed and >Java 8 fails with "Unrecognised option". >The reason it worked on Mac was simply because Java 8 on Mac seems more resilient to >unrecognized options, it seems to just ignore them and continues to start up eclipse. Well that's the idea of the patch: The auto-detection would only be done if no -vm is given. If you edit your eclipse.ini to provide a -vm, you should also be able to remove the java 9 specific options if needed. BTW, even if you really go ahead to release oxygen without a fix for this bug: I think the parameter removal still needs to be documented in /org.eclipse.platform.doc.isv/reference/misc/runtime-options.html, right?
Do you think it would be an acceptable solution if the parameter removal is skipped, if: - the -vm parameter is present AND - the argument ends with ".dylib"?
(In reply to Till Brychcy from comment #22) > Do you think it would be an acceptable solution if the parameter removal is > skipped, > if: > - the -vm parameter is present > AND > - the argument ends with ".dylib"? That sounds like it could work, considering that Java 8 on macOS anyway seems to ignore unrecognized options.
(In reply to Arun Thondapu from comment #23) > (In reply to Till Brychcy from comment #22) > > Do you think it would be an acceptable solution if the parameter removal is > > skipped, > > if: > > - the -vm parameter is present > > AND > > - the argument ends with ".dylib"? > > That sounds like it could work, considering that Java 8 on macOS anyway > seems to ignore unrecognized options. Implemented in patch set 2: - Only on MACOSX - If the type is VM_LIBRARY
Till, thanks for all your work on this but we're not going to need any new fix for this bug, it has been decided by the PMC (bug 516911 comment 3) that we're going to remove all Java 9 related workarounds from the launcher and eclipse.ini, which means that this regression will get fixed automatically.
See https://wiki.eclipse.org/Eclipse/PMC for some rationale of the PMC decision. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=517452 for an idea improving the Launcher moving forward -- replacing obscure C code that's hard to change by a data-driven approach that can adapt to different VMs. Comments welcome on that bug.
Good decision.
. *** This bug has been marked as a duplicate of bug 517507 ***
Till, please verify with I20170531-2000 or newer. Thanks.
Verified using I20170531-2000: 1) with jdk-9.jdk present in /Library/Java/JavaVirtualMachines, launching fails (as expected) 2) after removing jdk-9.jdk from /Library/Java/JavaVirtualMachines, launching and restarting succeeds with jdk1.8.0_112.jdk 3) after restoring jdk-9.jdk and adding --add-modules=ALL-SYSTEM --permit-illegal-access to eclipse.ini, launching and restarting succeeds with java 9 4) after removing jdk-9.jdk from /Library/Java/JavaVirtualMachines, but while keeping the java 9 specific args in eclipse.ini, launching and restarting succeeds with jdk1.8.0_112.jdk (as expected.)
(In reply to Till Brychcy from comment #30) > 4) after removing jdk-9.jdk from /Library/Java/JavaVirtualMachines, but > while keeping the java 9 specific args in eclipse.ini, launching and > restarting succeeds with jdk1.8.0_112.jdk (as expected.) I'm actually surprised that this doesn't fail, is it because Java8 is less sensitive to unknown options on MacOSX, compared to other Platforms?
(In reply to Martin Oberhuber from comment #31) > (In reply to Till Brychcy from comment #30) > > 4) after removing jdk-9.jdk from /Library/Java/JavaVirtualMachines, but > > while keeping the java 9 specific args in eclipse.ini, launching and > > restarting succeeds with jdk1.8.0_112.jdk (as expected.) > > I'm actually surprised that this doesn't fail, is it because Java8 is less > sensitive to unknown options on MacOSX, compared to other Platforms? I guess this is because on the Mac, java is started via the VM_LIBRARY method, not by executing the "java" command.
*** Bug 517701 has been marked as a duplicate of this bug. ***
