Skip to main content

There are a lot of opinion pieces about Jigsaw and the recent vote. Most of them are titled “Jigsaw Rejected,” or “Back to the Drawing Board.” In 28 days time you will read articles that have titles like “JCP has Change of Heart on Jigsaw” and “Jigsaw Approved in Java 9.”

Would it surprise you to learn that there are 2 to 3 more votes ahead?

You might now be thinking, “If there are so many votes ahead, how could Jigsaw have been rejected?” The short answer, it wasn’t.

Unless we learn the JCP process, we could be seeing up to 4 votes, this one included, after which everyone will be pronouncing Jigsaw dead, then alive, then dead again, then alive again.

There Was No Vote Rejecting Jigsaw

The vote this week was effectively, “Should Jigsaw move to the next phase of the JCP process?” There was no vote to include Jigsaw in Java 9. There was no vote to exclude Jigsaw in Java 9. We are not there yet.

A JSR has effectively 3 moments where Executive Committee (EC) voting is involved; JSR Approval, Public Review, Final Approval. At each of these moments there is the possibility for exactly one 30-day extension, after which there is another vote. The EC must vote “No” to get that extension. This means as a JSR you’re looking at a minimum of 3 votes and a maximum of 6. All votes are 15 days long.

The EC cannot get more than 15 days to vote. The JSR cannot get more than one extension once it puts itself up for a vote.

Now you might be thinking, “Wait, what happens after 30 days if the JSR does not remedy what is needed?” Short answer, it’s done. Full stop. You’re not “still in that phase,” you’re out of the JCP process. Game over. You’re welcome to start a new JSR, but that one is done.

Pretty severe, right?

What happened with this week’s vote is effectively Jigsaw was given a 30-day extension on this phase. The next phase is the last one. Should there be disagreement, legal issues, or any showstoppers at that phase, Oracle would be in the extremely unrealistic and terrible position to have to remedy all of them in 30 days or JSR-376 would be forever dead.

How fun does that sound? Not fun at all.

The Danger of “Yes, with Conditions”

In situations where a JSR has issues a JCP EC member feels really need to be resolved, it has been a common practice to vote “yes” and list the issues with a clear conditional statement they must be resolved or the next vote will be “No.” This is called “Yes with conditions” and it has some dangers.

JSR-299 Contexts and Dependency Injection (CDI) 1.0 passed the Public Review Ballot with several yes-with-conditions votes in February 2009. It then took 9 months to resolve all the issues before CDI 1.0 could be confidently put up for a Final Approval Ballot in November where it passed in December. As a result Java EE 6 was delayed, missing JavaOne — the biggest marketing moment of the year — and landing in December — the worst marketing moment of the year.

Those were some very fine-print yeses, no?

Being a spec-lead is a generous proposition where you round up your peers, solicit their hopes and dreams and then offer to pay for it. You get as far as you can with the budget and time you have, but eventually you need to close the lid and some people are not going to get what they want. It is the ultimate expectations-management challenge.

Now ask yourself, how does yes-with-conditions help that challenge at all? It doesn’t.

Think Past the Red

A yes-with-conditions vote on a Public Review Ballot keeps the responsibility entirely on the lead while the voter lists expectations and has no immediate responsibility. The spec lead will be very gun shy to call the Final Approval Ballot because the moment you do, your JSR will end in 15 to 45 days.

A no-with-conditions vote on a Public Review Ballot adds another vote into the process that wouldn’t otherwise be there and keeps pressure on both the spec lead and the EC. The EC member who voted No will need to stay very engaged in seeing their issues resolved as they’ll be required to vote again in 30 days. They’ll likely vote yes-with-conditions on that additional vote after the 30 days as voting “No” would kill the JSR, but we have still accomplished something:

  • The spec lead gets effectively 60 continuous days of EC attention (15+30+15) as opposed to just 15 days
  • The spec lead gets the luxury of a public statement from each EC member that the changes do or do not resolve the conditions
  • The 30-day window is not enough time to add significantly to the scope, therefore all parties must focus on what is truly important
  • The spec enters the next phase, just like it would have with a passing yes-with-conditions vote

The only downside is the red checkbox looks negative. A green checkbox looks positive, but you’re effectively opting out of all the above.

Does this Cause a Delay?

One could make the argument that the addtional 30 days causes delay. I’d argue it can significantly speed up jeopardized timelines as whether the conditions come with a red or green checkbox, they’ll still take time to resolve. A green checkbox with 5 big-ticket conditions is simply not helpful. Were I the VP who has to pull the trigger on the Final Approval Ballot knowing there are yes-with-conditions votes, I would desperately want the 30-day window to make changes and the ability to demand everyone come immediately back to the table for another vote.

Improving the JCP Process

In fact, if there was one change we could make, it might be to allow the spec lead to trigger the 30-day window and re-vote. Currently, these benefits can only be given to the spec lead by the EC via a no vote. There is no way for a lead to demand it if the vote passes, but with many conditions.

There is potentially some improvement on allowing EC members to trigger the 30 days without having to dress it in negativity. Certainly, some EC members who voted yes-with-conditions did so because of the concern for how it would look and not wanting to seem unappreciative of the spec lead and their dedication.

In the case of Jigsaw and Mark Reinhold, his dedication is unquestionable and progress is being made. Those of us who voted no were doing so to trigger the benefits. When it comes to Jigsaw, we can’t afford to be turning down any advantages.





David Blevins

David Blevins

David is a co-founder to OpenEJB (1999), Apache Geronimo (2003) and Apache TomEE (2011), 10-year member of the JCP serving in Java EE, EJB, CDI, JMS and Java EE Security JSRs, JavaOne RockStar for 2012 & 2013, 2015 inductee into the Java Champions and nominated for JCP Member of the Year 2015. He is a contributing author to Component-Based Software Engineering: “Putting the Pieces Together,” from Addison Wesley and a regular speaker at JavaOne, Devoxx, ApacheCon, OSCon, JAX and Java-focused conferences.
dblevins

Leave a Reply