Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Eclipse IDE on JDK 9 Early Access With Project Jigsaw

DZone's Guide to

Eclipse IDE on JDK 9 Early Access With Project Jigsaw

Read about how one developer has been doing real development with Java 9's new Jigsaw modularity in Eclipse Neon.

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

A few weeks ago I wrote 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).

Eclipse Neon running on JDK 9 + Jigsaw

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!

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:
eclipse ,java 9 ,jigsaw

Published at DZone with permission of Wayne Beaton, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}