After much thought and consideration the LJC JCP Committee have cast their votes for the JCP elections (Look for the Executive Committee Elections link at jcp.org). We’re making our vote public and will give our reasons according to the openness and transparency requirements for the committee.

The list of nominees for the seats are as follows (link also contains useful recordings and notes from the nominees):

There are 8 ratified seats and 5 open seats up for election. Although it may seem like the ratified seats are shoe-ins since to the number of candidates == the number of available seats, enough no votes can make a candidate ineligible to take the seat.

In short, we think Oracle have chosen well and see no reason not to ratify these candidates.

Open Seat Vote

This was a very close vote as the strength of candidates was unprecedented. Here are our yes votes:

Azul Systems – Azul is one of the few JVM vendors out in the marketplace. Their inclusion is vital in order to keep Java SE as an open standard and Gil Tene’s insights around thorny legal issues have proved to be invaluable to the EC.

ARM Systems – The world needs Java to run well on ARM, they should be involved in evolving Java, simple as that!

Hazelcast – Represent both strength in the EE space (JSR 107 and 347 for caching and distributed data grids) and also push the SE envelope with the requirements for their core product. Greg Luck is a long time experienced member of the JCP process, his expertise would be welcome.

Waratek – Bring innovative new thinking about the JVM with regards to scalability and security in cloud environments with their multi-tenanted VM. As with Azul, it would be great to see other JVM vendors on the EC to keep help keep Java modern.

Morocco JUG – Representing the voice of developers in the Middle East and Africa. It’s estimated that a majority of new developers will come from these nations over the coming years and so they should continue to be included at the highest levels of Java.

Geir Magnusson Jr - Geir was instrumental in helping shape Java in the early years of its existence and brings a wealth of experience and understanding of the broader Java ecosystem. It’s great to see him back!

There were lots of other worthy candidates, but we feel these 5 candidates represent the best balance to face the challenges of the industry in 2015.

Summary

Although the Committee has voted for and endorsed these particular candidates, any LJC member who is also a JCP member can (and no doubt will!) vote any way they wish to.

The LJC is voting No on the Final Approval Ballot for JSR 48 (WBEM Services Specification). As this decision may surprise the community, we wanted to ensure that the reasons behind this are fully understood.

The No vote is purely a procedural measure. During the discussion of this JSR, it came to light that the license that the Reference Implementation conflicts with the terms of the JSPA and is therefore not valid. Were the Final Approval Ballot to pass, the resulting standard would be impossible to implement and useless to the community.

The LJC, along with IBM, SAP and the JCP PMO, met with the Spec Leads and resolved the issues around licensing. The EC has agreed that the Final Approval Ballot must fail, and EC members will accordingly vote it down. The JCP process contains a contingency measure for circumstances like these, known as a Final Approval Reconsideration Ballot.

This Ballot allows the Spec Leads to correct any problems & resolve concerns before resubmitting within 30 days – effectively a second chance. The Spec Leads indicated that they intended to do so, and to resubmit the JSR with a modified RI license.

During the meeting with the Spec Leads, some ecosystem questions regarding the health of the ecosystem for this technology, and the number of participants were also addressed. The Spec Leads were able to point to a wide variety of companies and projects participating, so on this basis, the LJC is happy to support this JSR.

A number of minor technical questions were also discussed – and the Spec Leads agreed to address some of them by releasing the source code for the TCK for this JSR – and to produce a new JSR for a version 2.0 after the initial release to fix any bugs found by the community.

The LJC JCP Committee would like to thank the Spec Leads for making time to meet and address concerns at very short notice, and for their perseverance in completing the JSR process.

As always, if you’re an LJC member and interested in our work in the standards & specification space – please contact one of the committee – we’re very happy to talk about our ongoing projects, and there are always ways to get involved.

Disclaimer: This post is written by developers to demystify the process and some of the differences between the JSPA (Java Specification Participation Agreement) and the OCA (Oracle Contribution Agreement). Both of these may have legal implications to intellectual property rules that might be written into your employment contract. If you are in any doubt please seek legal advice before signing one of these contracts, the last thing either you or the community wants is for you to find yourself in a legal conflict.

If you are thinking about contributing to Java there are two levels on which you can get involved. Depending on what you want to contribute you will need to sign either one or both of the JSPA (Java Specification Participation Agreement) or the OCA (Oracle Contribution Agreement).

The JSPA enables you to contribute to JSRs and sit on the expert group of individuals representing that change.

Your employer may have already signed the JSPA, in the first instance you should check with them as you might already be covered for your participation by their contract.

If your employer hasn’t signed the JSPA, you will probably want to participate as an individual (there is a cost associated with company memberships, however an individual membership is free of charge).

Your employer needs to agree with you signing the JSPA (even as an individual) and your employer needs to sign your individual JSPA paperwork. Note: the signature needs to meet certain standards – if you’re not sure you need to look at the Oracle website, especially if it’s a squiggle! (from experience)

I worked for a large investment bank and this was not a problem to be signed off by the legal team, but it did take around a month. So if you are thinking of participating in a JSR it’s a good idea to get this signed off early.

Once you send to Oracle the process is usually fairly quick to resolve, you can either fax (if that still exists where you are) or E-Mail each of the pages back as a PDF.

OCA

The OCA is required for direct code based contributions that are to be checked in to Java. It is a short single page document.

If you’re working on Open JDK and your work is approved for submission you will need to have one of these.

The essence of this agreement is to share the ownership of the change between yourself and Oracle.

If you’re thinking about taking this path it’s only a simple one page document that is quick to complete, so I recommend doing this upfront.

If you are going through your employers approval process it is potentially a good idea to try get both of these agreements signed off at the same time if you need to.

One final thing to note is that you can still attend hack days and bug fixing days without having the above signed, so if you’re not sure about how to get started, a hack day, Adopt-A-JSR or Adopt Open JDK is for you.

As mentioned in a previous post the committee is very pleased to have been re-elected to sit on the JCP committee. Everyone who works on the LJC committee does this voluntarily and in their spare time. Naturally as other commitments come around for personal and/or other opportunities we always welcome new faces and bid farewell to those who have contributed.

On this occasion, Richard Warburton is stepping down from the LJC JCP to focus on other initiatives within the Java community. Richard has worked on countless initiatives within the LJC JCP and first became interested in the cause when he first moved to London and met Jim Gough in a bar at the monthly developer sessions. Since then he has significantly contributed to both project lambda for Java 8 and the Date Time API, also for Java 8. Working with the rest of the committee Richard helped to setup sone of the corner stones that launched the Adopt-a-JSR initiative and running hack days in multiple countries. It is fair to say that Richard has aided the delivery of Java 8 and many of its newer features.

Richard is well known to the spec leads of the major JSR projects due to his insight and feedback into the development of the features. Although Richard is leaving the LJC JCP group he will still be actively involved in the community and through the Adopt-A-JSR program.

We would like to thank Richard for all his hard work and wish him all the best for the future.

I won’t go into too much detail except to say that it’s great we can continue to represent developers around the world and that we’ll continue to focus on practical workshops, hack sessions and discussions to help drive Java forwards.

We’re always looking for volunteers to help out with these efforts, so if you want to have a direct hand in Java8/9/10, Java EE 8 and embedded Java, then let us know!

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.

Conclusion

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.

The committee meets once a month in person and has several discussions on their mailing list about Java standards and how the LJC should cast its vote for each Java Specification Request (JSR).

As per our informal charter, we blog about any changes in the membership of this committee. On this occasion Kim Ross has stepped down temporarily to other commitments.

Kim was a fantastically pragmatic minded member of our committee with a sharp eye towards what was sensible and useful for the day-to-day Java developer. She also bought extra expertise in the form of NoSQL and caching technologies and the views from the gaming sector.

====

We welcome to the fold Gemma Silvers (a LJC stalwart) who is currently heading a technology team at Amazon. We’ll be relying on her experience in dealing with the modern cloud an large Java/JVM deployments.

Also joining us is Sean Landsman who brings us extensive experience from inside the Java enterprise trenches across a multitude of sectors (yes, including finance, it is London after all!). Sean helps balance out the group with his experience of seeing large Java shops in action.

Last but not least we have Daniel Bryant who comes with an impressive academic CV and and extensive career as a contractor / consultant. Daniel has also been hard at work on some of the LJC’s open source projects, such as Betterrev

So thanks again Kim and welcome to Gemma, Daniel and Sean!

Martijn (on behalf of the LJC JCP committee)

PS: We’re always looking for more people to help us out – so if you have a passion for Java as a platform and want to help it stay relevant and vibrant going forwards then let us know!

JCP to put up a public calendar – Chasing java.net to do their site refresh

ACTION Ben to put our vote through for 358

Red Hat wants to start the expert group for Java EE 8 with others including as many developers as possible, as early as possible, including participation from the LJC. We’re looking into helping with this.

Graham has stepped down – Action to write a thanks post

Still need a 3rd for Ben for the F2Fs

Martijn will likely step down as a 2nd to Ben so will need a 2nd and 3rd at some point

Wanting to increase the number of volunteers in the LJC JCP committee. The committee will reach out to individuals after a lack of success on the main mailing lists

The ‘What should the JCP do next?’ survey has been rubber stamped by the EC committee – so we’ll send this out soon to developers so we can pass this back.

Write a blog post about our position for JSR 358 – very little action on this – Discussed during the meeting and will write up in a doc/blog post as the LJC JCP’s statement.

* Graham to schedule the March meeting* Wrote a couple of articles for Java Magazine – Adopt A JSR & Hackday* Still looking for a JEE person – failing* JSON/WebSockets hack day done! Yaaaaay – very little feedback back to organisers * Short retrospective after the hackday? (on the hack day and the JSR) * Split the hack day with experienced/novice users – offer intro to novice users * Possibly better to have joint hack days running on weekends* David to write up JSON/WebSockets hackday feedback* Richard to add the how to run a hackday presentation somewhere more visable* Martijn to write a thank you post to Trish* LJC to publicly write it’s position on JSR 358 – Google doc to put our thoughts in.* David to take the tertiary position as the LJC JCP rep – to check with work first (GDS)* Adopt a JSR global call – “Awesome call” – covered: Facebook page started by Brazillians, how to run a hack day, adopt a jar, bunch of git commits* Adopt OpenJDK – Going well – Trying to get OpenJDK onto github. Looking into the best way to submit patches to OpenJDK

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.