In order to continue our commitment to openness and transparency in the JCP we’re publishing our reasoning for the votes that occurred in February.  For a description of the overall criteria we use for voting you might want to read  http://londonjavacommunity.wordpress.com/sign-up/page/2011/11/08/what-we-look-for-in-a-jsr/.

JSR 331: Constraint Programming API
This is a Final Approval Ballot – which means that the standard has already been designed and worked upon and this vote is a final decision as to whether to approve or reject the standard. JSR 331 itself specifies an API defining a operations used to define and solve constraint satisfaction style problems.

Initially the LJC expressed some concern that whilst the API was of use the Expert Group was quite small, after the Expert Group broadened to include more user participation our concerns were alleviated and we had no issue voting yes.  The API itself is based upon several academic works and different implementations over a sustained period of time and is a refinement of this work, so we believe it would work well as a standard.  It also meets our transparency criteria since it has a publicly writable discussion forum, and the expert group business is publicly reported upon.  The reference implementation is open source.

JSR 354: Money and Currency API
Both 354 and 355 are approval ballots.  This means that they are JSRs that are at the very beginning of their process and this vote is whether to start standardising in this area.  The LJC’s own Ben Evans is a JSR 354 Expert Group member.

We believe that money and currency related problems are a common use-case in many industries and that the existence of several existing APIs and a wealth of proprietary internal APIs provides a clear motive for standardisation.  The Expert Group contains several User Participants.  Its running under JCP version 2.8 – which means it also meets our transparency requirements.

JSR 355: JCP Executive Committee Merge
JSR 348 began the process of improving the Java Community Process itself by making it more open and transparent, JSR 355 is the next step of the JCP reforms.  At present there are two committees: one for Java ME, and one for Java SE/EE.  In the near future Java ME will have its specification reworked so that its closer to Java SE, in order to allow people to transfer their skills to embedded and mobile developers more easily and in order to bring the APIs and language more up to date.  In conjunction with that process JSR 355 describes how the ME Executive Committee will be merged with the SE/EE Executive Committee.

The LJC is supporting this committee merge because it makes the constituency of the executive committee more reflective of the underlying technology developments.  As part of our commitment to JCP reform the LJC has two members on the JSR 355 Expert Group: Ben Evans and Martijn Verburg.  An initial concern was raised with the JSR allowing charges for JSPAs, however, Martijn has received clarification from Oracle that this is only to be used in order to discourage any attempt by an organisation to vote-stack the election process.

About these ads