In Development
Java 17: Features and Development - Inside Java Newscast #6 - read the full article about java development, Development and from Java on Qualified.One
Software Developer
Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. Im Nicolai Parlog and later youll get too see Jose Paumard, were both Java developer advocates at Oracle. Today, we got two topics for you: 1. the list of JEPs that made it into JDK 17 and 2. the release process that governs the work on JDK 17 for the next three months Ready? Then lets dive right in! Thanks Nicolai! Indeed we have the list of the happy selected JEPs which will make it to the JDK 17. JDK 17 is scheduled for next September and there are some really cool and exciting features in it. 14 JEPs are selected, some of them have a direct impact on the code you are going to write and I would like to focus on these.
My preferred feature is the addition of the sealed classes which is JEP 409. Sealed Classes are part of the Amber project and is one more step towards pattern matching.
Speaking of pattern matching there is one more JEP, 406, which is a preview feature called pattern matching for switch. This is also one more step towards pattern matching. You may be thinking well thats one more step plus one more step, sounds like two more steps? How many one more steps do we need to have complete pattern matching? Well thats a tough question but there will be more one more steps thats for sure! So stay tuned for more.
These first two JEPs will impact every Java developer. Several JEPs are very interesting but maybe not for everyone. For instance JEP 415: Context-Specific Deserialization Filter. You may remember that JDK 9 introduced the concept of deserialization filter to enable the validation of incoming serialized data, coming from untrusted sources. You know that serialization may be the source of many security issues, and this filtering is done at the JVM level. This JEP gives you more possibilities in this field than what was available in Java 9.
JEP 356: Enhanced Pseudorandom Number Generators just does that: add new random number generators algorithms to the JDK.
JEP 306: Restore Always Strict Floating Point Semantics. It has to do with how your floating point calculations are conducted on the Floating Point Unit of your CPU. Sometimes you write your calculation using the `float` primitive type, but it is really executed in `double` by this FPU. This can lead to slightly different results maybe its not too bad for your application but maybe it is so this. This JEP is there to ease the development of your numerically sensitive code.
Some other JEPs are welcome evolutions of the platform. New MacOS rendering pipeline is JEP 382 and the MacOS aArch64 port is JEP 391.
Some others deprecate or remove old or not that much used features of the platform. This is the nostalgic part of the newscast. RMI activation is removed with JEP 407 and the Applet API is deprecated for removal with JEP 398. And that means something for all people that started with Java by writing Applets.
What are you telling me "Good Riddance"? The experimental Ahead of Time and Just in Time compilers that were added to the JDK 9 as an experimental feature are also removed with JEP 410 and the Security Manager is not removed but deprecated for removal - thats the JEP 411.
One more sensitive JEP is JEP 403: Strongly Encapsulated JDK Internals. This JEP is the successor of JEP 396 and it strongly encapsulates all internal elements of the JDK except for critical internal APIs as defined and listed in JEP 260, which includes sun.misc.Unsafe. So just to be clear sun.misc.Unsafe remains available.
And we have two more incubator JEPs. The first one is the Foreign Function & Memory API JEP 412 delivered by the project Panama. This JEP aims to bring a replacement of JNI the Java Native Interface with this new API in a nutshell this API is about accessing memory outside of the heap, and call functions written in another language. You can already do that with ByteBuffer and JNI but the patterns given by this new API are safer. So if you need that in your code you should definitely check this JEP.
And the last incubator JEP is the JEP 414 Vector API nothing to do with `java.util.Vector`. Its about bringing SMID parallel computations capabilities to the JDK which is great. If you want to learn more on this topic there is an episode of the Inside Java Podcast about it with John Rose and Paul Sandoz, there is a more in-depth talk by Sandia Viswanathan and Paul Sandoz on this topic also, and the newscast by Nicolai Parlog all available on this channel.
And now I need to send you back to the studio, and I cant say Im super comfortable with it. Nicolai, can I leave it to you? Today, June 10th, the JDK 17 repo gets forked and rampdown phase 1 starts. But... what exactly does that mean? I didnt know myself, so I looked into it and heres the summary. If you want to know _all_ the details, check out Java Enhancement Proposal number 3 on the JDK Release Process. As usual, youll find a link to that in the description.
Lets start by talking about the issues, which include new features, all kinds of improvements as well as bugs of course. Somewhat confusingly, though, the OpenJDK community usually refers to all of them as bugs - yes, even new features like the ones Jose just described. Sticking with the official terminology used in JEP 3, Ill do that as well, but keep in mind that not all bugs are actually _bugs_. Anyway, OpenJDK tracks bugs in a JIRA instance referred to as the _JBS_, the _JDK Bug System_.
In the context of an upcoming release, 17 at the moment, bugs fall into two categories: * _current_ bugs relate to recent work and only affect the upcoming release * _targeted_ bugs are older - they affect already released JDK versions and are planned to be fixed in the upcoming one Besides that, bugs have one more property thats important to our inquiry and thats the _priority_, which ranges from P1, the most important, down to P5.
Now lets quickly talk about the OpenJDK repositories. Theyre hosted on GitHub under the OpenJDK organization and there are quite a few of them but the most important one is the JDK main line, simply called _jdk_.
And this is where a new releases journey begins. Each June and December the mainline is forked into a stabilization repository called _jdk$VersionNumber_, so today thats gonna be _jdk17_ - the fork works very much like a release branch. This is also the time when the release process officially starts. It stabilizes the upcoming release and minimizes the risk of introducing new problems by only working on increasingly important fixes under an increasingly strict process. Usually, these fixes will be developed in the stabilization fork and then ported to the main line.
Rampdown phase 1 starts with the fork and lasts a few weeks - for JDK 17 thats gonna be five. All code-related bugs with a priority of P4 or lower (meaning less important) wont be fixed before the release. Of the remaining P1-3 bugs, the focus is on the current ones (meaning those that were recently introduced). Addressing targeted bugs (which remained from older releases) is optional.
If a JDK developer deems a bug with priority 1 or 2 to take too long or be too risky, they can use the _bug-deferral process_ to potentially push the bug to a later version.
In this phase, bugs of any priority that only affect tests or documentation may be still be fixed.
Rampdown phase 2 works a bit differently from rampdown phase 1 and tightens the screws.
First, only current bugs can be worked on. Targeted bugs will be fixed in the future.
Second, the priority requirements are stricter: Priority 3 is out and only bugs with priorities 1 and 2 will be worked on. For code that goes into the released JDK, that is, test and documentation bugs of all priorities can still be fixed.
And third, the _fix-request process_ must be used to decide whether a bug will be worked on. This process involves a group or area lead who will help make sure that fixing the bug for the upcoming release is a reasonable idea.
For JDK 17, rampdown phase 2 lasts three weeks until August 5th.
And on that fine first Thursday in August, the first JDK 17 release candidate will be built. After that, only the most critical bugs can be addressed. To be fixed, * a bug must be current * it must be priority 1 * it must have passed the aforementioned _fix-request process_ * and it must actually impact released code The hurdle is intentionally steep to make sure the release candidate is kept stable. But if further bugs are discovered and fixed, new candidates will of course be released.
Hopefully all remaining problems will be found and fixed within the next two weeks, so that on August 19th the final release candidate can be built. And thats it! Ideally, while more and more projects start building against the release candidate, nothing critical is found and after a few weeks, four in this case, the new JDK version reaches general availability and the release candidate is promoted to be the actual release. For JDK 17, thats gonna be September 14th.
17 is of course also the next long-term support version and we planned to go into that as well, but youve suffered through enough process details for one episode, so well talk about that one in two weeks. If a lengthy explanation of who fixes what in which forks isnt a reason to subscribe, I honestly dont know what is.
And thats it for today on the Inside Java Newscast. If you have any questions about what Jose and I covered in this episode, ask ahead in the comments below and if you enjoy this kind of content, help us spread the word with a like or by sharing this video with your friends and colleagues. Ill see you again in two weeks. So long...
Java: Java 17: Features and Development - Inside Java Newscast #6 - Development