You are currently browsing richardwarburton’s articles.

What’s this all about?

The Java Community Process is the mechanism for defining specifications relating to Java.  These specifications are called Java Specification Requests (JSR) and there can be multiple implementations, for example, JSR 315 defines the latest servlet standard and software such as Tomcat and Glassfish implements this standard.

The London Java Community have a vote on the Executive Committee of the JCP which sets out the overall direction of the JCP and represents the interests of both its direct members and also the general membership of the Java community at large.  In order to complement the many informal discussions with developers that we regularly undertake the JCP Committee decided to run a survey in order to reach a wider audience. Here’s a summary of the 322 responses that we had!

1. Are you more likely to use a Java technology because its an implementation of a JSR?

An overwhelming 74% of respondents said yes, against 16% saying no.  We also asked people to explain why they said this. The obvious answer as to why is vendor neutrality, and this was chosen in a number of responses.

More surprisingly one of the other running themes from this question was that people felt that technologies that are backed by standards are more likely to be around in the long term and therefore something that you can rely on. In recent years the rapid deprecation and retirement rates of SaaS products and APIs has certainly drawn attention to this issue.

2. Would you like to see the JCP developing standards around any of the following areas?

NoSQL 169 18%
Data Analysis and Big Data 132 14%
Platform as a Service (PAAS) Cloud Computing 134 14%
Non-JMS Messaging Protocols (AMQP etc.) 98 10%
An app store or approach to deploying Java apps in app stores. 88 9%
I’d like to see more effort put into refining existing Java SE standards than creating new ones. 141 15%
I’d like to see more effort put into refining existing Java EE standards than creating new ones. 118 12%
I see little to no value in standardising new areas. 21 2%
I’d like to see standards, but these technologies aren’t mature enough. 36 4%
Other 27 3%

The most popular response, by far, was support for NoSQL databases. In many ways this is an ideal candidate for providing useful APIs around: different vendors all providing different competing products which developers get locked into. Of course there are many technical challenges surrounding the design of such a standard, given the differing merits and suitabilities of different products in the space (e.g. Document stores vs Graph DBs etc).

The next pack of popular options was led by improvements the Java SE. Java 8’s major overhaul of many core library and language components shows the existing JCP commitment to continuously improve core Java. The LJC shall continue to champion the evolution of Java SE through the Adopt OpenJDK program.

The standardisation of data analysis and PaaS platforms was also in high demand, giving us a solid idea of what developers want in next few years.

3. If you’ve not participated in the JCP what is the reason?

I don’t know how. 219 85%
I don’t think the JCP serves my interests. 30 12%
I am not interested in the technologies it standardises. 3 1%
I don’t think standardising Java technologies has much value. 5 2%

One of the most successful contributions that the LJC has made to the JCP is the introduction of the Adopt-a-JSR program which helps encourage developers to get involved in contributing to standards during their development.  We were quite surprised to hear that the most common reason for not participating is that people don’t know how. Its pretty obvious that JCP members, the LJC included, need to make more effort to publicise and explain the JCP and demystify it to day-to-day developers.

4. What type of software do you write?

We use a full stack Java EE system. (eg Glassfish, JBOSS, Websphere) 155 20%
We use an alternative enterprise stack that uses some Java EE components (eg Spring) 180 23%
We have written our own framework/architecture from scratch. (even if you re-use other ecosystem components such as Hibernate) 101 13%
We use an alternative framework (eg Play, Vertx, Grails, Hadoop) 85 11%
We use Java SE/Core Java components in our product. 225 29%
We’re developing using Java ME application. 7 1%
Other 13 2%

Very few people were actively using Java ME. This isn’t a particularly surprising result and validates JSR 355’s approach of merging the ME and SE/EE executive committees.


With the recent release of JavaEE 7 and Java 8 coming out soon, this is a great time for day to day developers to get involved with the next set of Java standards.  In particular there are strong requests for improvements to core Java and having standardisation introduced for the wave of recent NoSQL technologies.

Please join us at Adopt a JSR, Adopt OpenJDK and on the JCP to help shape the future of Java!


The LJC JCP Committee

Vaibhav Gowadia

1. Hello David

Since Mike Barker has left us, the committee welcomes its newest member – David Illsley.
2. 351 Discussion with Vaibhav
We discussed JSR 351 with Vaibhav Gowadia.  There has been a change in the makeup of the expert group, including going through 3 EG Leads.  Vaibhav explained that some of the issues with the original API have been resolved.  Many of our concerns, such as the poor definition of the scope of the API and that its modelling a domain remain.  Vaibhav agreed to get more detail on the motivations involved by some of the EG members and progress with improving matters from that point onwards.

3. Catchup

Following up from previous meetings, and going forward:

  • Martijn to Schedule May meeting
  • Some JSRs making really good progress with adoption (310 and 335) whilst others lagging behind (JMS 2.1)
  • Everyone needs to push Adopt-a-JSR and Adopt OpenJDK whenever they can.
  • We’ve fully investigated the concerns over the JEE licensing issue. and its ok.  The charges only applied to the commercial license, rather to people who are accepting the GPL’d OpenJDK implementation.
  • JSR 356 now satisfying these legal concerns as a result of feedback from the LJC.
  • People should check trello for TODO List updates.

4. Ongoing Items

  • We will launch adopt OpenJDK formally within a week, and spread it out to other JUGs via the JUG Leaders list and public mailing lists.
  • We still haven’t got Oracle’s analysis tools made public, so that they can be used for OpenJDK contribution.


5. Adopt OpenJDK & Adopt-a-JSR

  • We’ve acquired nearly 200 patches to go into OpenJDK, and are busy reviewing them.
  • We’ve moved to github in order to make it easier to coordinate things.
  • Richard made google groups work.
  • James & Somay to work on building OpenJDK and understanding more so that they can skill up and contribute
  • Ben and Richard to do a talk or hackday on lambdas.
  • Its proving hard to get volunteers for adopting jms 2.0 or ejb.


Ben Evans
Martijn Verburg
James Gough
Trisha Gee
David Illsley
Somay Nakhal
Richard Warburton


  • Everyone happy with meetings at jClarity offices.
  • JG to doodle for next meeting
  • RW to write up minutes from last meeting, and this meeting.

Adopt OpenJDK
The committee discussed the progress being made in this space.  A combination of a mailing list and an irc channel seems to have spurred contributions and made it easier to run and manage.  It would be a good idea to backport these to adopt a jsr.

  • Still plan to keep Adopt a JSR separate from Adopt OpenJDK.
  • RW + MV to setup a mailing list and irc channel for Adopt a JSR – (Done).

Brazil Face to Face

  • A lot of procedural discussion.
  • Several ME members not turning up.
  • Next version of ME will be rebaselined off of Java 7 in 18 months.
  • TOTVS (co-hosting with Soujava) introduced the Committee to Ginga-J – a Java-based digital TV standard used on top of the ISDB-T international standard (used primarily in Japan & South America)
    • This has the potential to allow developers to reach a South American user base of 350 million users via their TVs.
    • The potential and challenges that TOTVS face on the TV standardisation committees bear some similarities to those faced in other parts of the JCP.
    •  Strategies for co-operation with other standards organisations were discussed
    • Also ways to ensure that Java remains a central part of the ISDB-T story for IPTV.
  • Adopt Openjdk discussion at the Face to Face
    • Discussions with Anil Kumar at Intel.
    • Possible Hardware to host adopt openjdk.
    • Initially this could be hosted by LJC, but eventually broaden out to a larger community.
  • Some desire to extend the length of use for OpenJDK TCK to 5 years from Azul, however, no solid conclusions on the matter.

Lambdas Hackday

  • … went very well
  • Some bugs found, and some lessons learned for further hackday discussion.
  • RW to write up feedback for discussion on the mailing list – (Done).

Other Business

  • RW + JG to organise JSR 310 Hackday in London.
  • JG to investigate Java EE standards further
  • BE & MV to ask about putting Private LJC List read-only on the JCP Mailing List.

Last month we had a new JSR vote, which was an initial approval vote for JSR 357. As noted by the Java community at large, we voted no on this JSR and this blog post explains why as per our openness and transparency policy.

The vote itself was an initial ballot approval vote. This kind of vote happens at the very start of the JSR process in order to determine whether or not to accept the concept of a JSR from the initial specification. The JSR 357 proposal defines a social media API for use by Java programs.

Our vote shouldn’t be construed as a negative comment upon the medium term benefits of standardization in the social media space, but rather the immaturity of the area and potential issues within the initial specification of the JSR. The key problem that we see is that the API contains a high degree of domain modelling which is too inflexible to easily accommodate the evolving space.

The lack of focus on mobile is also a significant drawback – in 2012, social media is increasingly being driven by mobile applications – it makes no sense to have a social JSR which is not co-ordinated with the ME standards process. Fundamentally the scope of this JSR is quite wide and its our belief that focussed JSRs make better standards than specifications that are very broad in scope.

These initial concerns were raised by the LJC with respect to this JSR and feedback was given to the Expert Group leads about these concerns which they failed to address within the appropriate time. It was therefore decided that it was inappropriate to assume that these concerns would be addressed during the lifecycle of the JSR so we voted No. A majority of other EC members also voted no to this proposal, thus ending the JSR for the time being. The only EC member who had a direct business interest in social media, Twitter, abstained and echo’d the concerns outlined by the LJC. Furthermore some of the EC members who voted yes, for example Goldman Sachs and Oracle, agreed with the concerns raised but simply felt that the JSR would be able to evolve away from its initial specification during its lifetime and that these issues could be considered again at an Early Draft Review.

We’re very please to see that the Spec lead Antoine has taken the feedback on board and is looking to run a OSS project in order to flesh out this space.  Please do join him and the other project members on their Google Group.


Richard (On behalf on the LJC JCP Committee)

Over the last year the LJC has been involved in JSR 348 – a JSR reforming the JCP itself, and is also becoming involved in its successor – JSR 355. Despite the benefits that JSR 348 presents, due its complex and technical matter it is quite hard to read the specification itself – so here’s my layman’s take on the key developments in this space.

Transparency – a key improvement put forward within JSR 348 is improving the transparency of JSR development. In practice this means that Expert Group business is to be carried out on public mailing lists, requiring issues and comments to be tracked through a publicly viewable issue-tracking mechanism, and requiring EGs to respond publicly to all comments. It also requires that Spec Leads disclose their licensing terms and terms of use in advance and requires them to be compatible with the JSPA.

Maintenance – some JSRs have become inactive or are moving very slowly. JSR 348 introduces timeouts for these processes so that JSRs that aren’t functioning properly can be clearly identified and either their problems resolved or the JSR closed.

Ambiguities – this JSR also removes some technical ambiguities, for example the legal review of proposed licensing terms and makes guidelines within the old private EC Members Guide into a publicly readable EC Standing Rules document.

Governance – At present the Executive Committee of the JCP is split into two groups – the SE/EE committee that the LJC is part of and the ME Committee. JSR 355 will follow on from these reforms by merging the two committees into one committee, and reducing the overall number of elected seats.

The combination of these changes will make the JCP leaner and more reactive, as well as continuing to lower the barriers for day to day developers to get directly involved with the language and platform that they love!

Minutes for 29th March, as always, questions, comments etc are welcome!


  • Ben Evans
  • Trisha Gee
  • James Gough
  • Richard Warburton

We voted no to JSR 357, one of the spec leads will be investigating the core concepts of this JSR in an open source, community setting and then may reinvestigate standardisation after the issues that we pointed out are corrected.
Richard Warburton to writeup why we voted no.

With several committee members presently expanding their families we’re not as numerically strong as we were late last year.
James Gough to investigate the situation.

Oracle Meeting
We’re meeting Cecilia Borg, from Oracle, on 17th April in order to represent community interests.
Ben Evans to book a table for this.

EC Relations
We should invite Scot Baldry to a future JCP Committee meeting in order to facility relations with other non-vendor EC memembers.
Ben Evans to talk to Scot about when he’s free.

RI Licensing Issue
We’re unsure as to whether OCSL Appendix D licensing rules apply to open source projects.
Ben Evans to confirm with Oracle as to the status of this.

Trello Review
Richard Warburton to adopt JSR 308 and try to encourage user participation.
Richard Warburton to write up a blog post on why JSR 348 is an improvement.

LJC should run monthly adopt an openjdk hackdays, and needs more instructor level people in order to be able to achieve ethis.
Ben Evans to talk to community contacts about locations.
Instructors to meet and skill-up on 16th April.
Next hackday scheduled for 23rd April.

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

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.

At the LJC we’re trying to democratize the future development of the Java platform. The development of Java is run through the Java Community Process – which splits up changes to the platform into Java Specification Requests (JSRs). A JSR is a specification for a set of related changes to Java, and there are a lot of them. As an organisation that is trying to bring the wider developer community into the standards process in order to inform the decsion making process, improve the standard and innovate the platform we’re promoting the ‘Adopt a JSR’ program.

The idea behind Adopt a JSR is that you, a Java ecosystem enthusiast, can contribute to a JSR by following its progress, helping out on an expert group or informing the wider community of its progress and evangelising its benefits. You can take your industrial expertise and help progress Java in a direction that benefits you and the wider community. The LJC are a voting member on the JCP and can help facilitate any ideas or suggestions that you may have on the matter, so if you want to know more about how to get involved, please contact the LJC’s JCP Committee.

At present there are several JSRs that we’re seeking participation for.

  • Date and Time (JSR 310)  – the upcoming improvements to the Date and Time Api are requiring a TCK. James Gough (@goughjam) is helping coordinate the LJC’s effots here.
  • Java Message Service 2.0 (JSR 343) – the next version of the important JMS standard is currently being developed. The LJC is in contact with Tim Fox and Colin Crist, who are working on this project.
  • Bean Validation 1.1 (JSR 349) – a new maintenance release for Bean Validation. Do you use Bean Validation and want to help improve it?
  • Session State Management (JSR 350) – introduces an API that will offer a modular system for dealing with State management, generalising some of the ideas from the HttpSession State object. Somay Nakhal is interested in helping out with this proposal.

Of course if you want to work on something else, or even propose a new JSR yourself, then don’t hesistate to contact us. We’ll also be documeting our progress on our wiki.

Perhaps you’re tired of some problem within Java that you’re always encountering. Perhaps you’re trying to give back to a community that has helped you grow as a developer. Perhaps you just want to contribute in a meaningful way to an important and influential platform. Whatever your motives, its time to contribute because Java needs you.

What is the LJC

The London Java Community (LJC) is a group of Java Enthusiasts who are interested in benefiting from shared knowledge in the industry. Through our forum and regular meetings you can keep in touch with the latest industry developments, learn new Java (& other JVM) technologies, meet other developers, discuss technical/non technical issues and network further throughout the Java Community.