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.
Please join us at Adopt a JSR, Adopt OpenJDK and on the JCP to help shape the future of Java!
Thanks,
The LJC JCP Committee
London Java Community 
5 comments
Comments feed for this article
September 17, 2013 at 4:51 pm
lukaseder
What, no one wants new language features, like collection literals, for instance?
Some examples interpreting a mail by Brian Goetz on the lambda-dev mailing list:
September 17, 2013 at 4:57 pm
richardwarburton
I think you’ve misinterpreted the results here. 141/322 agreed with “I’d like to see more effort put into refining existing Java SE standards than creating new ones.” Which would include the kind of change that you’re talking about.
September 17, 2013 at 5:02 pm
lukaseder
Ah, you’re right. Although, I still think that the language and the platform deserve distinction in this context. While shortcomings in the libraries (e.g. Collections) can be circumvented with third-party libraries, shortcomings in the language cannot be circumvented, except if using something like Scala, or Xtend…
September 17, 2013 at 9:28 pm
What developers want for future Java standards | Kosovo Java Programmers
[…] Here’s a summary of the 322 responses that they had!Read it HERE! […]
November 16, 2014 at 9:05 pm
Why do I contribute to the JCP (and at the same time evangelise the Spring framework)? | The Tai-Dev Blog
[…] The key thing to remember about the JCP process is that it is not about innovation. Quite the opposite in fact. For a standard to be created there must have an initial requirement or problem, significant innovation for solutions, ideally some competing ideas and implementations, plenty of evaluation and discussion, and ultimately an agreed approach on how to meet the requirement. It is only at the second from final point the JCP can start creating standards. This is the biggest misunderstanding I encounter when running JSR hack days around the world, particularly with Junior developers, as they think the JCP is some mystical think tank who crank out the latest and greatest frameworks (I appreciate calling EJB ‘latest and greatest’ is very ironic 🙂 ). It’s also worth mentioning at this point that the work of the JCP is now undertaken in the open (I do appreciate the fact that it didn’t used to be, but JSR-348 has made great progress to abolish this). This openness allows anyone who wants to get involved have a voice in the process, and if a standard will cause problems (or is evolving in a problematic fashion) then the community can rise up and publicly duke this out with the spec leads. Now on the flip side to this there exists organisations like Spring Source/Pivotal who are all about innovation, and are constantly pushing the boundaries of what a language or framework can do. Personally I love this. I have an entrepreneurial background, and I thrive on innovation and playing with the latest tech and bleeding-edge frameworks, as do many of the companies I work with. However, as a consultant I appreciate that not all my clients (or the industry in general) think like this, or desire this level of innovation. Some companies are inherently risk adverse (sometimes with good reason) and they want to ensure any investment in technology or training their people in a specific technology offers a long-term return on investment (ROI). Such organisation also often desire portability of application/code, and although the implementation of this on the Java platform may not have been perfect in the past, I’ve personally moved several Java EE applications across differing application servers with minimal effort. In my mind this is where standardisation can offer enormous benefits, particularly if the standardisation work is undertaken out in the open. Finally, last year within the London Java Community we undertook a community survey last year, and many Java developers were in favour of standards (check out the result here https://londonjavacommunity.wordpress.com/2013/09/16/the-java-community-process-survey/) […]