BT

Oracle Commit to Java Modularity

by Ben Evans on Nov 17, 2014 |

Oracle have announced the second set of enhancement proposals (known as JEPs) that will deliver features for Java 9, including major news about Java modularity.

The first round of features was announced on August 11th, and was a relatively modest, although useful, set of features. By contrast, this announcement contains some of the real meat for Java developers. Following the commitment made by Oracle that the delayed modularity project will ship as part of JDK 9, Oracle have produced a series of four JEPs to deliver a redesigned solution for Java modularity.

Oracle's Java engineering team have already delivered JEP 162 (Prepare for Modularization) and JEP 201 (Modular Source Code). The second of these JEPs completely changed the layout of the JDK source, and rearranged it to align with the new module boundaries. The description of the module system itself is contained in JEP 200, although this has not actually been delivered yet, presumably because the details may change depending upon issues encountered when building the implementation.

The new batch of JEPs includes JEP 220 (Modular Runtime Images), and this is effectively the point of no return for modularity. After this point, The Java runtime system will no longer be contained in jar files, and instead will be composed of modules. Files such as rt.jar and tools.jar will be a thing of the past. The new system will consist solely of modules, although the platform will continue to accept and run applications and libraries packaged as jar files. The intention is that over time, application developers wil migrate to the new modular formats as well.

Mark Reinhold, Chief Architect for the Java platform, commented that for the Java runtime system contained in the JRE and JDK: "The JAR format has run its course. It's time to move on". He also recognized that the move to a modular system will have major implications for IDEs, tool makers and many frameworks, as the current introspection mechanisms rely upon a URI syntax that is tied to the legacy JAR format.The outreach programme is being run by Oracle's Quality group, with community support from the London Java Community and a global group of JUGs under the AdoptOpenJDK and AdoptAJSR projects. A number of key open source projects have already been contacted, including Apache projects: Ant, Builds, log4j, Hadoop and CXF as well as Eclipse, Hudson, IntelliJ, RedHat Netty, Redhat Tools, TestNG.

Oracle are also preparing a draft of a Java Specification Request to cover the module system specification as a new Java standard.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2018? by Aldrich Wright

The change over to modules is huge. Any idea when we can expect to see this?

Mudballs? by Luke deGruchy

Seeing as there are many circular dependencies among the class libraries and that for the most part all public classes and methods are effectively exposed to the world, how will Oracle avoid having to create one or more large "mudball" modules for the JDK?

Re: 2018? by Ben Evans

Hi Aldrich,

The latest round of early access JDK 9 builds from Oracle now have modular runtime images, although the compatability layer isn't in yet. There are lots of opportunities to help here - if you'd like to participate, please contact myself or Martijn Verburg.

The current ship date for Java 9 has not been announced - I would expect it to be Autumn 2016 for 2 reasons 1) Oracle try to keep roughly a 2-year cadence between releases & 2) Java 8 went GA almost exactly 2 years after the M1 build was released. We don't have a roadmap or an M1 for Java 9 yet, but it can't be far off.

Ben

Re: Mudballs? by Ben Evans

Hi Luke,

Analysis of the dependencies has already been done, and whilst there is obviously a core that is necessary (essentially the transitive closure of types referenced by Object), the size of the java.base module may not be as large as you might expect.

As additional evidence, recall that Java 8 has Compact Profiles, which are substantially smaller than the full JRE.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.