Java 17: Features and Development - Inside Java Newscast #6

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
Ujjaval Srivastav Inkoniq,
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