Java 17 reference implementation JDK 17 as well as GPL-licensed OpenJDK builds have been made available this week. The first long-term support release in three years sports 14 JEPs and is meant to improve not only the language but also the way it interacts with external functions and data.
To make the programming language a little more intuitive to use, Java 17 includes a preview of a pattern-matching feature for switch expressions and statements. Up until now developers could use switch for limited types only and were restricted to constants for their case labels, which often made more complex queries tricky to construct (and read). Allowing patterns in labels and introducing new patterns altogether is therefore hoped to help devs in formulating more concise code for such scenarios.
Writing concise code can also help with the security of code, as do three of the newly integrated language features. When using Java 17, users can restrict what classes are allowed to extend or implement specific classes via the addition of sealed classes. The update also improves deserialisation filters by introducing filter factories to support context-specific scenarios, and the strong encapsulation of JDK internals by requiring developers to use the
--add-exports command line options to open or export packages.
That standardisation of any type isn’t always straightforward can be seen at the incorporation of an incubating API for interoperating with code and data outside the Java runtime. The programming interface is a merger of sorts between the Foreign-Memory Access API and the Foreign Linker API which have — at least in parts — been discussed and evaluated since 2019. This latest iteration is meant to correct some of the issues of its predecessors and offer a more stable and safe alternative to the Java Native Interface.
In order to speed up Java code a little, Java 16 sported a new API for the expression of vector computations. Java 17 comes with an updated version of the incubating feature that adds “methods for copying characters between short vectors and char arrays, and new vector comparison operators for unsigned comparisons with integral vectors”. It also translates byte vectors to and from boolean arrays, and includes “intrinsic support for transcendental and trigonometric lanewise operations on x64”.
Other than that, the Java team has provided a JDK port for macOS/AArch64 and new interface types and implementations for pseudorandom number generators. It might be worth a look for those subscribing to a stream-based programming approach.
The latest JDK release also gets rid of a couple of little-used things, such as RMI activation and the experimental AOT and JIT compiler, to keep the kit’s code base easier to maintain. Upcoming versions will get to see the elimination of the Security Manager as well as the Applet API, which have been deprecated with JDK 17.
Oracle takes it up a notch
Since Java is still mainly developed by Oracle, the company took the opportunity of the latest release to make Java users aware of some changes. Teams who have been finding the time between LTS releases a bit long will be happy to learn that Oracle currently plans to ship upcoming LTS versions in a two-year cadence instead of sticking to their three-year cycle. This is mostly meant to benefit programmers working in organisations with a strict latest-LTS-only policy, since they can get using new features a bit earlier than before.
Developers who have been pondering trying the Oracle JDK are slightly nudged to give it a go through an updated licensing scheme, which allows the use of the kit in both commercial and private settings. The previously deployed OTN license meant either a jump onto OpenJDK or a Java SE subscription once production use was on the horizon. The new Oracle No-Fee Terms and Conditions (NTFC) license also allows this, as well as redistribution, as long as no fees are involved. Free Oracle JDK releases and updates are promised to be provided “until a full year after the next LTS release” to give users some overlap to upgrade.