javajigsaw

What does this most recent 8-week delay mean for Java 9 and Project Jigsaw?

Project Jigsaw is notorious for delaying Java release dates and being deferred to future versions, and its legacy of causing delays lives on. And on. And on.

Recently, members of the Java Community Process (JCP) Executive Committee raised concerns over Project Jigsaw’s viability in non-trivial issues such as implementation and compatibility with existing developer code. After a ‘no vote’ coming from the majority of the Executive Committee (EC) and the 30-day fixed period allowing for further discussion, we are once again being asked to patiently wait for Java 9’s General Availability release.

Update your calendars, Java 9 is now expected to be released for General Availability on September 21st!

Piecing Together Project Jigsaw

Per specifications of JSR 376 (commonly known as Project Jigsaw), the project is meant to design a scalable module system for the Java SE Platform that is easy to learn and use by all members of the Java community. Instituting modularization in the Java SE Platform with compatibility in the EE Platform, though, is no easy task.

A divided EC recently voted against releasing the project from the Public Review stage with many members citing the difficulties that developers will face when integrating existing projects and programs.

The two most vocal naysayers in the vote were IBM and Red Hat, which both have vested interests in existing module systems, JBoss and OSGi. In its current state, the specification doesn’t provide for interoperability between Jigsaw and these two module systems. This is sure to be disruptive for some developers if it is not addressed before Jigsaw’s release.

New Developments Now and Looking Forward

Several other members that voted against the draft commented at the time that they strongly felt that this issue and others still needed to be resolved by the Spec Lead and the Expert Group (EG). In voting no, these members noted that substantial progress could be made leading to a subsequent vote, and they would ultimately vote yes if more of a consensus could be reached by the EG.

In the 30 days following the vote, the Expert Group worked to address the concerns of the Executive Committee. The group was able to make “important changes relating to migration and the default behavior of JPMS” according to a post written by IBM’s Tim Ellison. Along with additional clarifications, these changes are expected to have a positive impact on the outcome of a future vote.

Despite the opposing positions of members of the EC, there seems to be a general agreement among them and the larger community that Jigsaw, without these important developments, could lead to the fragmentation of the community and cause irreparable damage in a rapidly changing Java ecosystem.

On May 30th, the Spec Lead and Chief Architect of the Java Platform Group at Oracle, Mark Reinhold sent a proposed schedule change to the OpenJDK Mailing list which was not met with any objections. As of June 7th, the Java 9 release schedule was officially updated to reflect the newest 8-week delay from July 27th to September 21st.

Final Thoughts

Before this announcement, we were all waiting for the EC to vote on a revised spec following the 30-day fixed period. Clearly, Mark Reinhold understood that the vote would not have a favorable outcome and that more time for revision was needed.

In an open letter to the EC posted before the initial vote, Reinhold mused that if they voted no (which they did), Project Jigsaw could potentially be delayed for years. This new delay is a short one, just 8 weeks, but the project’s volatile track record suggests that this might not be our last disappointment of this kind.

email
Yoda

Looking for more posts like this?

Join our force of more than 30,000 Java Jedi masters!

Watch a live demo
Yoda
Tali studied theoretical mathematics at Northeastern University and loves to explore the intersection of numbers and the human condition. In her free time, she enjoys drawing and spending time with animals.
  • Urban Fighta

    the obsession of backward compatibility in java community is not healthy what should have done is obvious: create a alternative way to do things and deprecate old way and in the next release let the deprecated way rot in hell!

    Java should be only compatible with previous version that is enough for all reasonable devs. This process has examples for Java itself but it is not used enough.

  • martinez45234

    Every educators are like this Java programming education and i hope they can learn so more well from you. To upgrade their programming knowledge it will be so more well guideline for them.

  • saxon98745178

    Every educators are like this Java programming education and i hope they can learn so more well from you. To upgrade their programming knowledge it will be so more well guideline for them.