Project Jigsaw Late for the Train: Deferment ratified

Back in July Oracle chief architect Mark Reinhold's blog piece Project Jigsaw: Late for the Train proposed deferring Project Jigsaw from its originally scheduled release in Java 8 for at least 2 years until Java 9.

In his responsa blog-entry Reinhold addressed most of the key questions, and discussed history, rationale, and alternatives.

In summary, Reinhold explained that the JDK modularization is complex, and Sun Microsystems could not sufficiently staff it. Adopting existing technologies such as OSGi and Maven was not an option, as these do not address all of the requirements.

One commentary went as far as to propose reappropriating Project Lambda staff to work on Jigsaw, delaying Project Lambda to Java 9, but Reinhold classified that as unfeasible.

One proposal however remained unanswered in full detail:

Project Jigsaw consists of two phases. As Reinhold describes them:

In the first phase we're exploring an approach to modularity that's markedly different from that of existing Java modularity solutions. We've assumed that we can change the Java programming language, the virtual machine, and the APIs. Doing so enables a design which can strongly enforce module boundaries in all program phases, from compilation to deployment to execution. That, in turn, leads to better usability, diagnosability, security, and performance. The ultimate goal of the first phase is produce a working prototype which can inform the work of the Module-System JSR EG.

The second phase will produce the reference implementation of the specification created by the Module-System JSR EG. The EG might ultimately choose an entirely different approach than the one we're exploring now. If and when that happens then Project Jigsaw will change course as necessary, but either way I think that the end result will be better for having been informed by our current work.

So why not deliver the ostensibly simpler first phase in Java 8 and just defer the second phase to Java 9? Reinhold responded:

If we deliver a module system in one release but don't use it to modularize the JDK until some later release then we run a big risk of getting something fundamentally wrong. If that happens then we'd have to fix it in the later release, and fixing fundamental design flaws after the fact almost always leads to a poor end result.

Since my impression is that we lack a clear strategy for making this happen in time for SE 8 without badly delaying it, I vote aye.

Providing a modularization framework is a key deliverable, and the risk of delivering that phase independently is substantially smaller than the actual JDK modularization. It would be interesting to learn whether or not our readers feel it is worth the risk to provide this key deliverable early, in Java 8, and defer the JDK modularization to Java 9?

If you have a different perspective let's hear your opinion in the comments below.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

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.