Thursday 30 December 2010

What about JSR-310?

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:

Anyone can access these javadoc files by just clicking a link on the JSR 310 website at Stephen says, "We always intended to run the JSR as an open source project. That naturally means public code, and feedback. Collecting the feedback is easier if people can access it by the method they are most familiar with -- javadoc." Some Spec Leads may be reluctant to run their projects as openly as this, but Stephen has no qualms at all. He says, "It's often thought that being open will increase the mails and issues you have to deal with. The reality is that you tend to have to address the real issues earlier than you might otherwise have to, and that is a very good thing."

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 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.

Stephen Colebourne
Project lead, ThreeTen
Co-spec lead, JSR-310


  1. Thanks so much for also making the actual JSR 310 specification available without having to go through the horrible (and free software incompatible) legalese of the JCP JSR click-through license!

  2. TenPastThree? Would make the time based metaphor a little bit more obvious.

  3. Thank you SIR...... we dont know the politics.. we dont want to be jobless either..We want you all to push java forward..thanks..

  4. Although the effort by Stephen may or may not be in the best interests of the Java community, the attitude of "we don't know the politics and we don't want to be jobless either" is not the right one for an open-source project - as open (or not) as the JDK may be. We should care and participate.

    Even if Java deadlocked (if everyone blocked the JSRs for Java 7/8) and turned up dead in the water, the body of software it can run would still be accessible by more modern languages, like Scala, Groove, Ruby, etc which also run in the JVM and interoperate easily with legacy code.

    finally, there are alternatives to the Java date functions (Joda comes to mind) so no one would be jobless because of that either!

  5. GH: Stephen is the author of JodaTime, and he decided to base JSR-310 on a new codebase because as he went down into the murky morass of dates and times he realized that there were some serious problems with JodaTime that only a rewrite would solve.

    That being said, I actually believe this is about the best compromise that we can get in the situation: there's the prospect of a JSR (which is the only way to get the full package supported by the rest of Java land [JMS, JDBC, and JAXB spring to mind immediately]), as well as a good reference implementation we can use if the politics of the JSR descend any further into farce.

    And as the CEO/CTO of OpenGamma (Stephen's employer), let me say that we decided early on to make a big bet on JSR-310, and we're extraordinarily happy we did. Dates and times are fundamental to pretty much any financial system, and the flexibility and power of the new libraries has helped us immeasurably along the way, and we're very happy to sponsor Stephen's time working on JSR-310 and the ThreeTen implementation.

  6. Philippe Marschall30 December 2010 at 22:43

    Thank you for continuing this, it is much appreciated.

  7. Wasn't it back in 2008 that you and Michael announced the completion of the jsr-310 implementation, and were paid by Sun Microsystems for it? I would have thought that would be the end of it; for a completed and paid-for project, you're sure dragging Sun (now Oracle), and the community, though the ringer to get what they paid for.

  8. Stephen Colebourne30 December 2010 at 23:34

    Thanks to most of you for your support.

    And a Happy New Year to you Neal ;-) BTW, the first link says "It should be noted that the JSR is unlikely to be complete within the
    timeframe of the challenge." - and as expected, it wasn't. Although money changed hands, it was not payment for work as in a contract, but a prize in a competition. See the challenge FAQ - "It is an award program designed to encourage developers to contribute new ideas, drive new projects, and collaborate to further the goals of the OpenJDK Community and of open source Java: to foster more adoption, accelerate innovation, and create new opportunities for the OpenJDK code base and for Java SE." Would you prefer me to stop work? or include a half-finished project into the JDK?

  9. Hi Stephen and thank you for the clarification.

    I have been thinking alot lateley about the JCP mess and Apache.
    Do you know the stand of ASF when considering new projects under the ASF umbrella with regards to languages? I have been using Apache as my web server of choice and many Java tools that came from Apache (JServ/Tomcat,Ant, Maven etc.)

    It would be nice to get some hints from the foundation. I for one is done with "new" server based development in Java unless my customer demands it. I'm looking at Go(lang) from Google and it looks promising.

    Anyway. Enough with this rant. Have a Happy New Year and a great 2011.


  10. It seems that people are never pleased with the Java development and community process, but are OK with Microsoft .NET or Google Android, despite the closeness of their development model. Google never forget to say how they are the savior of open Source Java, but contrary to OpenJDK, they do all their development under closed walls. There is no discussion on what features will be included in Android, when they will be available, and no project involving the community in the core of the framework. You can only be fed what google wanted to include in the platform, when they feel appropriate to do. That's not what I call an Open development process at all. But nobody criticize them. It seems that their never-ending marketing campaign is doing well.

    I would very much like to see less criticisms on an inherently open platform (this is why so much people are lamenting on the JCP, because there is so much way to express your opinions - or displeasure - on how Java is involving), and more on some high profiles projects which only mimic as opened.

    But it seems that all this campaign (which is not new, and ended with Sun not able to sustain itself) is somehow leaded by some well_known contenders such as Microsoft and Google (yesterday it was IBM too).

    All of this can only end in one way: giving the key to Microsoft (.NET is as closed as it can be), or Googles (we have yet to see a community in the building of the platform).

  11. Stephen Colebourne31 December 2010 at 14:56

    @Bjorn, The ASF has no real position on programming languages, so long as the code produced using the language can be released using the Apache license v2 (which is pretty much any language including Java). The ASF isn't a top-down company mandating what is used, its a bottom-up project-led organisation. Personally, I think the language called "go" (which should be renamed) isn't a suitable replacement for Java, and I think D is probably a better replacement for C.

    @Herve, My objections are simply to companies that break their word (Sun, then Oracle) - I'm sure other companies have also broken their word, but with 10 million developers, Java is a little special in the IT world. I have and continue to recognise that Oracle are putting in more cash than Sun, and are a little more open than .NET or Android.

  12. I guess you shouldn't have been that critical about all these entities like Red Hat, Eclipse, Intel, etc. then, if you follow their example.

    Is it only me who smells this hypocrisy combined with that imagination of not being replaceable ("Someone else might take over the project, perhaps causing another poor Java SE date and time library.")?

    I guess if you fear that Oracle takes over your project then just don't give them your copyright (Sun/Oracle still expect that, if your RI will be used in OpenJDK, right?).

    But I guess if Oracle would take it over the project would be finished already ...

  13. @Stephen Do you have a feeling when the RI for JSR-310 will be done? (I didn't see anything on the project page.)

  14. Speaking of a Happy New Year :) Thanks for your continued efforts Stephen!

  15. @Stephen: When Sun was still there, they had to fear the project to be taken over for their own interests by IBM and others. IBM used Harmony to try to take the lead on Java, that was the reason why they were really not pleased by the news that Sun's JDK has been open sourced as GPL , and not Apache, because they could not do what they wanted with the code. Then Google used Harmony, only because they thought that by using Harmony could also do as they pleased with the code.Wich they did sadly, using Dalvik only not to have to use HotSpot.

    The problem is that all these companies (IBM, Google, and even oracle at the time) seemed to want to help Sun in their work on Java, leaving to Sun all the work, and trying to take all the benefits or themselves. The Android case is astonishing, because clearly Google monetized their platform (which is their absolute right) without giving anything to those who developed the framework they used (it's the case for Java, but it is also the case for the Linux kernel).

    I feel that we would never have been in this situation if these contenders had showed ANY willingness to share some of their benefits. As it was (and still is) not the case, we had to be now in this situation.

    I'm still wondering how Google could have been so bold as to think that by not collaborating with Sun at all, the future would still be bright for them. They should have been aware that Sun was not well and would be bought if they did not helped them a little, or at least worked with them on OpenJDK. Sun could also have been bought by IBM, as everyone knows, and the result for Google would have been exactly the same.

  16. On my previous comment, "The problem is that all these companies (IBM, Google, and even oracle at the time) seemed to want to help Sun in their work on Java" should be replaced by "The problem is that all these companies (IBM, Google, and even oracle at the time) seemed not to want to help Sun in their work on Java"

  17. I am also critical of Oracle's approach to Java's long pending JSR's.

  18. The situation is simply that Sun was not focused on anything that was a sustainable business. The should of opened a Java APP store, the moment that Apple started theirs. Apple is now going to the desktop with the latest app store instance and that agreement says "no deprecated technologies allowed" and lo and behold, a month or more before, Java was deprecated on the Apple platform.

    Guess what, the non-technical community of the world is not interested in "open source". They are interested in affordable, supported products that meet their needs... So, Apple continues to sell products using their "closed" platform.

    Sun wanted to make big money on a few instances of "product" instead of understanding the concept of "small money" on everything with lots of opportunities everywhere. Apple is capitalizing on this!

    Oracle is now going after the "big money" in a few places by playing the software patent game. As Jonathan used to say, "Just innovate". I think that Google is innovating in the mobile device arena with Java in a way which the collective JCP and the JME platform had never been able to do.

    The open handset alliance seems to have attracted a lot of people interested in this form of innovation.

    Oracle stands to loose a lot of their "few" JME licensees. Due to their apparent "big money" from the "big players" attitude, they seem focused on quenching innovation without caring about how the existence of that platform would allow them to make even more money by making a desktop environment that provided portability into a desktop app store might cause Android developers to bring their applications to the desktop too. Apple sees this...

    Sun didn't need help taking care of Java. Sun needed to make Java a valuable platform to the desktop and mobile developers. They needed to understand the bigger picture.

    I, and others that participated in the Sun Developer Advisory Council saw how Sun was torn by the big exec's screaming big software on big hardware is important. All the time, even James Gosling was telling them that Sun must make small software on small systems work well.

    There are all kinds of things that Sun "tried", but they didn't know how to succeed and the engineers at Sun had little experience with desktop software systems, and thus really spent a huge amount of time just learning (look at the Java-4 to Java-5 Swing development around Vista's arrival where the whole rendering engine broke because it was written completely wrong to start with).

    What is happening with ThreeTen is what many people had already done who had any interaction with Sun and the JCP. There were some very irresponsible and very uneducated VPs at Sun who really thought they knew what to do, and they would not listen to anyone. Jonathan threw one of them out the door around the openjdk project... But it was already too late at that point. The damage had been done...


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.