The latest expert opinions, articles, and guides for the Java professional.

A Short History of Nearly Everything Java

The flow from idea to implemented feature

OK, we’ve had plenty of text and enough TLAs, so it’s time for a picture so describe all this. After all, the JCP is a process or pipeline, so it should be easy to depict as an image. Check this one out, which we grabbed from the JCP site:

short history of nearly everything java flow from idea to implemented feature

This pipeline shows a very optimistic timeline with reviews, drafts and ballots peppered throughout the process, which is very formally adhered to.

The first stage is the Initiation of the idea, the formalisation of the idea in the JSR format, the JCP EC vote on the JSR and then the creation of the EG. So essentially, a JSR is written up and submitted by a JCP member to the EC. The EC meet up every 2-4 weeks and go over new proposals that have been submitted and vote YES/NO as to whether this JSR should be developed. There could be many reasons for not accepting a JSR, from whether the area is mature enough to warrant standardisation to the submission simply not being complete enough. Should the EC members YES vote on the JSR, it’s development would commence, meaning the creation of an EG and typically the election of a spec lead, if different to the person who proposed the JSR.

Next, in the Early Draft phase, experts are added to the EG by JCP members proposing them. They create the first draft which will be made available to both the community and the EC for first draft review. Feedback from the EC and the community should be implemented back into the draft.

The next stage is the Public Review, which allows anyone who can access google and a keyboard to check it out and give feedback. This iterates through the feedback to provide a final draft which has an accompanying reference implementation, showing it can be used effectively and a TCK allowing others to implement the specification to a level of compatibility determined by the effectiveness of the TCK (This can vary wildly from TCK to TCK as shown by the varying levels of interoperability between implementations of JSRs)

The Proposed Final Draft is then voted upon by the EC and once cleared in the Final Approved Ballot, everyone can implement a final specification, celebrate with champagne, and boom: the world is a better place. Down the road a way, the JSR then enters Maintenance mode where requests to clarify, enhance or revise the specification occurs.

So, now we see the process, how can the community actually get involved so that we’re not providing important feedback to a JSR in the maintenance stage? Well, the JCP has been working on that…

Driving community participation with JCP.Next

JCP.Next is the process the JCP uses to evolve itself. In May 2011, Patrick Curran, the chair of the JCP, introduced JSR 348, the first in an initially three-part plan (now four parts), to meet the current needs of the Java developer community. JCP.Next changes the governance and membership agreements of the JCP program. It is a series of four JSRs, where we use the process to evolve the JCP Program:

JSR 348: Towards a new version of the Java Community Process was completed in 2011. This JSR made some simple but significant changes to promote transparency, agility, and participation. Most importantly, all Expert Groups are now obliged to carry out their work in public, so that anyone who is interested can observe, comment on, and participate in it.

JSR 355: The Executive Committee Merge, which was completed in 2013­, merged the two ECs into one EC.

JSR 358: A major revision of the Java Community Process is in progress now (but will take time to complete). This JSR will modify the JSPA as well as the Process implement more complex changes involving Intellectual Property rights and licensing.

JSR 364: Broadening JCP Membership is in progress now. This JSR will define new membership classes, changing existing membership categories and enabling broader participation by the community. The goal is to complete this JSR in 2014 and implement the changes in early 2015.

As you can see, the JCP is pretty serious about getting as many awesome developers, architects and hackers as possible involved in the future of Java. The problem is awareness–most of those 9 millions developers out there haven’t heard of or don’t care about any of this. So what can you do about it all? Well, we you asked. That’s the next chapter of this report, titled “What can you do about it all”… hehe…

The recent efforts of JCP.Next have removed the barriers for Java developers to participate in the technology they use and love. All members of the Java community can participate in the implementation of the platform through OpenJDK and GlassFish, and In the evolution of the platform through the JCP and Adopt­ a ­JSR programs. Java developers should get involved to move the entire Java ecosystem forward.


Responses (5)

  1. Avatar  

    Dmitry Leskov

    September 24, 2014 @ 8:47 am

    There is at least one more certified JVM that you did not mention: Excelsior JET ( Developed in Novosibirsk, Russia, it has been on the market since 2000, and was certified Java Compatible in 2005. The main distinctive feature of Excelsior JET is its Ahead-Of-Time (AOT) compiler, which takes your jar files as input and produces an optimized native executable for Windows, OS X, or Linux. AOT compilation benefits are dual: it hinders reverse engineering of your app, and at the same time improves the end-user experience through faster startup, smaller footprint and JRE-independency.

    Disclaimer: Yes, I work for Excelsior.

  2. Avatar  

    Chris Snyder

    September 24, 2014 @ 3:56 pm

    I used JET for a consumer software product at my old company. It allowed us to distribute our software without worrying about whether the customer had a JRE installed. It worked great, and Excelsior support was excellent (even though we were a tiny company not paying for a big support contract).

    I don’t have a use for JET now (everything is web-based for me at the moment), but I’m glad to hear that you’re still going strong. Keep up the good work!

  3. Avatar  

    Oleg Šelajev

    September 24, 2014 @ 4:59 pm

    Great point, Dmitry. For brevity, we didn’t describe all the existing JVM implementations, not even all the certified ones. Just the most major ones.

    So, big thanks for contributing the info!

  4. Avatar  

    Debbie Fuller

    September 25, 2014 @ 7:52 am

    Nice blog Oleg, but there is another certified JVM that was missed off from Waratek ( With a team of experienced dedicated JVM developers it is Oracle certified Java compatible and was initially developed to provide multitenancy with elastic memory and application isolation. (

    The containment and isolation that the in built hypervisor provided has since been expanded to provide ‘Runtime Application Self Protection’ for Java apps. This is the first time that RASP has been provided within the JVM. Because the JIT compiler can intelligently interpret messages, it avoids ‘false positives’ and ‘gracefully blocks’ attacks. This protects applications from SQLi, Zero Day attacks as well as providing virtual patching for Legacy Java. (

    We’re going to be at JavaOne and hope to meet up with you there!

    Disclaimer: Yes, I do work for Waratek!

  5. Avatar  

    Dmitry Leskov

    September 25, 2014 @ 1:18 pm

    Thank you for your kind words, Chris.

RSS feed for comments on this post.

Leave a comment