La semaine a été relativement calme pour les actualités OpenJDK et JEP. JEP 409 : Sealed Classes et JEP 410 : Remove the Experimental AOT and JIT Compiler ont été promues au statut de candidat, bien qu'elles ne soient toujours pas ciblées pour aucune version.
Cette dernière JEP marque la fin de la route pour le compilateur Graal dans OpenJDK. L'interface JVMCI expérimentale pour les compilateurs sera toujours présente dans OpenJDK mais la version Java-in-Java de Graal ne sera plus livrée. Le développement de la technologie Graal se poursuivra cependant dans le projet GraalVM d'Oracle.
Apache Maven a publié la version 3.8.1 du populaire outil de compilation Java.
Google a présenté TestParameterInjector, un exécuteur de tests paramétrés. Cet outil est pour JUnit 4, car JUnit 5 prend déjà en charge les tests paramétrés via la bibliothèque junit-jupiter-params.
Dans l'espace Enterprise Java, le 2021 Jakarta EE Developer Survey a été lancé et est ouvert jusqu'au 30 avril 2021.
Payara a annoncé la sortie de la version 5.2021.2 de Payara Platform Community. Outre la version communautaire, Payara Platform Enterprise 5.27.0 a également été lancé et est livré avec une gamme d'améliorations et de nouvelles fonctionnalités, y compris une mise à jour de l'outil de mise à niveau; une fonction automatisée de nettoyage des données d'exécution de JBatch Job et l'arrivée d'une API Notifier pluggable.
Le serveur d'applications Glassfish est désormais compatible Java 16 - cela signifie que Glassfish rejoint le nombre croissant de bibliothèques et de frameworks Java connus pour être compatibles avec Java 16.
Contrairement à d'autres versions récentes de fonctionnalités Java, Java 16 présente un obstacle supplémentaire à l'adoption - à cause de la JEP 396. Cette JEP modifie l'autorisation par défaut pour les accès via reflexion aux éléments internes du JDK en Deny (précedemment il était à permit avec l'émission d'un avertissement), bien que dans Java 16, il soit toujours possible de restaurer le statu quo initial à l'aide d'un indicateur de ligne de commande.
Ce changement signifie que, sans intervention de l'utilisateur, les applications qui dépendent de bibliothèques qui exploitent encore un accès aux composants internes encapsulés cesseront désormais de fonctionner. Cela rend la migration vers Java 16 potentiellement moins fluide que pour les autres mises à niveau de version.
Cela a été discuté avec le hashtag Twitter # AllTestsGreenOnJDK16 promu par Mark Reinhold et d'autres.