What We Look For in a JSR

During our most recent JCP meeting we decided that we should write down the criteria we apply when deciding how to vote on a JSR.  Most of the criteria derive from our desire to represent a large body of developers.  None of the criteria represent absolute lines in the sand.  We are willing to compromise on some or all of the areas that we value depending on the JSR.  It’s not possible to come up a rigid definition of what is required for a JSR to pass, otherwise you could just replace the LJC JCP Committee with small shell script.  So the criteria we apply is a bit like ‘The Pirate’s Code’, more of a guideline really.


This is one of our primary concerns.  How transparent is the process of developing the JSR.  For a long time a lot of the JSRs were put together in a manner that was invisible to the rest of the Java community.  We’ve been quite outspoken in our support of JSR 348 (aka JCP.next) which seeks to increase the transparency of the process.  We also included a strong statement during our vote on the Java 7 specification regarding the lack of visibility of some private mailing list content.  We are actively encouraging existing JSRs that started under older version of the JCP process to attempt to meet the transparency requirements of JSR 348.

User & Vendor Participation

Anyone remember EJB 1.0/2.0?  Anybody who does will remember a lot of pain.  It is our belief that the earlier versions of the EJB standard were the result of too much vendor control of the specification.  If one looks at the current specification of JPA (Java Persistence API) when compared to the older Entity Beans specification, it is very clear that the JPA has been driven heavily by open source/user focused tools such as Hibernate and EclipseLink (formally TopLink), whereas as the older Entity Beans was difficult to use and awkward to make efficient.  There was a very clear statement made during the development of JavaEE 5 that developer productivity was the main focus.  It is our feeling that this should be front and center of all work done in the JCP, and to ensure that this happens there should always be end user representation on the JSR expert group.

Open Source RI and TCK

One of the largest areas of controversy around the JCP was inability for the Apache Harmony project to get access to the Java TCK under a license that was acceptable to them and the resulting fallout.  While the Harmony PMC has voted to move the project to the Apache Attic and IBM have now agreed to work with Oracle on the OpenJDK, there is still an important lesson here.  To have an effective specification, the TCK should be open and accessible to all implementors.  We understand that commercial and legal constraints may prevent this, it won’t prevent us from asking for an open TCK or commenting on its absence.  We are even actively participating the the creation of a TCK for new Date/Time API (JSR 310).

Does it Work Well as a Specification

Is it something that really requires a specification?  An example of a JSR that works well, as a specification is the JMS (Java Messaging Specification).  Messaging as concept is an important aspect of enterprise systems making it a strong candidate for a standardised API.  There is a very rich market of commercial and open source messaging products and the success of the specification is backed up by the number of implementations that are available (~15 listed on Wikipedia).  Recently we voted no on JSR 351 (Java Identity API).  One of the reasons for that was a lack of existing implementations, and we suggested building out an open source implementation first.

General Merit

As a catch all we look at the overall importance of the JSR itself.  For example, while we weren’t happy with all aspects of the Java 7 JSR, we felt that it was too important to vote against.  Moving Java forward held greater importance than ensuring that every email produced during the development of Project Coin was publicly available.

If you feel that there are other criteria that should be applied by the LJC JCP Committee when assessing JSRs, then feel free to contact us.  Either on the LJC mailing list or directly, we tend to be at a lot of the meetups if you want to chat face to face.