The London Java Community, London's most famous Java meetup, published the results of their recent survey about the Java Community Process (JCP) that exposes some surprising trends. LJC represented by member Ben Evans currently holds one of the 24 seats on the JCP Executive Committee, and the LJC has been very active in promoting their "Adopt A JSR" initiative promoting community support for the JCP.
The Java Community Process is the governing body that defines and maintains Java Specification Requests (JSRs), and thereby defining the future of Java.
The survey asked four questions, and received 322 responses:
- Are you more likely to use a Java technology because its an implementation of a JSR?
74% responded said yes vs. 16% who said no. Reasons expressed were a preference for vendor neutrality and a perception that standards-backed technologies are a safer bet.
- Would you like to see the JCP developing standards around any of the following areas?
- If you've not participated in the JCP what is the reason?
- What type of software do you write?
| 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% |
NoSQL databases received the majority followed by improvements to the Java SE. The survey results also declare: "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."
Fully 27% would like to see more effort put into refining existing Java SE and EE standards.
| 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% |
The survey concludes from this result that "JCP members need to make more effort to publicise and explain the JCP and demystify it to day-to-day developers."
| 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% |
The vast majority are doing some combination of SE and EE, with some alternative enterprise stack like Spring.
The survey was organized by Dr. Richard Warburton, a key contributer to LJC.
Dr. Warburton summarized the results for InfoQ
I think one of the key results for me is that developers do really value standards. At the moment the hype and the buzz is elsewhere and a lot of people have been openly critical of the JCP itself. When you actually ask developers they do want standards and its partly because they want vendor neutrality, but its also partly because they feel that they can rely on the future of a standards backed product.
I think the other thing that I was surprised about was that there were a lot of people who weren't participating in the JCP because they weren't sure how. In the LJC we've tried quite hard to improve participation levels through a program called Adopt-a-JSR which has been very successful but this survey shows us how much more work there is left to do. It could easily be 10x or 100x bigger and that's good for both standards implementers and also day-to-day developers on the JVM platform.