OpenJDK Requesting Community Feedback on Java 9 Features
OpenJDK Adoption Group leader Dalibor Topic has compiled a comprehensive list of feature additions, changes and removals projected for Java 9. Martijn Verburg, Java Champion and member of the Adoption group, spread the news to several prominent Java communities, and is soliciting community feedback:
It's important that this message of reviewing and testing Java 9 early gets spread through the community, so please do pass onto your internal mailing lists, twitter followers, mention it at your meetings etc! I also strongly urge all of you individually to take a look at the JDK 9 outreach page where you can find the changes and some suggested early testing you can do. For further information and to get involved going forwards please join us in the Adopt OpenJDK programme as well as the Adopt Group in OpenJDK.
As a member of the Java Champions, this editor posed some questions to Verburg and the Java Champions group:
InfoQ: Martijn, you expressed a sense of urgency for the community to look at the list of new JDK 9 features as well as the JDK 9 outreach page. What kind of input are you expecting the community to provide there?
Martin Verburg: In general, developers, QA and production support teams should start adding the Java 9 early access builds to their environments and CI servers to start testing. Oracle publishes regular JDK 9 builds at http://jdk9.java.net that people can try out.
InfoQ: How will life change for Java developers with the Java 9 release?
Verburg: Assuming the IDE vendors and major toolchain authors (think JUnit & friends, Maven, Gradle, Ant, etc.) stay in sync, then most developers won't get too badly caught out. For example, under the hood, familiar constructs as rt.jar will no longer exist under modularisation, Java's runtime will be in modules instead. Although the Classpath will be kept for backwards compatibility, all will be encouraged to use the new module system and its specific lookup paths as opposed to using the Classpath. Most developers will need to read, understand and then hopefully start to implement their projects in this new modules system as opposed to using classpath and JAR files.
People will want to look out for unrecognized VM options. From the outreach page:
If your application's startup script launches the JDK 9 JVM with an unrecognized VM option, it will exit and let you know that it couldn't create a VM because of that unrecognized VM option. Some of the VM flags that were deprecated in JDK 8, have been removed in JDK 9 - like those relating to the permanent generation, which was removed in JDK 8.
People will want to make sure they're not using deprecated or removed APIs. From the outreach page:
In JDK 8 a new Java Dependency Analysis Tool (jdeps) was added to help developers understand the static dependencies of their applications and libraries. It can help you find dependencies on any internal, unsupported or private APIs that your application or its libraries use. A program using such APIs is not guaranteed to work in future versions of JDK 9 or even the same platform. For more information, please see this document.
For best results, make sure to run jdeps from the most recent JDK 8 update release or JDK 9 Early Access build.
Ben Evans: People also need to test the G1 Garbage Collector as there is a proposal to set that as the default in Java 9. This could radically change the runtime behaviour in terms of pause times, throughput and heap size of your application.
Kirk Pepperdine: In addition to what Ben said, either by design or by accident, each of the collectors has a time/space tradeoff baked in. G1 trades space for time whereas the parallel collectors trade time for space. So that will create some differences. In addition, the G1 will use a minimal amount of memory but ironically only if you configure it to have access to lots of memory. CMS works very similarly, but the Parallel collector is very exact in the amount of memory it will use. There are workloads that you can run using the Parallel collector with say, 1g of heap where G1 and CMS will fall over given the same 1g. There are workloads where G1 and CMS will cope very well but the parallel collector will yield some very long pause times. There is also a fairly complex feedback loop that exists between how GC behaves and how your application is using memory. These two process can affect one another, sometimes in some very profound ways, and always in some very unpredictable way.
Verburg: It's best to do “before and after” analysis of your GC. If you are using the default collector (i.e. you haven't specified it) then simply run your application through its usual endurance and load tests and make sure you generate the GC log(s) correctly by adding the following flags to your command line when starting the app (‑XX:+PrintGCDetails -XX:+PrintTenuringDistribution -Xloggc:<location of gc log>).
Capture that log to one side and repeat the test using the latest build of Java 9 so that the collector defaults to G1.
You can then use a tool like jClarity's Censum (7 day free trial - disclaimer, I'm the CEO) to get a deep understanding of your before and after behaviour. If you see better or worse behaviour in terms of throughput, pause times or heap size required with G1 then you can report that to the email@example.com mailing list. The firstname.lastname@example.org mailing list can be useful if you have other general questions about GC.
InfoQ: Is there a Java 9 hallmark feature, comparable to Java 8's Project Lambda?
Pepperdine: Modularity is the big ticket item on the table. It’s an item that could make or break this release or even Java. It all depends on the feedback that OpenJDK gets back from the community. My personal experiences with modularity in other languages has been very mixed. Modularity can be useful as long as we don’t over normalize to an academic level.
InfoQ: Some of these JEPS seem to have a way to go, are we still on time for the projected go live of Sept 2016?
Verburg: I don't work for Oracle and so I can't comment on timelines, but from the progress I've seen in OpenJDK, yes it looks like we'll make that deadline easily. In fact the goal is to be code complete by the end of 2015 and have 9 months of testing and working with the community on building support for the new module system.
InfoQ: Who are the other key players driving Java 9?
Verburg: Dalibor Topic is the Principal Product Manager for OpenJDK at Oracle. He's been involved in OpenJDK and OSS for a very long time and is an all round top bloke (That's NZ/Aussie for good guy :-)). Dalibor leads the Adoption Group within OpenJDK whose aim is to lower barriers to community involvement in the building and maintenance of OpenJDK.
I helped start the Adopt a JSR and Adopt OpenJDK programmes, initially aimed at Java User Groups to get more involved in standards around Java. Much of the Adopt OpenJDK programme was moved to OpenJDK proper (the Adoption Group), but some aspects of it remain external due to the 'blue sky' nature of some of the ideas.
There are too many names to mention, officially the Adoption Group members are (http://openjdk.java.net/census#adoption). But in reality there are many, many more who do the heavy lifting such as Richard Warburton, Mani Sarkar, Ben Evans, John Stevenson. Joe Darcy, Jonathan Gibbons, Stuart Marks, Brian Goetz, Alan Bateman and many others from Oracle are all highly supportive and assist in making hack days etc a reality.
InfoQ: You’ve mentioned Adopt a JSR, Adopt OpenJDK, and the Adopt Group. can you tell us about those and how can the community get involved in making Java great?
Verburg: Both Adoption Programmes came out of the work that the London Java Community (LJC) and SouJava (Brazil's largest Java User Group) was doing at the Java Community Process (JCP), the Java standards body. We decided that the best way we could help standards was from a technical standpoint and to get developers involved earlier in the process, testing out prototypes etc. The two programmes were launched and we've added ~30-40 Java user groups around the world who regularly participate in Java standards and working on OpenJDK.
Adopt a JSR focuses on Java EE standards as well as some large features of Java SE (e.g. modularisation) and The mobile/embedded parts of Java (Java ME / CLDC etc). Heather van Cura from the JCP is now the de-facto lead of this programme.
Adopt OpenJDK spun off from Adopt a JSR when we realised that a large part of OpenJDK was separate from the Standards Body and that there was a host of non standards work that people were interested in working on for core Java.
InfoQ: It looks like things are being deprecated. Can you talk about backward compatibility in Java 9?
Evans: Modularity has the potential to break a lot of applications, and so far I see no evidence that people are thinking about it as an issue. There is the jdeps tool shipping with Java 8 that can identify places where breakage can occur, but I anticipate that the real danger to applications is their transitive exposure to private APIs via the use of frameworks. It's therefore crucial to get framework vendors and OSS projects to scan their libraries with jdeps, and wherever possible, to consider refactoring into safe and problematic pieces (and ideally into smaller units that play well with Compact Profiles).
What about the controversial Unsafe class; will that be replaced by a first class citizen?
Verburg: sun.misc.Unsafe is a commonly used but private and officially unsupported API that many vendors (in particular in the infrastructure space) use to get native like performance for low level interactions with memory, the O/S, and in some cases hardware. The current plan will be to have it hidden by default (there will be a way in the new module system to gain access to it) and to have safe parts of it re-implemented in new modules/classes as first class citizens and the unsafe parts to be deprecated and removed.
OpenJDK and the industry at large are working on several proposals. This document sums up the state of sun.misc.Unsafe in relation to Java 9 and the gaps that are left to be filled.
Pepperdine: All VMs have backdoors to account for features that they can’t or won’t allow, or simply for features they didn’t imagine. In this regard, the JVM is no different with it’s implementation of Unsafe. That certain things that could have Java equivalents have ended up in Unsafe is unfortunate. However, at the time, it was safer to put them into Unsafe than it was to put them in the JDK proper. Do we need to get rid of Unsafe, Yes! Do we need to keep Unsafe? Yes. How do we reconcile these seemingly conflicting positions? Well, we need to plan a migration path to move the stuff that we now know how it should be implemented out of Unsafe and into the JDK proper. That said, we simply cannot shutdown Unsafe as it has become an essential pathway to features that frameworks need.