Wesley Reisz talks to Martijn Verburg, co-founder of the London Java Community and CEO of jClarity, about the JCP EC “no” vote on the Java Platform Module System (JPMS), which is due to be shipped as part of Java 9. The talk about what JPMS offers, how it works, what the no vote means and what happens next.

​Was the “no” vote a rejection of Jigsaw?

02:50 No, definitely not. If people carefully read the comments on the JCP page - any EC member that votes “no” has to leave commentary - they will see the vast majority of people are pretty happy with Jigsaw, and that modularity is the future of Java.

03:20 It sets the plumbing for future Java releases.

What was it then?

03:45 The “no” vote was, in my and the LJC’s opinion, was that the community hadn’t had time to test the specification out properly.

04:00 Since is such a core specification, if there is something fundamentally wrong, then it’s incredibly difficult to roll it back.

04:15 We thought more testing needed to happen about certain edge cases, and we needed to see major parts of the Java ecosystem - Maven, the OSGi folks, the JBoss modules folks and other build tools - needed to try the specification and that there weren’t any blockers.

Why was “no” so common?

04:40 Modularity is hard, and it was quite clear from the jigsaw and expert group mailing lists that there seemed to be a lot of open threads, or they were unsure and things haven’t been tested out.

05:00 There were more than five open threads still floating about at the time the vote was called. It was a case that it was very close, but perhaps wasn’t quite ready yet.

What was the original scope of Jigsaw?

05:40 The original scope was to modularise the Java runtime; a module system for Java itself.

06:00 A lot of the work was done in modularising the Java libraries themselves; a lot of that work was done in the Java 7 timeline, and most of that was done in the time of the Java 8 release, leading to the Compact profiles.

What benefits do I get from modularisation of the JVM?

06:20 It provides an awful lot more security around the core usage of Java;

06:30 It hides a bunch of Java APIs that are internal or not safe to use for a day-to-day Java developer;

06:45 There is a missing gap there in that some of the functionality needs to have safe counterparts provided.

07:00 There’s a strong commitment to creating a smaller Java at runtime, since Java is split into a set of smaller modules

07:15 The jlink tool, which is coming in Java 9, will allow applications to be deployed on a much smaller runtime, such that only install what they actually need.

07:30 The classic example is that any server-side application will not need any client-side GUIs, like AWT or Swing.

07:40 That will allow Java to start faster and run things on smaller devices, as well as faster deployments to cloud infrastructure.

What does that mean for rt.jar?

07:55 The rt.jar has gone away, and has been replaced with modules and a modulepath.

08:00 However, the classpath and the existing way of doing things is not going away.

08:10 If you deploy your existing Java application on Java 9 using the classpath, give or take a few small glitches, you should be able to run just fine.

So you’re not forced to use Jigsaw in Java 9?

08:35 Absolutely correct. We’re going to see the classpath exist for a very long time.

What happens to the classpath?

09:10 The new thing that’s coming is a modulepath, as a replacement for the classpath.

09:20 It’s a new much stricter construct that was causing consternation with the OSGi and JBoss Modules folks.

09:30 The modulepath module system and discovery with modules is much stricter with Jigsaw than it is with OSGi and JBoss Modules.

09:50 They are saying that it’s too strict to use with the existing module systems, or to use them effectively, and that’s a clash between two opposing points of view.

The scope was to break down rt.jar though, rather than work with other module systems?

10:15 Most people should see Jigsaw and the module system for the JVM itself; it’s possible for developers to use it to modularise their own applications, but it was not designed for strong compatibility with other module systems.

10:40 However, the JSR did state it had some rough goals that it would try to minimise harm to the ecosystem at large, and that’s the problem since it will cause harm to the existing module systems since they can’t be deployed effectively on top of Jigsaw.

Can you explain the role of the EC in the JCP?

11:30 We meed face-to-face three times a year, and calls monthly for the rest of the year, and there’s regular discussions on the EC mailing list - so it’s a continuous activity rather than a point in time activity.

11:40 Voting periods can come up whenever JSRs go through their normal lifecycle; but all EC members are expected to vote on them when they come up.

What are the upcoming votes for Jigsaw?

12:10 When a JSR goes through its lifecycle it goes through stages. Jigsaw is at the Public Review stage, but there are further votes that happen after that.

12:25 There’s a Proposed Final Draft stage, which Jigsaw still has to go through before going GA effectively, and you can see the stages at JCP.org.

12:45 Even though there was a “no” vote at this point doesn’t mean that it’s the end of Jigsaw, as there are future votes coming up.

There’s another vote in 30 days, correct?

13:00 Yes, the expert group and spec leads can choose to resubmit within 30 days, and that will allow the EC to vote again, and assuming the vote is “yes” it will continue on to its next stage.

What if there’s another “no” vote?

13:15 If there’s another “no” vote then according to the official JSR rules, effectively Jigsaw is killed.

13:25 However, there’s no cause for concern - if you look at the “no” votes, most of them said that they had seen a bunch of issues resolved during the voting period, and it needs a month’s testing with those resolutions in place before the next vote.

So the vote was on the content of Jigsaw at the start of the vote, rather than anything else?

14:05 That is correct, yes. Even if it had been on the day of the last submission, I still think “no” would have been voted on, simply because of the lack of testing.

Was there consensus?

14:45 A couple of the EC members certainly felt that way; it was certainly unusual that the review got posted to the EC in the first place.

14:50 None of the JSR expert group (except for the spec lead) thought it was ready to go through to a vote, which is unusual.

14:55 That’s what IBM in particular was referring to that the expert group wasn’t in consensus regarding the readiness of the JSR.

15:05 You would hope that the majority of an expert group would be in alignment.

This isn’t without precedent?

15:25 The CDI (JSR299 for JavaEE 5) vote was the only one that I can think of, and that was delayed as a result.

15:30 It’s a good thing that it doesn’t happen too often; it shows that a lot of hard work and due diligence goes into these specifications, and I think in this case the EC has worked as intended.

15:45 It must be frustrating for the Jigsaw team - they’ve been working hard at this for 7 years now, and they’ve put in a lot of good work with a difficult piece of engineering.

15:55 But that said, there are people outside of that team do have different communities and different viewpoints which that team simply isn’t aware of day to day, and the EC is the last stop-gap measure that those communities are taken into account.

What do you foresee happening?

16:15 Within the next 30 days, Mark Reinhold has already posted to the mailing list that he will be holding a daily call with all of the expert group members and other interested parties.

16:30 The London Java Community will be doing hands-on testing of these last minute resolutions, holding hack days making sure that what the specification says is implemented (or implementable).

16:40 We might see a resubmission with a few weeks time.

What is still outstanding?

16:55 We have not been able to test the automatic module names, the new naming feature.

17:05 When you modularise your application and depend on a bunch of other third-party modules that aren’t modularised, there’s a very quick way to give them a module name based on the file name.

17:25 This provides a transition path for libraries to move to a modular world.

17:45 Relying on file names for module names wouldn’t have worked for Maven, which as it is a de-facto standard for building systems would have caused problems.

17:55 Reflection isn’t being blocked entirely but there is stronger encapsulation system inside the module system.

18:15 In a classpath system, reflection can allow you to see anything on the classpath. Inside a module system, you’ll only be able to see the contents of the module on the modulepath.

18:25 That’s something which JBoss module and OSGi folks are still unhappy about; whether it will be resolved when Jigsaw is released I don’t know, but it’s not something that the LJC would vote “no” about.

Isn’t the point of Jigsaw to provide that isolation?

18:55 The argument from the JBoss modules and OSGi folks run in complicated environments where pragmatically it just needs to happen.

19:15 I personally think the new module system can find ways in the future to securely open the mechanisms that these other module systems need to allow them to achieve what is necessary without having a free-for-all access.

19:30 A lot of people have the misconception that Jigsaw is done and won’t be updated, but I’m pretty sure that Mark Reinhold and the rest of his team have got several more ideas and implementation details for future versions of Java to make the module system more accessible.

Any other issues that could torpedo Jigsaw?

20:00 The one other issue - which appears to already be resolved - is that the Eclipse compiler team, who create the independent Java compiler ecj, popped up to the mailing lists and said that they weren’t confident that they could create an independent implementation.

20:20 That’s the whole purpose of the JCP - it exists to make sure that specifications can be implemented by people other than the spec lead.

20:30 It was a blocker, but it has since been resolved. Alex Buckley from Oracle has been working hard with the Eclipse team to resolve the issues.

20:45 My understanding talking to the Eclipse lead is that the issues have been resolved and they are happy going forwards.

So there’s a lot of work to be done in the next few weeks?

21:30 Yeah, there’s going to be a lot of hard work in the next few weeks.

21:40 There’s going to be a lot of intense debate - but it’s a unique community, there’s so many different vendors and interest groups - and they all have Java’s best interests in heart: no-one wants to see Java 9 delayed, but they want to see that Java’s around in 10, 15, 20 years time, and we have to get the module system right - or right enough that we don’t back ourselves into a corner that we can’t get out of.

Additional Resources

News about JPMS

Simon Ritter’s talk on Project Jigsaw in JDK 9