JEP 398 et JEP 411 Les fonctionalités dépréciées (pour suppression) du JDK 17

Contexte

Le JDK 17 continue de bouger. cela implique aussi que certaines fonctionnalités soient dépréciées. En effet, le JDK s’adapte selon son utilisation et les besoins des développeurs. Certaines techniques qui ont fait le succès de Java sont devenues obsolètes. La dépréciation pour suppression permet au dévéloppeur Java de savoir le sens des évolutions Java et de pouvoir s’anticiper les changements.

JEP 398 Deprecate the Applet API for Removal

Les applets Java ont fait fureur dans son temps (début du Web) et cela a contribué à la popularité de Java. Mais, le Web a évolué aussi de son côté : HTML5, CSS et JavaScript. Les applets Java ne sont plus supportées par aucun navigateur moderne (depuis 2015).

De ce constat, les Applets franchissent un pas vers leur suppression. L’API Applet était déjà dépréciée par la JEP 289 : Deprecate the Applet API inclus dans le JDK 9.

Cela inclut les classes et interfaces suivantes :

  • java.applet.Applet

  • java.applet.AppletStub

  • java.applet.AppletContext

  • java.applet.AudioClip

  • javax.swing.JApplet

  • java.beans.AppletInitializer

avertissement Il est intéressant de noter dans la première JEP 289, ils avaient déjà précisés (en 2016) qu’ils feraient la dépréciation pour suppression lors de la prochaine version majeure. Chose faite avec cette version LTS.

JEP 411 Deprecate the Security Manager for Removal

Le gestionnaire de sécurité est un héritage de Java 1.0. C’est une solution qui permet de sécuriser le code Java, notamment côté client dans le cadre des applets notamment.

Il a été revu dans le JDK 1.2 pour appliquer le principe du moindre priviliège.

La configuration avec l’ensemble des permissions est très complexe (fameux fichier java.policy). La configuration n’est pas globale mais elle peut être spécifique à une librairie. Voici un exemple de fichier policy pour la base de données derby

Par exemple, lors de l’utilisation d’une librairie, il fallait configurer les droits associés à cette librairie. Cela n’est pas simple lorsque nous sommes simple utilisateur de cette librairie. De plus, il était nécessaire de rajouter la configuration pour les dépendances de la librairie.

Donc, en final, nous avions très souvent :

  • Pas de sécurité activée,

  • Sécurité activée avec toutes les permissions accordées (équivalent au point précédent),

  • Un fichier de sécurité mal configuré (plus problématique car le développeur se sent protéger).

Donc, au final, cela était rarement utilisé côté serveur.

astuce De mon expérience, je l’ai utilisé une fois pour permettre la mutualisation de trois serveurs d’applications sur une machine dont chacun serveur d’applications devait pouvoir accèder uniquement à sa base. Nous devions pouvoir le garantir en tant d’exploitant du serveur d’applications (et non développeur de l’application).

L’équipe d’OpenJDK souhaite profiter de la dépreciation pour suppression des Applets (JEP précédente) pour l’accompagner par la dépréciation pour suppression du gestionnaire de sécurité.

Cela est un signal fort à la communauté. Cela a été l’occassion de beaucoup d’échange sur les listes jdk-dev et security-dev du projet OpenJDK.

avertissement Une des utilisations fréquente est aussi la protection contre System::exit. Ainsi, l’application s’assure qu’un plugin (par exemple) ne demande pas l’arrêt de la JVM (Ex: NetBeans ou JIRA).

Et maintenant ?

La JEP n’intègre pas d' alternative au gestionnaire de sécurité. En revanche, des pistes sont à explorer en parallèle et dans le futur :

  • Sécuriser l’accès aux codes natifs. (Incubateur pour le JDK 17, prochain billet à venir),

  • Surveiller l’accès aux ressources : Utilisation de JDK Flight Recorder avec de nouveaux événements,

  • Bloquer l’accès à l’api System::exit via une nouvelle API,

  • Sécuriser la désérialisation (prochain billet à venir),

  • Sécuriser le traitement des fichiers XML (JAXP) : Activer par défaut le mode sécurisé de JAXP,

  • Trouver une alternative pour JAAS au niveau de Subject.doAs.