So, if the Java Community Process is now a zombie Java Corporate Partnership, what should I do with JSR-310?
I've been highly critical of Oracle's stewardship of Java, particularly on the topic of the JCP. Choosing to U-turn on their previous public statements and force through the Java SE 7 and 8 JSRs was bad for Java and bad for Oracle. By accepting Oracle's actions, the remaining JCP executive committee members ended the notion of the JCP as an open standards body.
So, the question arises as to whether I should cut my ties with the JCP and terminate JSR-310.
The reasons to abandon the JSR are quite compelling:
- The JCP is no longer an open standards body.
- JSRs now exist that are in incompatible with the JSPA legal agreement.
- The Executive Committee has shown itself to be more willing to do Oracle's bidding than to hold them to account.
However, I must also ask what the result would be if I stopped the JSR:
- I would break a commitment I made to the community to improve dates and times in Jave SE.
- Someone else might take over the project, perhaps causing another poor Java SE date and time library.
- The majority of developers, those that don't read blogs and news sites, don't care about the corporate politics and would suffer without ever knowing why.
Ever been between a rock and a hard place?
The upside is that the process of the JCP provides all the power to the specification lead. So, since I, and Michael Nascimento, are the specification leads for JSR-310, we have all the power :-) Consider what I said when the JCP asked me about transparency:
The key phrase is "run the JSR as an open source project". Because if the JSR is an open source project then the status of the JCP is more of a detail, an annoyance.
So, while my heart might tell me to walk away from the zombie JCP, my head tells me that I really don't need to. This is just an open source project which the community badly needs. And the JCP is just a tool I can use to access Java SE 8. I dislike maven as a tool, yet I still use it - I can dislike the JCP and still use it in exactly the same way.
Therefore, I've decided to continue work on JSR-310, targetting Java SE 8.
I've also taken advantage of the impending destruction of the original java.net website to move the code and discussion to sourceforge, where I hold most of my other projects.
I've also chosen to give the reference implementation a real name - ThreeTen. So, the ThreeTen project is the reference implementation of JSR-310. Development of both the reference implementation and the JSR will occur at the ThreeTen project.
As part of this process I've attempted to clarify the legal position of contributions to the project, including discussion, without getting too legal. The concept is that the overriding principle is that the project works on trust and respect for the public good. Beyond that, version controlled contributions continue to use the BSD 3-clause license, and version controlled contributions destined for JSR-310 continue to require a contributor agreement. As such, existing mailing list subscribers need to resubscribe to the new mailing list.
I also leave open the option of writing a ThreeTen specification separate to the JSR-310 specification.
The aim of a ThreeTen specification would be to provide common terminology and behaviour at a higher level with the intention of sharing the knowledge gained to other areas of computing. This might be another language, library or specification, such as SQL or XML.
Finally, I'm pleased to confirm that I will continue to spend 20% of my work hours on ThreeTen/JSR-310 thanks to my employer OpenGamma where the project is a core part of their platform for financial analytics and risk management.
Project lead, ThreeTen
Co-spec lead, JSR-310