Update: Note that as of October 11/2017, Java 9 is 100% supported “out of the box” by Eclipse IDE, Oxygen Edition; Java 9 can be used to run your Eclipse IDE, Oxygen Edition, and can be used to build Java 9 applications without additional configuration. Download or update today.
I wrote a few weeks ago about getting Eclipse Neon running on Java 9 (though, I had mistakenly and embarrassingly left “Mars” in the title of the post). It’s worth noting that the steps that I laid out also apply to the JDK 9 Early Access with Project Jigsaw (Java modularity) builds. Eclipse Neon works on Jigsaw. I’ve been using this combination for real development on some new plug-ins that I’ve been tinkering with (more on that later).
Developing some new plug-ins using Eclipse Neon M2 running on JDK 9 + Jigsaw.
In its current form, Jigsaw provides a well-defined visibility model that manages what pieces of a module are accessible from other modules. As part of this, it prevents you from accessing internal code. We’ve been warned for years, for example, that using com.sun.* packages is verboten and Jigsaw aims to do something about it. The modularized JDK hides these internal packages from dependent modules and throws a fit when you try to access them (both the compiler and runtime).
As a “legacy” Java application running on the classpath, Eclipse IDE runs as what’s called an unnamed module (Voldemodule? the module that must not be named?) Unnamed modules have a special status in the runtime, but are still subject to the visibility restrictions. I’ll save a more detailed discussion of this for another post. My point today is that the Eclipse IDE just works on JDK 9 Jigsaw builds. This is true, at least, on the Fedora 22 and Windows 8 systems I’ve tested; I’m interested to learn of your experience.
The Jigsaw builds come with a handy tool, jdeps, which does all sorts of things related to module dependencies (note that this tool is only included with the Jigsaw builds). Included with the functionality is the ability to scan Java code to determine if it violates any of the restrictions enforced by the modularity model.
I ran jdeps on the Mars.1 repository to get a sense for how much work we might have ahead of us and was delightfully surprised by how few references Eclipse Project code has to internal APIs. Perhaps my biggest concern is that there is a reference to an internal class in the SWT_AWT bridge (bug 482318). I’ll open additional bugs as I investigate the other hits.
In the meantime, if you want to check out your own code for violations you can run jdeps yourself. The JDK 9 Early Access with Project Jigsaw builds are just archive files that you can decompress into the directory of your choice (it doesn’t update any paths or configuration on your system) and execute:
~/jdk1.9.0> bin/jdeps -jdkinternals /path/file.jar
Where /path/file.jar points to one or more files (e.g. ~/.p2/plugins/*.jar).
Correction: jdeps is included in Java 8 and 9 builds.
While I have your attention: be sure to propose a talk for EclipseCon 2016!
Eclipse Hints, Tips, and Random Musings 
Pingback: Visualizing Java 9 Module Relationships | Eclipse Hints, Tips, and Random Musings
Hi,
I am working on an enterprise software platform ( more on http://projet43.fr/english/ ), which I likely plan to release at some point next year. I am developing it on Eclipse (with only need for JSE and JDBC), and I am wondering when is the good time to start developping in java 9. I do not want to lose too much time with an immature platform, although it would be an advantage to release directly in Java 9.
Any thoughts ?
The short answer is to start targeting Java 9 when you need features that are specific to Java 9. Having a smaller runtime sounds like something that might be valuable for your applications, so experimenting with different image configurations is probably something that you’ll want to start doing earlier rather than later. I’ve been using Java 9 JREs for a while with the primary goal of rooting out problems. I haven’t had very many of them.
Hi Wayne,
you have blogged a lot about Eclipse and Java 9 in the past and I learned a lot from it but during my own experiments I stumbled over the question of how to make any of the modules usable in a project which are not in the java.* name space. I am especially interested to get JavaFX going but all its modules are in the invisible javafx.* name space. Could you provide me with some info on that?
Michael
I haven’t had a chance yet to test this, but there’s an -addmod switch (jep 261) that might do the job.
http://openjdk.java.net/jeps/261
Yes, but where do you place that in Eclipse? It is a compile-time as well as a run-time switch. Or is configuring the new module system just not yet implemented?