You are currently browsing the monthly archive for June 2017.

TLDR

We voted “Yes” for the re-submission of this specification within.  Jigsaw and Java 9 will represent a solid foundation for a new evolution of the Java platform, one that is nimbler, more lightweight and more secure.  Is this work complete?  No, there are still outstanding issues and feature requests to go, especially as the ecosystem learns to use the new modulepath and friends.  But the basis is sound and we think a large minority will take up the new module system once Java 9 goes GA.

The results of the vote on the reconsideration ballot (Public Review) for this JSR are here: https://jcp.org/en/jsr/results?id=6016

We voted no the first time around because we wanted to see final consensus on the last few outstanding issues as well as some bedding in time of recent, far-reaching consensus decisions.

Our official comment

The LJC votes yes and echos IBM’s thanks to Oracle (as the specification leader) and those in the JSR 376 Expert Group who dedicated their time to reworking and clarifying areas of the specification that we were concerned about.

The LJCs concerns (https://londonjavacommunity.wordpress.com/2017/05/09/explanation-of-our-no-vote-on-jsr-376-java-platform-module-system/) over interoperability with the Java ecosystems defacto build tool / module repository (Apache Maven) have been addressed as have the concerns over the ability for independent implementations of the compiler to be built (noticeably ejc).

The disposition of outstanding issues as agreed amongst the Expert Group was handled really well and it was heartening to see the evident collaboration as described in the detailed minutes of the EG’s meetings in the past month.

We see this release of JPMS as the strong foundation for a new Java SE platform architecture, and expect to build upon this with feedback and experience from Java User Group members.

Further Notes

The specific technical details of what was agreed and what was deferred are in the minutes:

Some highlights include:

  • Agreement on version name format(s).
  • Agreement on rules around Automatic Module Naming and a guide on how to best use those (important for the Maven ecosystem).
  • Dealing with multiple versions of the same module was deferred.
  • Agreement on relaxing Strong encapsulation as a default (means fewer apps will break out of the box, but get a warning instead).
  • Tidying up on some keyword usage (allowing the Eclipse compiler to be built).

We think the Spec lead and EG did a great job in coming together to resolve the outstanding concerns and hope that this can be a model for further collaboration over particularly far-reaching / complex part of the Java ecosystem development going forwards.

Cheers,
Martijn (on behalf of the LJC JCP Committee, on behalf of the LJC)

What is the LJC

The London Java Community (LJC) is a group of Java Enthusiasts who are interested in benefiting from shared knowledge in the industry. Through our forum and regular meetings you can keep in touch with the latest industry developments, learn new Java (& other JVM) technologies, meet other developers, discuss technical/non technical issues and network further throughout the Java Community.

Twitterfeed