The latest expert opinions, articles, and guides for the Java professional.
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:
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.
– ANONYMOUS EXPERT
Leave a comment