Java : Oracle va marquer l'API Applet obsolète dans le JDK 9
Mais n'a pas l'intention de la supprimer de sitôt

Le , par Michael Guilloux

42PARTAGES

7  0 
Il est bien évident que nous sommes actuellement à la fin de l’ère des plugins même si ces technologies sont encore utiles et beaucoup utilisées. De nombreux éditeurs de navigateurs, notamment Microsoft, Google et Mozilla, ont soit supprimé le support des plugins ou annoncé un calendrier pour le faire.

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/08/2016 à 12:58
Rien de surprenant : Java ne supprime normalement jamais d'éléments de la bibliothèque standard. Elle se contente de les déprécier. Il y a des classes et méthodes dépréciées depuis toujours et qui sont toujours là.

De toute façon c'est plus du coté du support des plugins que du JDK que se décidera la vraie date de mort des Applets.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/08/2016 à 13:53
Citation Envoyé par spyserver Voir le message
De toute façon qui développe encore des applets en Java aujourd'hui ?! Personne, bon voila sujet clos.
Développer de zero une nouvelle applet, plus personne qui fait son travail sérieusement, n'oserait le faire, en effet. Mais combien de temps les applets existantes pourront être maintenues, c'est la véritable question.
4  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 26/08/2016 à 14:00
Citation Envoyé par yahiko Voir le message
Je pense que cette discussion omet un facteur décisif : les applets Java c'est juste trop moche !
Ben ça avait un peu la tête que tu lui donnais, en fait...
4  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 26/08/2016 à 9:43
Citation Envoyé par Uther Voir le message
Développer de zero une nouvelle applet, plus personne qui fait son travail sérieusement, n'oserait le faire, en effet. Mais combien de temps les applets existantes pourront être maintenues, c'est la véritable question.
Vu les bâtons dans les roues que mettent les navigateurs, l'usage des Applets est en voie de disparition, après, dire que c'est un bien ou un mal, j'ai un avis mitigé... A la base, c'était fait pour combler les lacunes HTML... et force est de constater qu'il y en a toujours
2  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 26/08/2016 à 10:25
Citation Envoyé par OButterlin Voir le message
Vu les bâtons dans les roues que mettent les navigateurs, l'usage des Applets est en voie de disparition, après, dire que c'est un bien ou un mal, j'ai un avis mitigé... A la base, c'était fait pour combler les lacunes HTML... et force est de constater qu'il y en a toujours
Ça fait longtemps que plus personne n'essaye de palier les lacunes de HTML avec des applets Java.
1  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 29/08/2016 à 14:15
Citation Envoyé par yahiko Voir le message
Je n'ai pas pris la peine de lire les pages précédentes et oui c'est vrai, car j'ai tourné la page . Maintenant faudra m'expliquer dans ce cas en quoi les applets Java sont le seul moyen dans le cadre des SmartCard et avoir la gentillesse de donner d'autres exemples si vous voulez convaincre que les applets sont indispensables.
En soit ce ne sont pas les applets qui sont réellement indispensables mais l'interaction avec les éléments de l'OS (périphérique, HDD, autres) depuis un navigateur. Il faut donc passer un plug-in du navigateur et pour cela les applets sont plutôt une solution intéressante pour ne pas avoir à coder un plug-in pour chaque couple navigateur / plateforme.

Java a de plus historiquement une bonne intégration avec certaines solutions, notamment les SmardCard.

Donc dans l'absolu ce n'est pas l'unique solution mais bien une très bonne solution. Qui de toutes façons sera remplacé par une solution aussi peu propre, donc ne changera rien sur le principe.
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 29/08/2016 à 20:58
Il y a une solution pour remplacer les applets : une appli native externe au navigateur. Si elle doit communiquer avec l'appli web, ça complique un peu les choses, mais c'est faisable (en websockets par exemple). Mais bon, ça demande quand même pas mal plus de boulot...
1  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 06/09/2016 à 10:55
Je ne pense pas qu'il soit judicieux de commencer à se lancer des accusations de troll. Mais admettons. Reprenons les faits :

1) Aucun navigateur actuel ne permet l'exécution des applets Java sans une manipulation explicite de l'utilisateur. A moins que les gens qui bossent sur ces navigateurs (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, etc) ne soient complètement incompétents, il doit bien il y avoir une raison. Il semble bien que ce soit des failles de sécurité qui en soit la principale motivation. Je ne suis pas un expert du domaine, mais le fait que justement à une époque 80% des postes avait ce plugin d'installé en faisait une cible de choix pour les malwares, sans qu'Oracle ait pu résoudre les failles de façon vraiment satisfaisante.

2) Oracle a décidé d'arrêter le support des applets Java. Conséquence, c'est pratiquement de l'histoire ancienne, que cela plaise ou non aux supporteurs de cette technologie. Il va bien falloir faire le deuil de ces applets.

3) Il existe des alternatives aux applets, que ce soit une application standalone (pourquoi pas écrite en Java pour faire du multiplateforme à moindre frais) qui du fait du caractère explicite de l'installation (contrairement à un plugin web accessible par n'importe qu'elle personne qui se rendrait par mégarde sur une page) réduit déjà la porté des menaces, ou via une technologie de transition comme Java Web Start, à mi-chemin entre l'applet Java et l'application standalone (je parle sous le contrôle des spécialistes évidemment...). Pour remplacer les applets, JWS est d'ailleurs la recommandation officielle d'Oracle sauf erreur de ma part.

Tous les plugins subissent le même sort : Flash, Silverlight et autres, c'est fini ! Les habitudes sur Internet ont beaucoup changé ainsi que les standards.

Les applets ont pu rendre des services. Elles continueront à en rendre pour les gens qui souhaitent mordicus s'y accrocher. Après tout rien ne les en empêchent. Mais c'est clairement une technologie dépréciée et pas seulement par caprices de certains, mais par un consensus général de l'industrie IT.

D'autant que je rajouterai, à moins d'y mettre beaucoup d'efforts, l'essentiel des applets Java étaient relativement moches, mais je reconnais que c'est subjectif et que vous pouvez ne pas être d'accord.
1  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 25/08/2016 à 13:26
Ça va accélérer un peu le processus...
0  0 
Avatar de Cyäegha
Membre régulier https://www.developpez.com
Le 25/08/2016 à 16:47
Citation Envoyé par esperanto Voir le message
La bonne nouvelle c'est qu'Oracle confirme qu'il y aura un Java 9 et peut-être même un 10 avant la fin du siècle (on commençait à en douter, à force)
La mauvaise, c'est que ce que cette version aura de plus c'est qu'elle aura des choses en moins (applets) alors que pour ce qui est des nouveautés, les dernières annonces datent de fin 2014 (quelqu'un ici a déjà pu essayer les nouvelles API comme JSON ou HTTP2?)

En plus, Java 9 était censé devenir modulaire, alors pourquoi ne pas déplacer cette API dans un module séparé, de sorte que celui qui l'installe le fasse en connaissance de cause?
Pour Java 9, les pré-versions du JDK 9 sont disponibles régulièrement depuis un petit moment maintenant, donc il n'y avait pas spécialement de doute à avoir sur sa sortie prochaine (après, pour ce qui est de tenir la date exacte prévue, on peut toujours avoir des surprises...). Ce n'est pas comparable à la situation de Java EE 8 par exemple. Pour les fonctionnalités inclues dedans, tu peux regarder sur cette page (le plus gros morceau étant bien sûr jigsaw).

Pour la modularisation : j'ai jeté un œil à la branche JDK9 du repo d'OpenJDK, et les classes des applets sont visiblement inclues dans le module "java.desktop", avec le reste d'AWT et de Swing. Au pire, ça veut dire que ceux qui ont seulement besoin d'AWT/Swing pour du desktop devront embarquer 5 classes inutiles... Ça ne me parait pas trop grave.

En revanche, ce qui serait vraiment utile à mon avis, ça serait de rendre optionnelle (et désactivée par défaut) l'installation du plugin Java dans les installeurs du JRE et du JDK, vu que ça ne sert plus beaucoup et que c'est le principal risque de sécurité lié à Java... Mais ça, je n'y crois pas trop.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web