Java Language Architect Brian Goetz on Java and the JDK

Show Notes

• 02:34 The six-month cadence is a change in both the release of the JDK and in the planning process, leading to improved flexibility and efficiency. Long release cycles of three to four years previously meant more time spent in release planning meetings rather than on engineering work. Smaller features now don't have to wait for release years after being completed.
• 05:10 While there was some resistance to the idea of the faster cadence for the platform, the ability to work on and release smaller features means less disruption to Java developers when upgrading to the latest release. Java 9 had some major changes, which could have been addressed with compiler warnings and time to adapt, had it been rolled out more gradually.
• 07:41 The feature pipeline is in better shape than ever, because of the incremental delivery. When we were working on one major feature for years, like lambda, you don't bother to have a pipeline. When you release that, and you ask, "what's next?" no one has even been thinking about it.
• 09:08 Oracle JDK and Open JDK are essentially the same. The goal is to get to identical binaries with two different licenses. Some closed source features have been open sourced.
• 10:01 Most of the other JDKs out there are based on Open JDK, from a specific changeset. The differences are largely in which bugfixes are included.
• 11:17 Java 10 was the first release on the new cadence, and was a bit of a proof-of-concept that the cadence could work. Despite some concerns that there wouldn't be any features released in Java 10, the number of JEPs was on pace with the longer release cycle.
• 11:45 Java 10 included type inference for local variables. Goetz thinks, for many people, that feature alone justifies switching to Java 10. It's also a good example of the tension faced when adding new language features, since one set of developers were clamoring for something available in many other languages, and the other group worrying that it would allow people to write bad code.
• 13:52 Deciding what features to include in Java focuses mostly on how intrusive a change will be. A bugfix, which can be clearly demonstrated with tests and code to fix the bug, it usually easy to approve. More disruptive changes are going to be given a lot more scrutiny. Language evolution is a specialized skillset, both within Oracle and by members in the community.
• 16:05 The old model of having one JDK installed on your system has gone away as more people are moving to containers. Being able to specify which JDK your app requires allows teams to be much more flexible in deciding when to upgrade.
• 17:00 As the time between releases gets smaller, the time to get feedback from people also gets smaller. When a release took three years, we had lots of people using a new feature and providing feedback before it went live.
• 17:42 To provide more feedback, we have incubator modules, which are libraries we think are stable enough to try out, but not recommending people use in production.
• 19:10 Flight Recorder was previously a commercial feature, and is a full production feature in Java 11. Flight Recorder is an amazing monitoring tool where the JDK maintains a circular ring buffer of events. Since it gets automatically written over after a configurable amount of time, you can set up triggers to write certain events to a log file. This allows really useful instrumentation of a production system, with very low overhead. As it is open sourced, other libraries will be able to write their own events, giving a more holistic view.
• 20:46 Shenandoah and ZGC are both low-latency garbage collectors. All garbage collectors are a trade-off between latency and throughput, and this is why there are so many options for garbage collection in Java. ZGC was started as a commercial product, and then turned open source. At the same time, Shenandoah was being developed in the open, primarily by Red Hat. Both landed as experimental features at about the same time, and each focuses on a slightly different sweet spot.
• 22:53 A preview feature is sort of an analog to incubator features for language and JVM, with a higher bar. Preview features have full specifications, and are close to complete, but we want people to have six months to use them before they are finalized. They are similar to a feature flag, with an option to turn all preview features on or off at compile time.
• 24:29 Expression switches is the first preview feature. It allows you to use a switch as an expression as well as a statement. Many switch statements could be written more concisely as expressions, but the syntax didn't allow it. This is a "Let people say what they mean" move, with the result being more compact and reliable code.
• 25:03 Expression switches were segmented out of the larger feature of pattern matching, which is part of Project Amber. Because it was a required sub-feature that was completed, rather than making people wait until all the pattern matching was done, the decision was made to release expression switches on their own.
• 25:45 Almost any non-trivial feature is going to take more than six months to complete. The side projects like Amber and Valhalla allow work to proceed on these features. When they are ready, the code can be extracted and merged into the next train release.
• 26:37 Value types are a major undertaking, spanning four years and five prototypes. It's approaching something that someone might want to use, but it's not done.
• 27:24 Value types are important because the world of computing changed out from under us. The hardware we run our programs on has changed a lot since Java was first being developed in the early '90s. For example, the performance difference between a memory fetch and an arithmetic operation has grown by almost a factor of a thousand. Using the latest prototype, benchmark tests were up to twelve times faster for the value types. Value types are part of Valhalla.
• 30:23 Amber is an umbrella project for all the smaller language features, such as variable type inference and expression switches. Features are added to amber, then removed when they are placed on a train, making room for new features.
• 31:21 The goal of Project Loom to add support for delimited continuations in the JVM, and then expose that through Java libraries through a mechanism like fibers. Again, this is important because the way we deal with asynchrony has changed in the last 30 years. We started with callbacks, but they made code hard to read, so we created threads. Fibers is playing the same trick on threads, making reactive code more readable.
• 33:14 A fiber is coroutine -- a lightweight unit of execution that borrows a thread when it needs to do some computation.
• 34:02 In C# and Kotlin, they introduced a notion of an asynchronous task in the language, with well-defined points using keywords like await or yield that instruct the complier to create a state machine behind the scenes. This places some restrictions on what you can do within an asynchronous method. The continuation approach, used by Go and Java, is less restrictive because there's nothing you can't do in a fiber, but it requires support deeper in the runtime.
• 35:45 It has always been possible, but not easy, to call native C code from Java through the Java Native Interface (JNI). Project Panama aims at making the interaction with native libraries both easier and safer. One layer is to be able to invoke native methods. On top of that are some tools, like Jextract which you point at an .h file and it generates the metadata and Java interfaces to call it. Previews of the lowest level features are probably about a year away.
• 38:25 Java developers and C# developers have a lot in common. In the languages, we're solving a lot of the same problems, and finding the same answers.
• 39:29 Project Sumatra was an experiment aimed at compiling down to GPUs. It wasn't a very successful experiment, but provided a lot of learning. It led to collaborative work between Oracle and Intel to expose vectoring operations up into the programming model. That type of work will be helpful for future language improvements to take advantage of GPUs and FPGAs.

Related news post: Raw String Literals Removed From Java 12 as Feature Set Frozen