Find out what’s going on behind the scenes of Java, and how new features come to life
In a previous post we went over the new and pending features for the upcoming Java 9 release, and briefly mentioned the process that a new feature goes through before being added to the next release. Since this process affects almost all Java developers, but is less known to most of them, this post will focus on giving an insider’s view of Java (and how you can suggest that new feature you always wanted). We felt the best way to understand how new features come to life would be to ask the people who are responsible for bringing them into life.
We spoke with 2 Java Executive Committee members, Gil Tene and Werner Keil, together with Richard Warburton, a London Java Community member, and asked them about new features in Java and what kind of new capabilities they’d like to see in the future. This post will cover the first part of the interview.
But before we do that, here are the main players that take part in creating and voting on new features:
Groups – Individuals and organisations with a mutual interest around a broad subject or a specific body of code. Some examples are Security, Networking, Swing, and HotSpot.
Projects – Efforts to produce a body of code, documentation or other effort. Must be sponsored by at least one group. Recent examples are Project Lambda, Project Jigsaw, and Project Sumatra.
JDK Enhancement Proposal (JEP) – Allows promoting a new specification informally before or in parallel to the JCP, when further exploration is needed. Unlike JSRs, may also contain features that have no specification-level visibility (e.g. new garbage collector or JIT implementation). Accepted JEPs become a part of the JDK roadmap and assigned a version number.
Java Specification Request (JSR) – The actual specification of the feature happens in this stage, can be either coming through Groups/Projects, JEPs or from individual JCP (Java Community Process) members. An umbrella JSR is usually opened for each Java version (Also called a platform JSR), this has yet to happen with Java 9. Individual members of the community can also propose new Java specification requests.
How do new features find their way into Java?
Warburton: “The real answer is that someone wants the feature. That person could be an internal engineer or project manager at a big vendor or an outside member of the community. Either way it needs to be something that meets quite a strict criteria:
- Serious User Demand: It needs to be something that is a consensus benefit for the whole community. Example: Java SE 8 adds lambdas – this is a feature that has been argued about and demanded for years.
- Tried and Tested: Standards have to last a long time and its a very difficult and expensive process to modify standards which have already been established. The consequence is that the JCP (Java Community Process) isn’t bleeding edge. Its the place to go once technologies are ready for enterprise adoption.
- Not Unique to One Vendor: Standards need to be comfortable to all vendors. Example: weak/soft/phantom references interact with the garbage collectors, so they were specified in a way that tried to minimise the restrictions that they impose on GC Design.”
“Once you’ve figured out that your feature is a good idea, you need to start the standardisation process. This involves raising a JSR – Java Specification Request – which is the atomic unit of changing Java. A JSR needs to be voted upon multiple times. Firstly to approve that its a good idea to start a JSR on this topic. Iteratively whenever a public review comes up to ensure that the JSR is headed on the right course. Finally when its time to approve the standard”.
Tene: “Java has a long history of careful and deliberate enhancements over time. One of the things that still makes Java more successful than virtually all other programming languages and environments in history is its relative success in avoiding the rapid adoption of “the latest cool thing”, and its relative consistency as a platform. This is true across the platform as a whole (Java SE, EE, etc.) but is probably most clearly followed within the Java SE platform, where I focus most of my attention. Collections, NIO, Generics, Platform-optimized Concurrent Utilities, MethodHandles, and most recently Lambda expressions and streaming library support are all good examples of features that were added and then widely adopted over time, showing their true value to the platform and their importance as much more than a fleeting fashion.”
“The JCP (Java Community Process) is responsible for capturing new features via JSRs. A successful individual, stand-alone JSR standardizes the semantics of a specific set of features or behaviors. But the ultimate success and adoption of a feature is usually demonstrated when it becomes a required part of a platform JSR, thereby becoming an integral part of the Java SE or Java EE platform. Since the creation of OpenJDK, we’ve seen much of the early stage work on features in Java SE move from being developed within JSRs to being developed within JEPs (JDK Enhancement Proposals). They all still end up being spec’d and completed as before, and become part of the Platform JSRs as well, but we see a lot more development-in-the-open, and a lot more experimentation (development of things that wouldn’t necessarily make it as JSRs).”
Keil: “3 competing JSON libraries, one for Java EE, another Oracle proprietary one bundled with Java ME 8 and yet another independent JEP based approach for Java SE 9 is probably one of the best examples where this can go wrong and contrary to user’s and developer’s need or the aim of setting ONE standard for Java. Another one would be overlapping and largely incompatible Date/Time APIs introduced with Java SE 8 (JavaFX+JSR 310) while 2 other libraries existed before under “java.util”. Java architects provide input and recommend things, but looking at e.g. Date/Time API only the worst issues they or others (including a few Executive Committee members) pointed out were addressed, while other concerns they had were brushed away.”
Can you share one personal experience you had with the Java Community Process?
Keil: “A while ago myself and Co-Spec Lead Antoine Sabot-Durand proposed a JSR for standardized CDI based connectors to Social Media and similar APIs naturally based around JSON, REST or security standards like OAuth, too. The JSR was turned down by a slight majority of 8:5. Given Seam Social and the entire Seam ecosystem at Red Hat were dropped in favor of new projects just like the entire JBoss server got a new name and brand (WildFly) around that time, the resulting Open Source project Agorava was a natural fit to replace Seam Social and many ideas we had proposed for JSR 357.”
Tene: “As part of the JCP Executive Committee, I’ve had to weigh in on approving new JSRs. In more than one case I’ve voted to reject JSRs (and advocated for others to do the same) that I thought did not belong in the platform, but most JSRs that naturally fit into the Java ecosystem do not have too high a bar to cross as long as the JSR lead signs up for the detailed work and process involved”.
Warburton: “I helped out a bit with the date and time library. I think it gave me a greater appreciation for the level of detail in which each unit of functionality or method signature needs to be thrashed out. People invest a lot of time in trying their best to get these APIs right.”
| Reference: | Java 9 Behind the Scenes: Where Do New Features Come From? from our JCG partner Alex Zhitnitsky at the Takipi blog. |
