Oracle a marqué l'API Applet pour suppression dans la JEP-398. La démarcation fait suite à plusieurs années d'avis d'obsolescence (JEP-289) après que tous les principaux navigateurs ont supprimé la prise en charge du plug-in NPAPI qui était utilisée par les Applets Java depuis le dernier millénaire.
Les applets Java étaient utilisées à l'origine pour les applications Internet riches à une époque où les navigateurs avaient moins de puissance et moins de standards pour le développement d'applications. La capacité d'activation des applets Java était fournie par Netscape Plugin Application Programming Interface (NPAPI) pour exécuter des applications Java dans un bac à sable dans le navigateur. NPAPI est apparu pour la première fois dans les navigateurs en 1995, bien avant l'arrivée de Mozilla (2005 ) et la première version de Chrome (2008).
Avant les standards des navigateur modernes, ces applets étaient souvent utilisées pour des activités telles que les transferts de fichiers, l'authentification et divers autres cas que JavaScript ne pouvait pas gérer. Les navigateurs ont commencé à supprimer la prise en charge de NPAPI en 2015 pour simplifier la maintenance et l'exploitation en tandem avec le livre blanc publié par Oracle, «Migrating from Java Applets to plugin-free Java technologies.»
Bien que la sécurité ait été un sujet d'intérêt lié aux applets Java avant les modifications de l'API de 2015, de nombreuses organisations ont pu protéger leurs clients grâce à des outils de gestion tels que Deployment Rule Sets ou le verrouillage de la compatibilité Java/navigateur dans un environnement Citrix isolé
Alors que les versions précédentes de Java ont marqué les applets Java comme obsolètes, les API ont été laissées en place pour éviter les problèmes de compilation ou d'exécution avec des applications qui exploitaient les API d'une manière ou d'une autre, même sans utiliser la fonctionnalité de l'applet. Cette fonctionnalité, marquant les éléments comme obsolètes et retardant la suppression, était standard dans Java et OpenJDK pendant environ les 20 premières années de la plate-forme.
InfoQ s'est entretenu avec Dr. Deprecator, alter-ego du contributeur OpenJDK Stuart Marks sur la façon dont le projet OpenJDK utilise la balise @Deprecated pour communiquer et ce qui est obsolète.
Java 9 a amélioré l'annotation @Deprecated pour ajouter un attribut nommé forRemoval. Suite à la modification de la JEP-398, les API Applet auront l'attribut forRemoval = true défini, ce qui obligera les compilateurs et les outils à émettre des avertissements plus forts avant que les API ne soient réellement supprimées. Le passage à travers plusieurs niveaux d'avertissement permet d'éviter la perturbation du code de la communauté, conformément à la présentation de 2015 de l'architecte du langage Brian Goetz, «Move Deliberately and Don't Break Anything.»
Les autres éléments qui ont été supprimés des API Java core sont :
- CORBA, un framework d'interopérabilité par l'Object Management Group (OMG) de 1991 avec sa dernière version en 2012.
- JAXB, l'ensemble d'API XML maintenant géré dans Jakarta EE.
- Nashorn, un moteur d'exécution JavaScript.
- Modifications plus petites telles que Thread.stop(Throwable), System.runFinalizersOnExit et RMI Stub Compiler.
Les utilisateurs curieux de voir si ce changement affectera leur application ou leurs dépendances peuvent tirer parti d'une combinaison de deux outils sur leur code et ses dépendances.
- jdeps, un outil qui analyse l'utilisation d'API mettant en danger la compatibilité. Cela peut aider une équipe à détecter si elle utilise des API non spécifiques susceptibles de changer.
- jdeprscan, un utilitaire d'analyse de code par rapport aux annotations d'obsolescence pour comprendre comment il sera en danger s'il ne s'adapte pas à l'abandon en attente.
Lorsqu'on lui a demandé si la dépréciation pouvait être appliquée à la sérialisation, au SecurityManager orienté applet et à d'autres aspects, Dr Deprecator a simplement répondu : «hold my beer», pour indiquer qu'un changement pourrait être en cours.