Dans les derniers efforts dans le sens de se débarrasser des modules d’extension dans les navigateurs, Apple a annoncé une expérience utilisateur par défaut sans plugin dans Safari 10 sous macOS Sierra. Les plugins Java, Flash, Silverlight, entre autres, seront donc désactivés par défaut dans son navigateur, pour donner la priorité à HTML5. Google et Mozilla ont également suivi avec de nouvelles mesures visant à bloquer Flash dans leurs navigateurs.
Il est donc clair que les éditeurs ne veulent plus de plugins dans leurs navigateurs. Voyant la possibilité d’intégrer les technologies basées sur les plugins en train d’être éliminée, Oracle a alors décidé de suivre le mouvement vers une expérience web sans modules d’extension. Au début de cette année, le géant des bases de données a en effet annoncé son intention de passer à un Web sans plugin, avant de recommander aux développeurs de migrer des applets Java vers la technologie Java Web Start. Lors de l’annonce, Oracle avait prévu que son plugin Java de navigateur devienne obsolète dans le JDK 9.
Oracle a récemment expliqué dans le JEP (JDK Enhancement Proposal) -- un processus élaboré par la société pour recueillir des propositions d'améliorations pour le JDK et OpenJDK -- comment cela sera mis en œuvre. Il s’agira de marquer l'API Applet obsolète dans le JDK 9 en ajoutant l’annotation @Deprecated(since="9" aux classes suivantes :
- java.applet.AppletStub ;
- java.applet.Applet ;
- java.applet.AudioClip ;
- java.applet.AppletContext ;
- javax.swing.JApplet.
Oracle explique que « ces annotations vont provoquer des avertissements de dépréciation qui seront émis par le compilateur Java pour tout code qui utilise cette API. Si les avertissements sont traités comme des erreurs, ils entraîneront l'échec de la compilation ».
L'obsolescence n’étant pas synonyme d'abandon, l’API Applet devrait encore exister dans JDK 10 et peut-être au-delà de cette version. Oracle explique en effet ne pas avoir l’intention de la supprimer dans la prochaine version majeure : « Nous ne voulons pas supprimer l'API Applet dans la prochaine version majeure, donc nous n'allons pas spécifier forRemoval = true dans ces annotations. Si plus tard, nous proposons de supprimer cette API nous allons ajouter forRemoval = true à ces annotations au moins une version majeure à l'avance. » Autrement dit, l’API Applet ne devrait pas être supprimée dans JDK 10 sinon, Oracle aurait ajouté forRemoval = true dans ces annotations. En précisant « au moins une version majeure à l'avance », cela ouvre surtout une porte pour permettre à l'API Applet de survivre bien au-delà du JDK 10.
Il faut également noter que appletviewer deviendra également obsolète, avec des avertissements qui seront affichés au démarrage de l'outil.
Mise à jour le 27 / 08 / 2016 : Oracle explique que @Deprecated ne signifie pas que l’élément qui porte cette annotation sera supprimé de Java SE
Dans une proposition d’amélioration pour le JDK Oracle et l’OpenJDK (JEP 277), Oracle revient sur la signification de @Deprecated, en expliquant que cela ne signifie pas que l’élément qui porte cette annotation sera nécessairement supprimé. Une API peut porter l’annotation @Deprecated pour au moins l’une des raisons suivantes :
- l’API a un problème qui est impossible de fixer ;
- l’utilisation de l’API est susceptible de conduire à des erreurs ;
- l’API a été remplacée par une autre API ;
- l’API est obsolète ;
- l’API est expérimentale et est sujette à des changements incompatibles.
Mais comme cela est expliqué dans le JEP 277, il y a confusion au sujet du sens et de l’usage de cette annotation. « ;Un élément de programme annoté @Deprecated est un élément que les programmeurs ne sont pas encouragés à utiliser, généralement parce qu’il est dangereux, ou parce qu’une meilleure alternative existe ;». Le but est de communiquer des informations sur le cycle de vie des API en question afin d’encourager les développeurs à faire migrer leurs applications et ne plus créer de nouvelles dépendances avec ces API.
« ;L’annotation @Deprecated a finalement fini par être utilisée à plusieurs fins différentes. Très peu d’API marquées @Deprecated ont été effectivement supprimées, ce qui conduit certaines personnes à croire que rien ne sera jamais supprimé. D’autre part, d’autres gens croyaient que tout ce qui a été déprécié pourrait éventuellement être supprimé, ce qui n’a jamais été l’intention non plus. Il en est résulté un message peu clair délivré aux développeurs sur le sens de @Deprecated, et ce que les développeurs doivent faire quand ils utilisent une API dépréciée. Tout le monde était confus au sujet de ce que la dépréciation signifiait réellement, et personne ne l’a pris au sérieux. Cela a en retour rendu difficile de supprimer quoi que ce soit de Java SE. ;»
C’est la méthode forRemoval(), qui retourne un booléen, qui permettra donc de savoir si oui ou non, Oracle a l’intention de supprimer un élément annoté @Deprecated. Si la valeur est True, cela signifie que cet élément est destiné à être supprimé dans une version ultérieure. Si la valeur est False, l’élément est désapprouvé ou déprécié, mais il n’y a actuellement aucune intention de le supprimer dans une version ultérieure. La valeur par défaut de forRemoval() est False.
Source : OpenJDK (Java.net)
Et vous ?
Qu’en pensez-vous ?
Voir aussi :
Sans surprise, Oracle va repousser la date de sortie de Java EE 8, mais envisage de livrer une édition de Java SE chaque année
Oracle brise le silence et rassure au sujet de Java EE, la firme pourrait dévoiler un nouveau plan pour la plateforme à la JavaOne en septembre
Des partisans de Java EE soutenus par Red Hat et IBM décident de poursuivre leur propre développement de la plateforme, indépendamment d'Oracle