The Vote That Didn’t Pass

I’m sure you’ve heard Tuesday’s big news: The public review ballot for JSR 376 did not pass! That leaves is with a lot of questions so let’s dive right in.

Who Voted What?

Let’s start off with a quick summary of the votes and some of the more interesting reasons that were given. The first vote came from IBM and established the mood of many to come: a “No” with a reference to somewhat nebulous technical reasons and the desire for more consensus in the expert group (EG).

The JSR 376 Expert Group and the public have raised a number of reasonable issues and concerns with the current public review draft of the specification that warrant further discussion and resolution. […] IBM would like to see closer consensus amongst the entire Expert Group before this specification proceeds to the next step.

Similar opinions, sometimes with more specific reasons, were expressed by Werner Keil, Hazelcast (problems for build tools), Software AG (automatic modules, cyclic dependencies, package isolation), Credit Suisse (automatic modules, reflection), SAP (insufficient specification), London Java Community, Ivar Grimstad, Twitter (package isolation), Eclipse Foundation (insufficient specification), Hewlett Packard, and Tomitribe.

Given their recently published concerns, Red Hat of course voted “No”. They gave a little more detail than most other members, though, for example by clarifying their focus:

from a middleware/SE developer perspective we believe that Jigsaw does not fulfil its original goals of being a module system which can be used by the likes of Java EE

Red Hat explained that they proposed solutions to the mailing list, which were often rejected, and also mentioned the lack of community consensus.

Many members who voted “Yes” gave no reason, a few stated that they shared some concerns but were basing their agreement on the assumption that they would be fixed before the next ballot: Oracle (surprise!), Intel, NXP Semiconductors, Goldman Sachs, Azul, MicroDoc, Gemalto M2M, V2COM, SouJava (clearer specification), and Fujitsu.

I find it important to note that many members, starting with SAP, lauded the work of the Jigsaw team and thus tried to improve the mood (or soften the blow).

We absolutely recognize the tremendous achievements and the great work that has been carried out until now — by the expert group members as well as (and especially) by the spec lead himself.

Many members also noted that the progress in the recent weeks gave them confidence that things will be resolved soon. I find that rather curious and will come back to it later.

About That Consensus…

The most often cited reason for a “No” was the lack of consensus within the EG. I don’t quite know what to make of that. Consensus is nice, of course, but is a lack thereof really a reason to vote against something as technical as a Java Specification Request? Why base your vote on whether people agree on something that you have all the resources to check for yourself? I have to admit, it sounds lazy.

What I can absolutely understand are technical concerns but again I find those votes lazy that just say “there are issues”. I mean, Jigsaw brings a module system, something that is by nature strict, into an ecosystem that for two decades didn’t give a fuck about any boundaries between artifacts (and suffered the consequences) — how can there not be issues?

So if a member thinks some design decisions were wrong, I would expect them to name them and articulate their stance on it — not necessarily as part of their vote but somewhere at some point.

Examples of this are Red Hat and IBM, who have long participated in the discussion on the mailing list and made clear which technical decisions they disagree with. That’s how I think an open process is supposed to work and even though I disagree with many of their opinions they expressed them consistently and in a way that allows the Jigsaw team to act on them if they think that’s prudent.

What Happens Now?

The JCP is very precise on this:

If the Public Draft Specification Ballot fails, the Expert Group will have 30 days to update the draft in response to the concerns raised by the EC and to submit a revised version to the PMO. If a revised draft is not received within 30 days, the original decision by the EC shall stand and the PMO will declare the JSR closed.

So Mark Reinhold, the specification lead, has 30 days to change enough of the module system to sway the critics before calling a reconsideration ballot, where JSR 367 will pass if it gets 2/3 of the votes that were cast.

Will The Next Vote Pass?

As I said, many “No” votes were lacking specificity, so it is hard to predict under which exact circumstances they might change. Most apparently refer to the wider criticism that Jigsaw solves too few actual problems while introducing new ones.

After reading the different accounts (particularly interesting are David M. Lloyd’s for Red Hat and Tim Ellison’s for IBM) I think it is fair to say that most votes would go “Yes” if the following were to happen (unless someone on the EG disagrees, of course, because “consensus”):

isolate modules (which would also allow multiple versions); likely by having a class loader per module

allow cyclic dependencies

improve support for integrating other module systems (often referred to as layer/module primitives)

improve migration story around automatic modules

give reflection its superpowers back

Regarding the validity of the Jigsaw team’s design decisions underlying those (and other) JPMS traits I refer you to a great post by Rafael Winterhalter, which puts many things in perspective and with which I full-heartedly agree. Here I want to discuss how likely I think it is that these things will change within the next 30 days:

module isolation via class loaders is utterly unrealistic because it is a lot of work to get right and causes too many compatibility concerns to be ironed out in one month

the deliberate decision to forbid cyclic dependencies is unlikely to be reverted (because it is a good decision)

the support for other module systems might happen but is currently being fought by Mark Reinhold because it would expose module system internals that were not designed for wider use

the issues around automatic modules seem to have been resolved

the fight between reflection and encapsulation is over and reflection has lost; no way is the Jigsaw team going to go back on that decision

So I don’t actually think much will change within the next 30 days. But hasn’t there been so much progress over the last weeks? Regarding that: no there hasn’t. There was a great decision regarding automatic modules (and I’m going to get into that right away) and lots of small clarifications but I see little evidence that speed has picked up recently — on the contrary, if it changed, it was more of a slowing down.

Going out on a limb I want to dare a partial prediction: Red Hat’s and IBM’s concerns will go largely unaddressed and the public discussion will focus on a few small things that people will fight over — in the end both will vote “No”. I think that’s fair because they are evidently concerned.

What will the rest of the committee do? Without appeasing Red Hat, there won’t be much more consensus than there is now and with the larger quarrels with Jigsaw unabated (particularly module isolation), the technical reasons for their “No” will still stand. So the real question is this: Are the members sufficiently convinced of their given arguments to kill JSR 376?