Minutes for the LJC/JCP Committee Meeting on 19th October

Attendees

• Richard Warburton
• Somay Nakhal
• Ben Evans
• James Gough
• Martijn Verburg
• Trish Gee
• Mike Barker

Agenda

• Review TODOs from last meeting
• JSR-331– Constraints Programming for Java – Proposed Final Draft. We have Openness and Transparency Concerns.
  • There’s one potential Adopt a JSR LJC member that we can use to look into this (Lanre)
• JSR-333 – Content Repository API – Early Draft Review, last day of review: 30 October 2011.
• JSR-351 – Identity.  As we have major concerns about the validity of this JSR we should discuss whether to get them in for a presentation.
  • Meta: Stimulating discussion about JSRs on the SE/EE list. e.g. we didn’t publicise our concerns about JSR 351 on the SE/EE EC alias – and I think a lot of other members would have had more concerns if we’d spoken up on-list
• Adopt a JSR program
  • Progress Reports on existing Adopted JSRs
  • Discussion on where we go next with this
  • Publicising the list of people who have joined the program back to the LJC (and beyond)
• Adopt the OpenJDK program
• Discuss candidates for the upcoming JCP elections
• Other business

Minutes

• Issues from last meeting were reviewed
• JSR-331 – BE to send to SE/EE list saying we’re going to vote no and here’s why. Before he does, check with Werner Kiel.
  • We need to list our criteria for voting on any JSR on the Java.net wiki (MB)
  • We need to update our voting record on Java.net (BE/MB)
• Look into into 333 for our voting stance (MB)
• Accept 351 invitation for webinar (BE)
  • JCP.next.next solicit comments before the vote (BE to ask Patrick)
• Launch Adopt a JSR by end of Oct (MV)
  • 350 report, new Java.net project, (SM will adopt a JSR)
  • Submit a BOF on JSR-310 at Open Conference (JG)
  • Find people to ‘Adopt the JMS 2.0 JSR’, (TG talk to BE)
• Set up a JCP Committee voting poll (MV)
  • Post early endorsement of a candidate (BE/MV)
  • Promote this election (All of us)
• Lead an ‘Adopt an OpenJDK’ (TBA)
  • Get a collection of LJC people to work on the build (MV)
  • Propose Oracle to allow JEPs without being a committer (MV/BE/TG/MB at Devoxx)
• Next meeting to be scheduled for November, the week after Devoxx (BE/MV)
• We need to have our contact details in a Shared Document (Everyone)
• Martijn to buy the next lot of Wine (MV)

Cheers,

Martijn (On behalf of the LJC JCP Committee)

The LJC JCP Committee – How it formed and how you can join!

Hi all,

We realised that at the recent Open Conference that there were a lot of new faces to the LJC. It has been 6 months since we won the elected seat for the JCP Executive Committee (EC) and formed our own committee to review and vote on JSRs (and deal with any other JCP activity).

There have been a number of posts to this list on the topic of the committee and it’s activities, but we thought we’d better bring it all together under one post with regards to how it came to be, its structure and how you can join in!

What’s the goal of this Committee?

1. Primarily we want openness and transparency in the creation of Java Standards.
2. Equally as important, we want the end users of these standards (that would be Java developers) to have a say in the standard before it becomes ratified.

What if I don’t agree with the committee?

We don’t own anybody!

The reality is that with >2000 members, all we can do is try to represent you as best as possible. We do this by canvassing opinions, especially at events such as the developer sessions, talks and of course, the recent open conference. You’ve probably also seen the regular blog posts and mails asking for feedback as well.

‘Adopt a JSR’ is yet another feedback mechanism we have in place.

We especially want to hear from you if you do disagree with us! The wide range of opinions we have, the more accurately we vote for the community at large. And of course you can join the committee and add your direct vote (see “How do I join?” below).

Who’s currently on the Committee

• Ben Evans (The designated rep for JCP EC meetings)
• Martijn Verburg (secondary rep)
• Trisha Gee (tertiary rep)
• James Gough
• Richard Warburton
• Simon Maple
• Michael Barker
• Somay Nakhal

And of course Barry Cranford keeps his hand in as the Founder of the LJC and keen ‘Adopt a JSR’ supporter.

How did this committee form?

We originally sent out several posts asking for volunteers for the LJC JCP Committee. The initial group of people that volunteered was Ben Evans, Martijn Verburg, Trisha Gee, Simon Maple & James Gough. Michael Barker, Richard Warburton and Somay Nakhal have been added since (see “How do I join?” below).

How do I join?

The JCP Committee consists of a “meritocracy of the willing”. That is, if you want to join and are willing to put the effort in then after a couple of monthly meetings the committee adds you in (after a simple majority vote). So far everyone that has wanted to join has been accepted, we’re very much an open shop on that front!

The barrier to entry is relatively low. The minimum requirement is that you put in some effort – that is:

1. Regularly turn up to the monthly meetings
2. Actively review JSRs
3. Support programs such as ‘Adopt a JSR’
4. Write the occasional blog post

It helps to have a good understanding of the overall Java ecosystem and some open source and software patent laws, but we can mentor people in all of those areas. The time effort required is typically about 5 hours a week for a committee member, with the JCP EC reps putting in extra hours for EC meetings and extended research (10-20 hours/week).

Travel is required for the primary rep (or the appropriate back up) for a F2F meeting 3-4 times a year. As we are a Java User Group – Oracle picks up the flight and accommodation expenses for that rep (we’re talking economy class and a reasonable hotel, so this isn’t the 5* perk the rep was looking for ;p).

How does the committee vote/organise itself?

Simple majority voting applies, this includes voting who the primary, secondary & tertiary reps are and voting on JSRs etc.

Is the mailing list public?

Sadly not. This is the unfortunate reality of discussing legal issues (under NDA in some cases) and other information that the committee is given in strictest confidence.

So what do you make public then?

Everything that we possibly can! So our minutes (with some legal stuff redacted), our voting strategy and record. We’re certainly the most open and transparent member of the JCP EC and are encouraging the other members to follow suit.

Hopefully that answers most people’s questions but of course any and all feedback is welcome!

Cheers,

Martijn (on behalf of the LJC JCP committee)

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.

Transparency

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.