Comment 1 Dani Megert 2016-05-17 03:02:50 EDT

On which original Eclipse build did you install the Java 9 feature patch?

It looks like you don't have the latest stuff. We fixed that issue with bug 489958.

Comment 2 Dani Megert 2016-05-17 03:34:33 EDT

(In reply to Dani Megert from comment #1)
> On which original Eclipse build did you install the Java 9 feature patch?
> 
> It looks like you don't have the latest stuff. We fixed that issue with bug
> 489958.

Never mind. Stephan reported the same problem with the latest stuff.

Comment 3 Jay Arthanareeswaran 2016-05-17 08:05:44 EDT

I wrote a small program that tries to load the class "javax.annotation.PostConstruct" and ran it. This is the output:

java.lang.ClassNotFoundException: javax.annotation.PostConstruct
        at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:366)
        at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/ClassLoaders.java:184)
        at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
        at java.lang.Class.forName0(java.base@9-ea/Native Method)
        at java.lang.Class.forName(java.base@9-ea/Class.java:294)
        at X.main(X.java:6)

Comment 4 Jay Arthanareeswaran 2016-05-17 08:09:53 EDT

Wayne, did you get a chance to try any regular Neon build with the b118 JRE?

Comment 5 Jay Arthanareeswaran 2016-05-17 08:31:06 EDT

(In reply to Jay Arthanareeswaran from comment #3)
> I wrote a small program that tries to load the class
> "javax.annotation.PostConstruct" and ran it. This is the output:

BTW, I am not sure if that should have worked.

Comment 6 Thomas Watson 2016-05-17 08:59:47 EDT

I can launch the SDK with b114.  I will try with b118 next.

Comment 7 Thomas Watson 2016-05-17 09:25:06 EDT

(In reply to Jay Arthanareeswaran from comment #3)
> I wrote a small program that tries to load the class
> "javax.annotation.PostConstruct" and ran it. This is the output:
> 
> java.lang.ClassNotFoundException: javax.annotation.PostConstruct
>         at
> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/
> BuiltinClassLoader.java:366)
>         at
> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/
> ClassLoaders.java:184)
>         at
> java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
>         at java.lang.Class.forName0(java.base@9-ea/Native Method)
>         at java.lang.Class.forName(java.base@9-ea/Class.java:294)
>         at X.main(X.java:6)

If this fails it would seem like a bug in the VM build.  Wayne, can you report that issue back to the VM?

Comment 8 Thomas Watson 2016-05-17 09:50:00 EDT

(In reply to Thomas Watson from comment #7)
> If this fails it would seem like a bug in the VM build.  Wayne, can you
> report that issue back to the VM?

Hold off on that.  I think the javax.annotation got removed from the boot classpath so this program likely should not work by default.  See bug 489958.

Perhaps something changed in java 9 again that broke the check in the launcher for running on java 9.

Comment 9 Thomas Watson 2016-05-17 11:50:21 EDT

The eclipse SDK looks to need at least the module java.annotations.common above the java.se module.  It may be more safe to simply include the java.se.ee module to launch on java 9.

Add this to your eclipse.ini after the -vmargs line

-addmods
java.se.ee


You can play around changing the modules.  For example, I got it to launch just with java.annotations.common, but that is missing some other packages that are typically available from Java 8 boot class loader.  See http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html for details on the module content.

I'm unsure if we can add this to our eclipse.ini be default.  For example, I don't know if that will bust java 8 launching.  I would hope the unrecognized arg would go unused, but I think it would at least print a message.

Comment 10 Wayne Beaton 2016-05-17 11:57:32 EDT

(In reply to Thomas Watson from comment #9)
> -addmods
> java.se.ee

That makes it go with the Java 9 JVM.

Under Java 8, I get complete failure:

--
[wayne@daffy eclipse]$ ./eclipse 
Unrecognized option: -addmods
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
--

Comment 11 Dani Megert 2016-05-17 12:03:01 EDT

(In reply to Thomas Watson from comment #9)
> The eclipse SDK looks to need at least the module java.annotations.common
> above the java.se module.  It may be more safe to simply include the
> java.se.ee module to launch on java 9.
> 
> Add this to your eclipse.ini after the -vmargs line
> 
> -addmods
> java.se.ee

Could we set this in the launcher, depending on the JRE version?

Comment 12 Thomas Watson 2016-05-17 12:05:22 EDT

I'm actually not getting this to work in my eclipse.ini on windows.  I thought I was but I was still using the java 8 VM.  And interestingly enough that did not fail to launch for me even though the option should not be recognized.

Comment 13 Thomas Watson 2016-05-17 12:08:55 EDT

Invoking java directly does work for me though.

java -addmods java.annotations.common -jar plugins\org.eclipse.equinox.launcher_1.3.200.v20160318-1642.jar -console

Comment 14 Thomas Watson 2016-05-17 12:11:49 EDT

I fear the -addmods option only works when using the java launcher.  I think it may have worked for Wayne (on linux?) because there I think we do not use the shared library to launch the VM by default, but on Windows we do.

Comment 15 Thomas Watson 2016-05-17 12:17:38 EDT

Using a -vm option in my eclipse.ini to point to the java 9 java.exe on windows makes it work with the -addmods option.  Perhaps the jvm.dll has not been updated to accept the -addmods option yet.

Comment 16 Wayne Beaton 2016-05-17 12:20:34 EDT

(In reply to Thomas Watson from comment #15)
> Using a -vm option in my eclipse.ini to point to the java 9 java.exe on
> windows makes it work with the -addmods option.  Perhaps the jvm.dll has not
> been updated to accept the -addmods option yet.

I should have been more clear. I set the -vm option in the ini file in my test.

Comment 17 Thomas Watson 2016-05-17 14:07:36 EDT

(In reply to Dani Megert from comment #11)
> (In reply to Thomas Watson from comment #9)
> > The eclipse SDK looks to need at least the module java.annotations.common
> > above the java.se module.  It may be more safe to simply include the
> > java.se.ee module to launch on java 9.
> > 
> > Add this to your eclipse.ini after the -vmargs line
> > 
> > -addmods
> > java.se.ee
> 
> Could we set this in the launcher, depending on the JRE version?

I think we used to do similar things for permgen options, so this should be possible.  But I doubt for Neon.  Also the limitations of the jvm shared library to accept the -addmods option is problematic.  I think this would have to wait until Neon 2 and work with the VM team to ensure the jvm launching library can take the -addmods option.

The other option to look at is if there are java 9 APIs that allow us to dynamically load more modules at runtime.  I know early on they were talking about having such APIs but I have not looked at the latest state of that.

Comment 18 Thomas Watson 2016-05-19 09:11:02 EDT

Moving to Neon.1 to investigate having the launcher add the -addmods automatically for Java 9 VMs.

Comment 19 Dani Megert 2016-05-19 09:57:36 EDT

(In reply to Thomas Watson from comment #18)
> Moving to Neon.1 to investigate having the launcher add the -addmods
> automatically for Java 9 VMs.

We will document the workaround in the N&N (see bug 494022).

Comment 20 Klara Ward 2016-06-23 08:01:04 EDT

There is ongoing JDK work by the Jigsaw team to make the -addmods flag (and others) into VM flags

https://bugs.openjdk.java.net/browse/JDK-8136930

Comment 21 Thomas Watson 2016-06-23 08:26:53 EDT

(In reply to Klara Ward from comment #20)
> There is ongoing JDK work by the Jigsaw team to make the -addmods flag (and
> others) into VM flags
> 
> https://bugs.openjdk.java.net/browse/JDK-8136930

If I read that issue correctly currently the -addmods (and other module options) are being set as system properties by the java executable?  For example -addmods sets the addmods system property?  But once these are changed to "real" VM flags then they will no longer be set in system properties?  The -addmods flag must be used AND that option will then be understood by shared vm library (e.g. jvm.dll)?

Comment 22 Klara Ward 2016-06-23 08:53:23 EDT

> If I read that issue correctly currently the -addmods (and other module
> options) are being set as system properties by the java executable?  For
> example -addmods sets the addmods system property?  But once these are
> changed to "real" VM flags then they will no longer be set in system
> properties?  The -addmods flag must be used AND that option will then be
> understood by shared vm library (e.g. jvm.dll)?

Yes, this is my understanding as well.

We in the JMC team also planned to use the same flags for multiple JDK versions, and add the -XX:+IgnoreUnrecognizedVMOptions flag, but this unfortunately doesn't work with the -addmods flag, since it uses whitespace to separate the flag and the parameter...
There is some ongoing discussion about this I believe.

Comment 23 Klara Ward 2016-08-16 06:01:26 EDT

The VM flag has now been changed to
--add-modules=<comma separated list of modules>
There is also 
--add-exports=<module>/<package>=<other-module>(,<other-module>)*
(this flag can be used more than once)

OpenJDK changeset http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3cfddcb268e3
Should be in the next EA build.

Comment 24 Jay Arthanareeswaran 2016-08-17 00:45:39 EDT

*** Bug 497595 has been marked as a duplicate of this bug. ***

Comment 25 Thomas Watson 2016-08-31 09:37:36 EDT

Nothing ready for Neon.1.  Moving to consideration for Neon.2.

Comment 26 Wayne Beaton 2016-09-14 12:47:14 EDT

FWIW, the changed flag works as expected with the latest builds of Eclipse SDK and Java 9. With the old flag, launching crashes and burns immediately; without the flag, we get as far as workspace selection before we get the CNFE.

So... this works:

From the eclipse.ini:
-vmargs
--add-modules=java.se.ee
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m

Configuration:
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+135, mixed mode)

and

Eclipse SDK
Version: Oxygen (4.7)
Build id: I20160914-0800
OS: Linux, v.4.4.14-200.fc22.x86_64, x86_64 / gtk 3.16.7, WebKit 2.4.11

Comment 27 Thomas Watson 2016-11-15 10:59:22 EST

Nothing going to happen for Neon.3.  I also think it is dangerous to do anything at this point until all the options for Java 9 been locked down and will not change.  Otherwise we run the risk of the launch failing hard with no way to override the hardcoded option.

Comment 28 Dani Megert 2017-01-16 11:24:19 EST

(In reply to Thomas Watson from comment #27)
> Nothing going to happen for Neon.3.  I also think it is dangerous to do
> anything at this point until all the options for Java 9 been locked down and
> will not change.  Otherwise we run the risk of the launch failing hard with
> no way to override the hardcoded option.

I still think we have to make Eclipse 4.6.3 and 4.7 run on Java 9 out of the box.

Unfortunately, adding

--add-modules=java.se.ee
-XX:+IgnoreUnrecognizedVMOptions

to the eclipse.ini does not work since the IBM (and maybe other) VMs do not have an option to ignore unrecognized VM options.

Tom, how about adding a new (temporary) option for the launcher, e.g. --enableJava9Launching. This would add "--add-modules=java.se.ee" in case of Java 9 and allow users to disable this, in case the option changes again.

Comment 29 Thomas Watson 2017-01-17 12:02:55 EST

(In reply to Dani Megert from comment #28)
> 
> Tom, how about adding a new (temporary) option for the launcher, e.g.
> --enableJava9Launching. This would add "--add-modules=java.se.ee" in case of
> Java 9 and allow users to disable this, in case the option changes again.

But then users need to know to update their eclipes.ini or command line to use this temporary option.  We would have to publicize the option etc.  This does not seem much better than documenting what options you need to make java 9 work.  I guess the one benefit is if the java 9 options change we can update the launcher to specify the new options instead of documenting new options again.

Comment 30 Dani Megert 2017-01-23 09:06:26 EST

(In reply to Thomas Watson from comment #29)
> (In reply to Dani Megert from comment #28)
> > 
> > Tom, how about adding a new (temporary) option for the launcher, e.g.
> > --enableJava9Launching. This would add "--add-modules=java.se.ee" in case of
> > Java 9 and allow users to disable this, in case the option changes again.
> 
> But then users need to know to update their eclipes.ini or command line to
> use this temporary option.  We would have to publicize the option etc.  This
> does not seem much better than documenting what options you need to make
> java 9 work.  I guess the one benefit is if the java 9 options change we can
> update the launcher to specify the new options instead of documenting new
> options again.

We would add this to the eclipse.ini. It would hopefully work out of the box, but in case Java 9 changes again, users can opt out.

Comment 31 Markus Keller 2017-01-24 06:53:28 EST

Another solution could be to detect Java versions < 9 in the launcher and in that case have the launcher remove --add-modules=java.se.ee from the command line.

Then we can add --add-modules=java.se.ee to the eclipse.ini by default, and the launcher effectively performs something similar to -XX:+IgnoreUnrecognizedVMOptions, but doesn't require VM support for that.

The risk that a VM < 9 will actually require --add-modules is very low. Certainly lower than the risk that a VM >= 9 will not be able to handle --add-modules=java.se.ee (comment 27).

Comment 32 Dani Megert 2017-01-29 11:13:20 EST

(In reply to Markus Keller from comment #31)
> Another solution could be to detect Java versions < 9 in the launcher and in
> that case have the launcher remove --add-modules=java.se.ee from the command
> line.
> 
> Then we can add --add-modules=java.se.ee to the eclipse.ini by default, and
> the launcher effectively performs something similar to
> -XX:+IgnoreUnrecognizedVMOptions, but doesn't require VM support for that.
> 
> The risk that a VM < 9 will actually require --add-modules is very low.
> Certainly lower than the risk that a VM >= 9 will not be able to handle
> --add-modules=java.se.ee (comment 27).

Fine with me too.

Comment 33 Dani Megert 2017-02-10 10:02:08 EST

(In reply to Dani Megert from comment #28)
> Unfortunately, adding
> 
> --add-modules=java.se.ee
> -XX:+IgnoreUnrecognizedVMOptions
> 
> to the eclipse.ini does not work since the IBM (and maybe other) VMs do not
> have an option to ignore unrecognized VM options.

IBM will most likely provide that option in their updates for Java 8 and Java 9 before we ship. So, we might be able to go with that approach. That would also save us from adding special code to the launcher.

Comment 34 Dani Megert 2017-02-21 09:04:32 EST

(In reply to Dani Megert from comment #33)
> (In reply to Dani Megert from comment #28)
> > Unfortunately, adding
> > 
> > --add-modules=java.se.ee
> > -XX:+IgnoreUnrecognizedVMOptions
> > 
> > to the eclipse.ini does not work since the IBM (and maybe other) VMs do not
> > have an option to ignore unrecognized VM options.
> 
> IBM will most likely provide that option in their updates for Java 8 and
> Java 9 before we ship. So, we might be able to go with that approach. That
> would also save us from adding special code to the launcher.

We can't expect that people who update to Oxygen also update to the latest IBM JRE (otherwise they would not be able to launch). Therefore we will go with comment 31.

Comment 35 Thomas Watson 2017-03-02 13:46:46 EST

Is there a chance we can get something like comment 31 for M6 next week?

Comment 36 Dani Megert 2017-03-07 05:23:57 EST

(In reply to Thomas Watson from comment #35)
> Is there a chance we can get something like comment 31 for M6 next week?

This is too late for M6. We should also consider to handle at least add-opens and add-exports.

Comment 37 Thomas Watson 2017-03-07 09:08:36 EST

(In reply to Dani Megert from comment #36)
> (In reply to Thomas Watson from comment #35)
> > Is there a chance we can get something like comment 31 for M6 next week?
> 
> This is too late for M6. We should also consider to handle at least
> add-opens and add-exports.

Can you explain more?  Is there some setting here we need to enable by default?

Comment 38 Dani Megert 2017-03-07 10:12:01 EST

(In reply to Thomas Watson from comment #37)
> (In reply to Dani Megert from comment #36)
> > (In reply to Thomas Watson from comment #35)
> > > Is there a chance we can get something like comment 31 for M6 next week?
> > 
> > This is too late for M6. We should also consider to handle at least
> > add-opens and add-exports.
> 
> Can you explain more?  Is there some setting here we need to enable by
> default?

To my current knowledge the Platform (runtime) is fine, but e.g. the tests use an Orbit bundle that accesses SunReflectionFactoryInstantiator (see bug 508734). To allow clients to react to such things we should allow them to use add-opens and add-exports.

Comment 39 Thomas Watson 2017-03-07 11:13:33 EST

(In reply to Dani Megert from comment #38)
> (In reply to Thomas Watson from comment #37)
> > (In reply to Dani Megert from comment #36)
> > > (In reply to Thomas Watson from comment #35)
> > > > Is there a chance we can get something like comment 31 for M6 next week?
> > > 
> > > This is too late for M6. We should also consider to handle at least
> > > add-opens and add-exports.
> > 
> > Can you explain more?  Is there some setting here we need to enable by
> > default?
> 
> To my current knowledge the Platform (runtime) is fine, but e.g. the tests
> use an Orbit bundle that accesses SunReflectionFactoryInstantiator (see bug
> 508734). To allow clients to react to such things we should allow them to
> use add-opens and add-exports.

By allow, you mean allow them in the eclipse.ini file and have the launcher ingore them if not running on Java 9?

Comment 40 Dani Megert 2017-03-07 11:28:23 EST

(In reply to Thomas Watson from comment #39)
> By allow, you mean allow them in the eclipse.ini file and have the launcher
> ingore them if not running on Java 9?

Yep.

Comment 41 Thomas Watson 2017-03-07 14:18:01 EST

(In reply to Dani Megert from comment #40)
> (In reply to Thomas Watson from comment #39)
> > By allow, you mean allow them in the eclipse.ini file and have the launcher
> > ingore them if not running on Java 9?
> 
> Yep.

Seems reasonable.

Comment 42 Markus Keller 2017-03-15 12:05:33 EDT

The requirement for non-modular Java SE 8 applications to add new VM arguments to make them work on Java SE 9 is a breaking change that is totally against the spirit of Java.

https://jdk9.java.net/ refers to https://docs.oracle.com/javase/9/tools/java.htm , which is still completely outdated and doesn't even mention modules at all.
Same for http://download.java.net/java/jdk9/docs/technotes/tools/windows/java.html

JDK 9-ea+160's "java -h" says:
--------------------------------------------------------------------------------
    --add-modules <modulename>[,<modulename>...]
                  root modules to resolve in addition to the initial module.
                  <modulename> can also be ALL-DEFAULT, ALL-SYSTEM,
                  ALL-MODULE-PATH.
[...]
To specify an argument for a long option, you can use --<name>=<value> or
--<name> <value>.
--------------------------------------------------------------------------------

According to http://openjdk.java.net/jeps/261#Root-modules , ALL-SYSTEM is probably the best default for Eclipse that would avoid the breaking change for our users.

The workaround in the Eclipse launcher (remove unsupported vmargs when running with Java < 9) should work with both spellings (one-arg with "=", or two-arg).

Unfortunately, we can't simply strip all options that start with "--". The problem is that there are also zero-arg options like --version, so there's no generic rule that would tell us whether we have to remove the next argument as well.

(FWIW, putting --add-modules and the argument on two lines in eclipse.ini or Info.plist didn't work for me on the Mac, but it worked fine on Windows 7.)

Comment 43 Thomas Watson 2017-04-04 12:56:42 EDT

(In reply to Markus Keller from comment #42)
> According to http://openjdk.java.net/jeps/261#Root-modules , ALL-SYSTEM is
> probably the best default for Eclipse that would avoid the breaking change
> for our users.
> 

I agree that ALL-SYSTEM is probably the best default for us.


We may want to consider running with the kill switch

 --permit-illegal-access

This will open up all the modules included in the VM for deep reflection as well as access to its internal packages that are not exported.  But doing so will spit out a nasty WARNING:

WARNING: --permit-illegal-access will be removed in the next major release

It also will spit out warnings each time deep reflection is detected which are permitted by this option.  For example:

WARNING: Illegal access by use.internals.Test (file:/Users/tjwatson/workspaces/eclipse/jpms/use.internals/bin/) to field java.net.URL.factory (permitted by --permit-illegal-access)

Comment 44 Gunnar Wagenknecht 2017-04-05 02:05:02 EDT

(In reply to Thomas Watson from comment #43)
> It also will spit out warnings each time deep reflection is detected which
> are permitted by this option.  For example:
> 
> WARNING: Illegal access by use.internals.Test
> (file:/Users/tjwatson/workspaces/eclipse/jpms/use.internals/bin/) to field
> java.net.URL.factory (permitted by --permit-illegal-access)

It would be cool if those warnings could be collected by AERI.

Comment 45 Thomas Watson 2017-04-05 08:34:16 EDT

(In reply to Gunnar Wagenknecht from comment #44)
> (In reply to Thomas Watson from comment #43)
> > It also will spit out warnings each time deep reflection is detected which
> > are permitted by this option.  For example:
> > 
> > WARNING: Illegal access by use.internals.Test
> > (file:/Users/tjwatson/workspaces/eclipse/jpms/use.internals/bin/) to field
> > java.net.URL.factory (permitted by --permit-illegal-access)
> 
> It would be cool if those warnings could be collected by AERI.

I think they are posted to System.err.  So you would have to capture that stream to report these.

Comment 46 Dani Megert 2017-04-07 10:15:19 EDT

(In reply to Thomas Watson from comment #43)
> It also will spit out warnings each time deep reflection is detected which
> are permitted by this option.  For example:
> 
> WARNING: Illegal access by use.internals.Test
> (file:/Users/tjwatson/workspaces/eclipse/jpms/use.internals/bin/) to field
> java.net.URL.factory (permitted by --permit-illegal-access)

See https://bugs.openjdk.java.net/browse/JDK-8177916

Comment 47 Andreas Sewe 2017-04-07 11:07:34 EDT

(In reply to Gunnar Wagenknecht from comment #44)
> (In reply to Thomas Watson from comment #43)
> > It also will spit out warnings each time deep reflection is detected which
> > are permitted by this option.  For example:
> > 
> > WARNING: Illegal access by use.internals.Test
> > (file:/Users/tjwatson/workspaces/eclipse/jpms/use.internals/bin/) to field
> > java.net.URL.factory (permitted by --permit-illegal-access)
> 
> It would be cool if those warnings could be collected by AERI.

(In reply to Thomas Watson from comment #45)
> I think they are posted to System.err.  So you would have to capture that
> stream to report these.

I think this is doable if you call System.setErr as early as possible, with a wrapper filtering for "WARNING: Illegal access" or a similarly unique pattern. You could then either copy this information to the Error Log (this is how AERI integrates with the UI Responsiveness Monitoring) or talk directly to AERI's LogListener (see [1] for an example).

@Gunnar: Are you interested in implementing this? If so, open a bug with AERI and I'll happily review any changes you come with with.

[1] <https://git.eclipse.org/r/#/c/85151/15/bundles/org.eclipse.epp.logging.aeri.ide/src/org/eclipse/epp/internal/logging/aeri/ide/IDEStartup.java>

Comment 48 Eclipse Genie 2017-04-25 07:06:47 EDT

New Gerrit change created: https://git.eclipse.org/r/95676

Comment 49 Eclipse Genie 2017-04-28 16:14:13 EDT

Gerrit change https://git.eclipse.org/r/95676 was merged to [master].
Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=2e0869c0e8cf5f4125a3237f22ed6f166a065fbb

Comment 50 Arun Thondapu 2017-04-28 17:26:04 EDT

Launcher binaries for Windows, Mac and Linux have been rebuilt and committed via https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=6e669e45abdd98f3aaa0bad6d380fcac4aa98f39

Comment 51 Arun Thondapu 2017-04-28 17:43:05 EDT

Users can now specify the --add-modules argument in the eclipse.ini's -vmargs section to be able to launch with Java 9 and continue to use the same setup to launch with Java 8 as well. The launcher recognizes both formats of specifying the argument (--add-modules=<value> or --add-modules <value>) and removes it when running with Java 8.

I would appreciate help with testing this change in the next few builds so that any problems and/or regressions can be identified and fixed before M7 releases. Thanks in advance!

Comment 52 Dani Megert 2017-04-30 11:34:26 EDT

(In reply to Arun Thondapu from comment #51)
> Users can now specify the --add-modules argument in the eclipse.ini's
> -vmargs section to be able to launch with Java 9 and continue to use the
> same setup to launch with Java 8 as well. The launcher recognizes both
> formats of specifying the argument (--add-modules=<value> or --add-modules
> <value>) and removes it when running with Java 8.
> 
> I would appreciate help with testing this change in the next few builds so
> that any problems and/or regressions can be identified and fixed before M7
> releases. Thanks in advance!

I'm sorry, I did not test but only read your comment. Reading this I interpret it as you did not treat "--permit-illegal-access" accordingly. But this is necessary. Please close if you fixed this too.

Comment 53 Arun Thondapu 2017-05-02 03:13:33 EDT

(In reply to Dani Megert from comment #52)
> I'm sorry, I did not test but only read your comment. Reading this I
> interpret it as you did not treat "--permit-illegal-access" accordingly. But
> this is necessary. Please close if you fixed this too.

You are right Dani, I had not considered this argument because I wasn't sure if it was really necessary, Tom's comment 43 seemed to mention it as a suggestion. Thanks for the confirmation that it is needed.

It shouldn't be hard to add an additional check for "--permit-illegal-access" and I think I can get it done today.

Comment 54 Lars Vogel 2017-05-02 09:53:27 EDT

*** Bug 516050 has been marked as a duplicate of this bug. ***

Comment 55 Dani Megert 2017-05-02 10:38:14 EDT

We also need to add the new arguments to our eclipse.ini files.

Comment 56 Arun Thondapu 2017-05-03 05:59:38 EDT

(In reply to Arun Thondapu from comment #53)
> (In reply to Dani Megert from comment #52)
> > I'm sorry, I did not test but only read your comment. Reading this I
> > interpret it as you did not treat "--permit-illegal-access" accordingly. But
> > this is necessary. Please close if you fixed this too.
> 
> You are right Dani, I had not considered this argument because I wasn't sure
> if it was really necessary, Tom's comment 43 seemed to mention it as a
> suggestion. Thanks for the confirmation that it is needed.
> 
> It shouldn't be hard to add an additional check for
> "--permit-illegal-access" and I think I can get it done today.

I'm testing the potential patch for this and expect to be done by EOD.

Comment 57 Arun Thondapu 2017-05-03 06:04:26 EDT

(In reply to Dani Megert from comment #55)
> We also need to add the new arguments to our eclipse.ini files.

I had discussed this with Markus last week and he had reservations about adding the arguments to our eclipse.ini files for Oxygen since Java 9 wouldn't be GA by the time Oxygen releases. I'll raise a separate bug to discuss this.

Comment 58 Markus Keller 2017-05-03 08:11:04 EDT

(In reply to Arun Thondapu from comment #57)
> (In reply to Dani Megert from comment #55)
> > We also need to add the new arguments to our eclipse.ini files.
> 
> I had discussed this with Markus last week and he had reservations about
> adding the arguments to our eclipse.ini files for Oxygen since Java 9
> wouldn't be GA by the time Oxygen releases. I'll raise a separate bug to
> discuss this.

Sorry, that must have been a miscommunication/misunderstanding. I think I once said we cannot add it to eclipse.ini "right now" because the launcher was not ready to remove it when running under Java 8. I have no reservations to adding the two arguments for Oxygen once the launcher properly removes them for Java 8.

Comment 59 Eclipse Genie 2017-05-03 11:10:43 EDT

New Gerrit change created: https://git.eclipse.org/r/96317

Comment 60 Arun Thondapu 2017-05-03 11:24:37 EDT

(In reply to Markus Keller from comment #58)
> > I had discussed this with Markus last week and he had reservations about
> > adding the arguments to our eclipse.ini files for Oxygen since Java 9
> > wouldn't be GA by the time Oxygen releases. I'll raise a separate bug to
> > discuss this.
> 
> Sorry, that must have been a miscommunication/misunderstanding. I think I
> once said we cannot add it to eclipse.ini "right now" because the launcher
> was not ready to remove it when running under Java 8. I have no reservations
> to adding the two arguments for Oxygen once the launcher properly removes
> them for Java 8.

Markus, I don't think there is a misunderstanding, the concern you expressed in our last discussion was the possibility (though very remote) of Oracle changing the names of the new arguments we plan to add to the eclipse.ini file, after we release Oxygen and before they GA Java 9.

If there are no objections anymore, I will go ahead and provide patches for updating the eclipse.ini files as well. Thanks!

Comment 61 Dani Megert 2017-05-03 12:04:47 EDT

(In reply to Arun Thondapu from comment #60)
> Markus, I don't think there is a misunderstanding, the concern you expressed
> in our last discussion was the possibility (though very remote) of Oracle
> changing the names of the new arguments we plan to add to the eclipse.ini
> file, after we release Oxygen and before they GA Java 9.

This risk is there, but in that case users can adjust the eclipse.ini.

There's also a discussion for adding another command line argument that allows to suppress the log entries issues when using --permit-illegal-access (see comment 43).


> If there are no objections anymore, I will go ahead and provide patches for
> updating the eclipse.ini files as well. Thanks!

Yes, please.

Comment 62 Eclipse Genie 2017-05-03 15:58:28 EDT

Gerrit change https://git.eclipse.org/r/96317 was merged to [master].
Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=4295e27d8e41283eadba7aa2e098126b22c5a7a9

Comment 63 Arun Thondapu 2017-05-03 17:08:48 EDT

Launcher binaries for Windows, Mac and Linux with the new patch for removing --permit-illegal-access have been rebuilt and committed via https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=e719396741d65a336a6fcc07fba5a6f742f825d1

Comment 64 Arun Thondapu 2017-05-04 06:37:54 EDT

(In reply to Dani Megert from comment #61)
> > If there are no objections anymore, I will go ahead and provide patches for
> > updating the eclipse.ini files as well. Thanks!
> 
> Yes, please.

I've created bug 516143 for updating the eclipse.ini files to include the new VM arguments. This bug can be considered to be completely fixed only after 516143 is also fixed as the new VM arguments are essential for running eclipse out of the box with Java 9 JRE.

Comment 65 Arun Thondapu 2017-05-05 04:12:36 EDT

Verified in 4.7.0.I20170504-2000.

Comment 66 Till Brychcy 2017-05-09 04:23:22 EDT

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)

Comment 67 Till Brychcy 2017-05-09 05:37:18 EDT

(In reply to Till Brychcy from 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)

As the current bug is already set to verified, i have created bug 516349 for this.

Comment 68 RYAN JENTZSCH 2017-05-10 16:35:57 EDT

I've not used Eclipse since Ganymede and on a whim, I decided to download and install Eclipse to see if anything has improved (it hasn't). Does anyone do QA before packaging a release? Guess not. Also Status: VERIFIED FIXED is wrong (definately NOT fixed).

I'm running Linux Mint 18.2 (64-bit) Here's the error log vomit:


!SESSION 2017-05-10 14:20:52.746 -----------------------------------------------
eclipse.buildId=4.6.3.M20170301-0400
java.version=9-ea
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.javascript.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.javascript.product

!ENTRY org.eclipse.osgi 4 0 2017-05-10 14:21:20.895
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:386)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:294)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:490)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:504)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:203)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:632)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:151)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:375)
	... 23 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.1.v20160712-0927
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:410)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
	... 25 more

!ENTRY org.eclipse.e4.ui.workbench 4 0 2017-05-10 14:21:20.907
!MESSAGE FrameworkEvent ERROR
!STACK 0
java.lang.NoClassDefFoundError: javax/annotation/PreDestroy
	at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:426)
	at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:154)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:176)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:106)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:139)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
	at org.eclipse.osgi.container.Module.doStop(Module.java:634)
	at org.eclipse.osgi.container.Module.stop(Module.java:498)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
	at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.1.v20160712-0927
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:410)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
	... 21 more
!SESSION 2017-05-10 14:22:19.576 -----------------------------------------------
eclipse.buildId=4.6.3.M20170301-0400
java.version=9-ea
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.javascript.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.javascript.product

!ENTRY org.eclipse.osgi 4 0 2017-05-10 14:22:44.896
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:386)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:294)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:490)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:504)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:203)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:632)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:151)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:375)
	... 23 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.1.v20160712-0927
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:410)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
	... 25 more

!ENTRY org.eclipse.e4.ui.workbench 4 0 2017-05-10 14:22:44.903
!MESSAGE FrameworkEvent ERROR
!STACK 0
java.lang.NoClassDefFoundError: javax/annotation/PreDestroy
	at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:426)
	at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:154)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:176)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:106)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:139)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
	at org.eclipse.osgi.container.Module.doStop(Module.java:634)
	at org.eclipse.osgi.container.Module.stop(Module.java:498)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
	at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.1.v20160712-0927
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:410)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
	... 21 more

Comment 69 Till Brychcy 2017-05-10 16:52:00 EDT

(In reply to Arun Thondapu from comment #65)
> Verified in 4.7.0.I20170504-2000.

(In reply to RYAN JENTZSCH from comment #68)
> [...] (definately NOT fixed) [...]
> eclipse.buildId=4.6.3.M20170301-0400

Some QA before releasing a comment doesn't hurt either ;-)

If you want to run 4.6.3 with Java-9 Previews, https://www.eclipse.org/eclipse/news/4.6/platform.php#java-9 might help.

Comment 70 RYAN JENTZSCH 2017-05-12 17:24:57 EDT

(In reply to Till Brychcy from comment #69)
> (In reply to Arun Thondapu from comment #65)
> > Verified in 4.7.0.I20170504-2000.
> 
> (In reply to RYAN JENTZSCH from comment #68)
> > [...] (definately NOT fixed) [...]
> > eclipse.buildId=4.6.3.M20170301-0400
> 
> Some QA before releasing a comment doesn't hurt either ;-)
> 
> If you want to run 4.6.3 with Java-9 Previews,
> https://www.eclipse.org/eclipse/news/4.6/platform.php#java-9 might help.

Sorry. Like most things written in Java, it's a literal crap shoot if it will work or not. I'm a bit disappointed, but not surprised that Eclipse didn't work "out of the box". I've spent too many hours in Ganymede's version trying to get it to work years ago so that I will not waste my time mucking about in this newest release if it starts out as a piece of crap.

Comment 71 Stephan Herrmann 2017-05-12 18:13:05 EDT

(In reply to RYAN JENTZSCH from comment #70)
> (In reply to Till Brychcy from comment #69)
> > (In reply to Arun Thondapu from comment #65)
> > > Verified in 4.7.0.I20170504-2000.
> > 
> > (In reply to RYAN JENTZSCH from comment #68)
> > > [...] (definately NOT fixed) [...]
> > > eclipse.buildId=4.6.3.M20170301-0400
> > 
> > Some QA before releasing a comment doesn't hurt either ;-)
> > 
> > If you want to run 4.6.3 with Java-9 Previews,
> > https://www.eclipse.org/eclipse/news/4.6/platform.php#java-9 might help.
> 
> Sorry. Like most things written in Java, it's a literal crap shoot if it
> will work or not. I'm a bit disappointed, but not surprised that Eclipse
> didn't work "out of the box". I've spent too many hours in Ganymede's
> version trying to get it to work years ago so that I will not waste my time
> mucking about in this newest release if it starts out as a piece of crap.

Let's make the test whether you are just a troll or able to understand the facts behind this: Java 9 previews are still a moving target. Making the *previous* version of Eclipse run out-of-the-box on what will eventually become the *next* version of Java is plain impossible in my algebra. Do you have advice how we should achieve this?

Comment 72 RYAN JENTZSCH 2017-05-15 16:18:13 EDT

I'm a troll feed me!! nom nom nom.
You have a point in that Java 9 current state is:

2017/03/16 Rampdown Phase Two
2017/06/22 Initial Release Candidate

My irritation is that Java 9 is stable enough that all other applications that target Java 9 on my desktop do not have any issues:
- PHPStorm
- Ruby Mine
- CLion
- GDevelop
- A few games

Comment 73 Arun Thondapu 2017-06-01 09:43:08 EDT

(In reply to Arun Thondapu from comment #65)
> Verified in 4.7.0.I20170504-2000.

FYI : All changes made as part of this and bug 516143 to enable launching with Java 9 as well as Java 8 using the same configuration in eclipse.ini have been reverted in Oxygen RC3 via bug 517507 and bug 517482.

Comment 74 Lorenzo Mengoni 2017-09-27 09:18:18 EDT

I've just downloaded and installed JDK 9 and Eclipse Oxygen and this is what happen in workspace log:

!SESSION 2017-09-27 15:11:52.624 -----------------------------------------------
eclipse.buildId=4.7.0.I20170612-0950
java.version=9
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=it_IT
Framework arguments:  -product org.eclipse.epp.package.jee.product -keyring /Users/zernolo/.eclipse_keyring
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/zernolo/.eclipse_keyring

!ENTRY org.eclipse.osgi 4 0 2017-09-27 15:12:00.080
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
	... 22 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 24 more

!ENTRY org.eclipse.e4.ui.workbench 4 0 2017-09-27 15:12:00.087
!MESSAGE FrameworkEvent ERROR
!STACK 0
java.lang.NoClassDefFoundError: javax/annotation/PreDestroy
	at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:450)
	at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:156)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:178)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:99)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:141)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
	at org.eclipse.osgi.container.Module.doStop(Module.java:634)
	at org.eclipse.osgi.container.Module.stop(Module.java:498)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
	at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 21 more

Comment 75 Jay Arthanareeswaran 2017-09-27 09:27:48 EDT

(In reply to Lorenzo Mengoni from comment #74)
> I've just downloaded and installed JDK 9 and Eclipse Oxygen and this is what
> happen in workspace log:
> 
This after adding the workaround text in the whitespace in the eclipse.ini?

--add-modules=ALL-SYSTEM

Comment 76 Noopur Gupta 2017-09-29 02:06:40 EDT

*** Bug 525346 has been marked as a duplicate of this bug. ***

Comment 77 Sumitra Swayampraya 2017-10-02 03:01:33 EDT

Hi Team,

I have Java Verison 9 in my computer. I tried to launch Eclipse Oxygen latest version as of now.

It is giving me following error.


Can you please have a look at it and help me in fixing this. t would be a great help.

Thanks in forward.

!SESSION 2017-10-02 12:22:20.157 -----------------------------------------------
eclipse.buildId=4.7.1.M20170906-1700
java.version=9
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.java.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product

!ENTRY org.eclipse.osgi 4 0 2017-10-02 12:22:28.675
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
	... 23 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
	... 25 more

!ENTRY org.eclipse.e4.ui.workbench 4 0 2017-10-02 12:22:28.706
!MESSAGE FrameworkEvent ERROR
!STACK 0
java.lang.NoClassDefFoundError: javax/annotation/PreDestroy
	at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:450)
	at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:156)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:178)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:99)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:141)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
	at org.eclipse.osgi.container.Module.doStop(Module.java:634)
	at org.eclipse.osgi.container.Module.stop(Module.java:498)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
	... 21 more

Comment 78 Till Brychcy 2017-10-02 05:06:22 EDT

(In reply to Sumitra Swayampraya from comment #77)
> [...]
> I have Java Verison 9 in my computer. I tried to launch Eclipse Oxygen
> latest version as of now.
> 
> It is giving me following error.
> [...]

See https://wiki.eclipse.org/Configure_Eclipse_for_Java_9

Comment 79 Keith Chong 2017-10-03 12:25:24 EDT

I am using the build: eclipse-SDK-4.7.1aRC2-win32-x86_64.zip
with Java 9 EA.

I verified that the eclipse.ini has --add-modules=ALL-SYSTEM  and I've add the -vm option to point to Java 9 EA.

I launch eclipse, created and tried to launch a debug Eclipse Application launch configuration, but I got the issue.

org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
	... 23 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 25 more

Comment 80 Keith Chong 2017-10-03 12:56:23 EDT

Correction, I was using the GA version of Java 9

Comment 81 Stephan Herrmann 2017-10-03 13:12:02 EDT

(In reply to Keith Chong from comment #79)
> I verified that the eclipse.ini has --add-modules=ALL-SYSTEM  and I've add
> the -vm option to point to Java 9 EA.

If that didn't help I see two possibilities:

(1) JVM has a bug

(2) --add-modules was not effective because it was not placed after -vmargs in eclipse.ini

All probabilities are pointing towards (2) :)

Comment 82 Till Brychcy 2017-10-03 13:43:53 EDT

I think he meant launching eclipse worked, just launching a nested eclipse doesn't.
Solution: add --add-modules=ALL-SYSTEM to the vm args in the launch configuration of the nested eclipse

Comment 83 Keith Chong 2017-10-03 15:48:59 EDT

(In reply to Stephan Herrmann from comment #81)
> (In reply to Keith Chong from comment #79)
> > I verified that the eclipse.ini has --add-modules=ALL-SYSTEM  and I've add
> > the -vm option to point to Java 9 EA.
> 
> If that didn't help I see two possibilities:
> 
> (1) JVM has a bug
> 
> (2) --add-modules was not effective because it was not placed after -vmargs
> in eclipse.ini
> 
> All probabilities are pointing towards (2) :)

It's after -vmargs:

-startup
plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.550.v20170928-1359
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vm
C:/jdk9/jdk-9/bin/javaw.exe
-vmargs
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m
--add-modules=ALL-SYSTEM

Comment 84 Keith Chong 2017-10-03 15:53:10 EDT

(In reply to Till Brychcy from comment #82)
> I think he meant launching eclipse worked, just launching a nested eclipse
> doesn't.
> Solution: add --add-modules=ALL-SYSTEM to the vm args in the launch
> configuration of the nested eclipse

Yes, the initial launch worked but the nested eclipse didn't.  It is added to the vm args of the launch configuration but it failed.

Comment 85 Stephan Herrmann 2017-10-05 05:28:42 EDT

(In reply to Keith Chong from comment #84)
> (In reply to Till Brychcy from comment #82)
> > I think he meant launching eclipse worked, just launching a nested eclipse
> > doesn't.
> > Solution: add --add-modules=ALL-SYSTEM to the vm args in the launch
> > configuration of the nested eclipse
> 
> Yes, the initial launch worked but the nested eclipse didn't.  It is added
> to the vm args of the launch configuration but it failed.

Sorry for misreading your comment.

Perhaps inspecting the full command line used for the inner launch will provide some clue: After the (failed) launch, go to the debug view, select the second node (label should be the full path to javaw.exe) and inspect its properties.

Comment 86 Keith Chong 2017-10-05 14:11:45 EDT

(In reply to Stephan Herrmann from comment #85)
> (In reply to Keith Chong from comment #84)
> > (In reply to Till Brychcy from comment #82)
> > > I think he meant launching eclipse worked, just launching a nested eclipse
> > > doesn't.
> > > Solution: add --add-modules=ALL-SYSTEM to the vm args in the launch
> > > configuration of the nested eclipse
> > 
> > Yes, the initial launch worked but the nested eclipse didn't.  It is added
> > to the vm args of the launch configuration but it failed.
> 
> Sorry for misreading your comment.
> 
> Perhaps inspecting the full command line used for the inner launch will
> provide some clue: After the (failed) launch, go to the debug view, select
> the second node (label should be the full path to javaw.exe) and inspect its
> properties.

I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=525583 to track this problem since others were able to reproduce.   See more details there.  I did copy or import all the vm args.

Comment 87 Simon Kepp 2017-12-17 13:30:01 EST

This bug still causes the Oxygen release of Eclipse to fail on Windows running Java 9.0.1.
Either this bug should be fixed, or the proposed workaround implemented in the default eclipse.ini, that comes with Oxygen

Comment 88 Till Brychcy 2017-12-17 13:42:58 EST

(In reply to Simon Kepp from comment #87)
> This bug still causes the Oxygen release of Eclipse to fail on Windows
> running Java 9.0.1.
> Either this bug should be fixed, or the proposed workaround implemented in
> the default eclipse.ini, that comes with Oxygen

This has been fixed in another bug.
Please use 4.7.1a or later.

Comment 89 Marcus Lagergren 2018-01-11 05:10:43 EST

This still very much happens with Java 9.0.1 and 4.7.2.M20171130-0510

!SESSION 2016-11-24 08:32:12.208 -----------------------------------------------
eclipse.buildId=4.6.1.M20160907-1200
java.version=1.8.0_111
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.java.product -keyring /Users/marlag/.eclipse_keyring
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.java.product -keyring /Users/marlag/.eclipse_keyring

!ENTRY org.eclipse.buildship.core 2 0 2016-11-24 08:33:04.896
!MESSAGE Could not load Gradle version information
!STACK 0
org.gradle.api.UncheckedIOException: Cannot download published Gradle versions.
        at com.gradleware.tooling.toolingutils.distribution.PublishedGradleVersions.downloadVersionInformation(PublishedGradleVersions.java:175)
        at com.gradleware.tooling.toolingutils.distribution.PublishedGradleVersions.tryToDownloadAndCacheVersions(PublishedGradleVersions.java:159)
        at com.gradleware.tooling.toolingutils.distribution.PublishedGradleVersions.create(PublishedGradleVersions.java:119)
        at org.eclipse.buildship.core.util.gradle.PublishedGradleVersionsWrapper$LoadVersionsJob.run(PublishedGradleVersionsWrapper.java:66)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1546)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
        at com.gradleware.tooling.toolingutils.distribution.PublishedGradleVersions.downloadVersionInformation(PublishedGradleVersions.java:172)
        ... 4 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
        at sun.security.validator.Validator.validate(Validator.java:260)
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
        at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
        ... 17 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
        at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
        at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
        ... 23 more

Comment 90 Marcus Lagergren 2018-01-11 05:11:41 EST

Sorry, please disregard my earlier comment, there seems to be some version skew in my setup.

Comment 91 Marcus Lagergren 2018-01-11 05:13:02 EST

Nope. Still there.

!SESSION 2018-01-11 11:12:11.817 -----------------------------------------------
eclipse.buildId=4.7.2.M20171130-0510
java.version=9.0.1
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_SE
Framework arguments:  -product org.eclipse.epp.package.jee.product -keyring /Users/marlag/.eclipse_keyring
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/marlag/.eclipse_keyring

!ENTRY org.eclipse.osgi 4 0 2018-01-11 11:12:17.818
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
        at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410)
        at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
        at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204)
        at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
        at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124)
        at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
        ... 22 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
        at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
        ... 24 more

Comment 92 Andreas Sewe 2018-01-11 05:15:45 EST

(In reply to Marcus Lagergren from comment #90)
> Sorry, please disregard my earlier comment, there seems to be some version
> skew in my setup.

That being said, the root cause also seems to be different. It's not a NoClassDefFoundError but rather a ValidatorException related to some SSL certificates used on a Gradle download site. Maybe you should open a bug at the Buildship project, which provides the Gradle integration in Eclipse:

  <https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Buildship>

I'm sure they want to know if even one Java version out there doesn't have the necessary certificates in its truststore to download the Gradle distribution.

Comment 93 Marcus Lagergren 2018-01-11 05:20:52 EST

I got it to launch after creating a completely new workspace.

Apparently data from the existing workspace (created with Java 8) interfered with the startup it some way.

Comment 94 Serge Burtsev 2018-03-15 11:09:06 EDT

I'm alsohad this issue with Eclipse JEE 4.7.2-1(Jdk 9.0.4) under Arch linux.
Error log:
https://pastebin.com/yJDgrsjT

Comment 95 Dani Megert 2018-03-15 11:17:15 EDT

(In reply to Serge Burtsev from comment #94)
> I'm alsohad this issue with Eclipse JEE 4.7.2-1(Jdk 9.0.4) under Arch linux.
> Error log:
> https://pastebin.com/yJDgrsjT

There was a problem for those that installed the Marketplace version. I suggest to do a fresh install.

Comment 96 Florian Beckmann 2018-04-19 08:15:04 EDT

Just did a fresh install and get the same error: 
https://pastebin.com/U3HB5e4g

Comment 97 Dani Megert 2018-04-19 08:34:57 EDT

(In reply to Florian Beckmann from comment #96)
> Just did a fresh install and get the same error: 
> https://pastebin.com/U3HB5e4g

What exactly did you install and which JRE are you using?

Comment 98 Florian Beckmann 2018-04-19 08:42:09 EDT

All version information is in the pastebin.
I downloaded eclipse-jee-oxygen-3a-linux-gtk-x86_64.tar.gz and used a fresh eclipse-workspace.
Java archive was jdk-9.0.4_linux-x64_bin.tar.gz from oracle, converted to oracle-java9-jdk_9.0.4_amd64.deb on Ubuntu 17.10.1 (Artful Aardvark) with java-package.

Comment 99 Dani Megert 2018-04-19 08:50:35 EDT

(In reply to Florian Beckmann from comment #98)
> All version information is in the pastebin.

I avoid to click external links. The information should be part of the bug report.


> I downloaded eclipse-jee-oxygen-3a-linux-gtk-x86_64.tar.gz and used a fresh
> eclipse-workspace.
> Java archive was jdk-9.0.4_linux-x64_bin.tar.gz from oracle, converted to
> oracle-java9-jdk_9.0.4_amd64.deb on Ubuntu 17.10.1 (Artful Aardvark) with
> java-package.

Does the eclipse.ini contain
--add-modules=ALL-SYSTEM
?

If yes, it looks like this gets lost somewhere. However, this is the first bug report about this since we fixed it.

Comment 100 Florian Beckmann 2018-04-19 09:21:00 EDT

Yes, the line is there (last line).

Also, I tried it with and without the -vm option.

Here is the log output:

---

!SESSION 2018-04-19 14:09:17.388 -----------------------------------------------
eclipse.buildId=4.7.3.M20180330-0640
java.version=9.0.4
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 -vm /usr/lib/jvm/default-java/
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product -vm /usr/lib/jvm/default-java/

!ENTRY org.eclipse.osgi 4 0 2018-04-19 14:09:24.977
!MESSAGE Application error
!STACK 1
org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399)
	... 23 more
Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 25 more

!ENTRY org.eclipse.e4.ui.workbench 4 0 2018-04-19 14:09:25.130
!MESSAGE FrameworkEvent ERROR
!STACK 0
java.lang.NoClassDefFoundError: javax/annotation/PreDestroy
	at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:450)
	at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:156)
	at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111)
	at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74)
	at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:178)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:99)
	at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:141)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
	at org.eclipse.osgi.container.Module.doStop(Module.java:634)
	at org.eclipse.osgi.container.Module.stop(Module.java:498)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165)
	at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 21 more

Comment 101 Dani Megert 2018-04-19 09:25:08 EDT

(In reply to Florian Beckmann from comment #100)
> Yes, the line is there (last line).

Strange. Can you try to explicitly add
--add-modules=ALL-SYSTEM
via -vmargs on the command line?

Comment 102 Florian Beckmann 2018-04-19 09:38:56 EDT

yout mean like
./eclipse -vmargs --add-modules=ALL-SYSTEM
?
That didn't work either.

Comment 103 Dani Megert 2018-04-19 09:46:28 EDT

(In reply to Florian Beckmann from comment #102)
> yout mean like
> ./eclipse -vmargs --add-modules=ALL-SYSTEM
> ?
> That didn't work either.

OK, so, no idea what's wrong.


> converted to oracle-java9-jdk_9.0.4_amd64.deb on Ubuntu 17.10.1 (Artful Aardvark) with java-package.

Maybe that introduces the problem?


You could also try with http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.3a-201803300640/

Comment 104 Florian Beckmann 2018-04-19 11:27:58 EDT

(In reply to Dani Megert from comment #103)
> > converted to oracle-java9-jdk_9.0.4_amd64.deb on Ubuntu 17.10.1 (Artful Aardvark) with java-package.
> 
> Maybe that introduces the problem?

Maybe but unlikely. The created deb pakage is simply installing the original archive folder's content to /usr/lib/jvm/oracle-java9-jdk-amd64 (which default-java in /usr/lib/jvm symlinks to - JAVA_HOME=/usr/lib/jvm/default-java on my system). Only difference (imho) to extracting the tar.gz somewhere, is that the contained files are registered by the package manager (dpkg) and symlinks to executables (java, javac, etc.) are created in /usr/bin.

> You could also try with
> http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.3a-201803300640/
Didn't work either. Neither with jdk 9.0.4 nor jdk 10.0.1 (which I just installed).

Comment 105 Florian Beckmann 2018-04-19 11:56:14 EDT

Just installed eclipse-jee-oxygen-3a-linux-gtk-x86_64 and jdk 10.0.1 on my laptop (also running Ubuntu 17.10.1) and eclipse starts up.
Difference on my laptop: I have neither JAVA_HOME nor _JAVA_OPTIONS set.

So I just unset both env vars on my desktop and it works there too! Yeah.
Not sure what caused the problem. Will try to figure that out later.

Thanks for your help Dani!

Comment 106 Dani Megert 2018-04-19 12:04:27 EDT

(In reply to Florian Beckmann from comment #105)
> Thanks for your help Dani!

My pleasure!

Comment 107 Florian Beckmann 2018-04-19 12:10:56 EDT

I successively removed options from the env var _JAVA_OPTIONS until none was left.
Even with 'export _JAVA_OPTIONS=""' eclipse won't start.
If I do 'unset _JAVA_OPTIONS'everything works.

Comment 108 Dani Megert 2018-04-20 06:00:01 EDT

(In reply to Florian Beckmann from comment #107)
> I successively removed options from the env var _JAVA_OPTIONS until none was
> left.
> Even with 'export _JAVA_OPTIONS=""' eclipse won't start.
> If I do 'unset _JAVA_OPTIONS'everything works.

See bug 215689 for details about that behavior.