Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Java News Roundup - Week of April 5th, 2021

Java News Roundup - Week of April 5th, 2021

This item in japanese

Lire ce contenu en français

It has been a relatively quiet week for OpenJDK and JEP news. JEP 409: Sealed Classes and JEP 410: Remove the Experimental AOT and JIT Compiler have been promoted to Candidate status, although they are still not targeted for any release.

The latter of these marks the end of the road for the Graal compiler in OpenJDK. The Experimental JVMCI interface for compilers will still be present in OpenJDK but the Java-in-Java version of Graal will no longer be shipped. Development of the Graal technology will still continue in Oracle's GraalVM project, however.

Elsewhere, Apache Maven released version 3.8.1 of the popular Java build tool.

Google introduced TestParameterInjector, a parameterized test runner. This tool is for JUnit 4, as JUnit 5 already supports parametrized tests through the junit-jupiter-params library.

In the Enterprise Java space, the 2021 Jakarta EE Developer Survey was launched and is open through April 30, 2021.

Payara announced the release of version 5.2021.2 of Payara Platform Community. As well as the community release, Payara Platform Enterprise 5.27.0 was also launched and comes with a range of improvements and new features, including an update to the Upgrade Tool; an automated JBatch Job execution data cleanup feature, and the arrival of a pluggable Notifier API.

The Glassfish application server is now Java 16 compatible - this means Glassfish joins the growing number of popular Java libraries and frameworks that are known to be Java 16 compatible.

Unlike other recent Java feature releases, Java 16 has an additional barrier to adoption - in the form of JEP 396. This JEP changes the default permission for reflective access to the JDK internals to Deny (from previously permitting and issuing a warning), although in Java 16 it is still possible to restore the status quo ante by use of a command-line flag.

This change means that, without user intervention, applications that depend on libraries that still leverage encapsulation-breaking access to the internals will now stop working. This makes the migration to Java 16 potentially less smooth than for other version upgrades.

This has been discussed on the Twitter hashtag #AllTestsGreenOnJDK16 promoted by Mark Reinhold and others.

Rate this Article