Discussion :

[Logan Mauzaize]

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.

[tomlev]

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...

[yahiko]

Dans le cas d'un accès au matériel, passer par une application externe au navigateur est plutôt ce qui est recommandé il me semble d'un point de vue de la sécurité.

[OButterlin]

L'intégration d'une application autonome avec une application web est loin d'être naturelle, et de mon point de vue, ne règle pas plus le problème de sécurité...
Si c'est une application java type swing, il faut que le poste cible ait un jre d'installé... et de l'autre côté, le navigateur doit avoir un plugin pour faire tourner l'applet... bref, rien de top dans tous les cas.
Le problème vient plutôt de ce que va imposer le client

[yahiko]

Je vois en tout cas qu'on progresse et qu'il n'y a plus de caractère technique indispensable de l'applet

[tomlev]

Dans le cas d'un accès au matériel, passer par une application externe au navigateur est plutôt ce qui est recommandé il me semble d'un point de vue de la sécurité.

Oui mais en fait la sécurité de ce genre de solution, c'est pas gagné... en fait, les mesures de sécurité des navigateurs obligent à faire des trucs pas secure du tout pour que ça puisse marcher, comme je l'avais expliqué ici.

[_skip]

De plus, à compter du moment où il faut installer ou lancer une application tierce sur le poste client, la sécurité devient strictement une affaire de confiance. En ce sens, on peut tout autant se demander en quoi une applet était tellement moins sécurisée que ça, en gros tu la trustes ou pas. Les ransomwares sont à la mode, et ils ne demandent pas forcément de très grands privilèges pour faire du dégât.

Je vois en tout cas qu'on progresse et qu'il n'y a plus de caractère technique indispensable de l'applet

La vraie différence c'est que dans le cas des applets, jusqu'à il y a quelques années, c'était une technologie qui permettait de faire tourner une application sur un poste client en se servant d'un plug-in qui avait genre +80% de chance d'être présent et dispo. Donc en gros faire des opérations qui n'étaient pas immédiatement possibles en JS avec une gêne minimale tant côté développeur que côté utilisateur.
Techniquement, c'est clair que tu peux t'y prendre autrement, genre obliger le client à déployer une application avec les contraintes que ça a (support multi-plateforme) ou pourquoi pas livrer ton propre navigateur, ou ton OS . mais c'est plus de contraintes à bien des égards et le gain de sécurité, comme expliqué en début de post, est fonction de la décision de l'utilisateur de te faire confiance ou non.

Enfin je dis ça pour le cas où tu es réellement intéressé par la discussion et non par le troll bas de gamme avec des "ololol cé tro moche".

[yahiko]

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.

[Michael Guilloux]

Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java
Y a-t-il des raisons de regretter les applets Java ?

L'avènement de HTML5 a donné naissance à un mouvement d'ensemble vers une plateforme Web sans plug-in. Fin 2015, les éditeurs de navigateurs avaient déjà commencé à mettre fin au support des standards basés sur les plug-ins ; éliminant ainsi la possibilité d’y intégrer Flash, Silverlight, les applets Java, entre autres. Cette tendance a également poussé les entreprises derrière ces technologies à les mettre aux oubliettes ou à envisager de le faire.

Dans la foulée, Oracle a marqué l'API Applet obsolète dans Java 9. Toutefois, ce n'est que maintenant qu'elle sera définitivement supprimée du JDK.

L'API Applet « n'est presque plus utile puisque tous les fournisseurs de navigateurs Web ont soit supprimé la prise en charge des plug-ins de navigateur Java, soit annoncé leur intention de le faire », peut-on lire dans le JEP 398 mis à jour samedi 6 mars.

En annonçant l'obsolescence de l'API Applet en 2016, Oracle avait demandé aux développeurs d’applications qui reposent sur le plug-in Java de navigateur d'envisager d’autres options telles que la migration des applets Java (qui reposent sur un plug-in de navigateur) à Java Web Start, qui ne dépend d'aucun plug-in.

Java Web Start est une technologie de déploiement d’applications qui vous permet de lancer des applications complètes en un seul clic à partir de votre navigateur Web. Parmi les avantages attribués à cette technologie, on peut noter que contrairement aux applets Java, les applications Java Web Start ne s'exécutent pas à l’intérieur du navigateur. Java Web Start garantit aussi l'exécution de la version la plus récente de l'application et ne fait pas appel à des procédures d'installation ou de mise à niveau compliquées : la mise à jour est transparente. Java Web Start était encore recommandée si la performance est d’un enjeu crucial.

Face à ces avantages qu’offre Java Web Start, il faut encore noter que les applets Java ne tenaient plus leurs promesses de sécurité. Mais la technologie Java Web Start a elle-même été abandonnée par la suite. Oracle a en effet annoncé en mars 2018 qu'il n'allait pas l'inclure dans Java SE 11 et les versions ultérieures du JDK, obligeant les développeurs à explorer d'autres technologies de déploiement.

Et vous ?

Regrettez-vous les applets Java ? Quelles technologies de remplacement utilisez-vous étant donné que Java Web Start a également été déprécié ?
Pourquoi ? Partagez votre expérience

Voir aussi :

Oracle envisage de passer à un Web sans plugin et recommande de migrer des applets Java vers la technologie Java Web Start
Safari 10 vers une expérience sans plugin sous macOS Sierra : Flash, Silverlight et autres plugins désactivés par défaut, et la priorité à HTML5
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

[yahiko]

La politique d'Oracle envers Java est tout à fait cohérente.

• Abandon des Applets Java : Fait.
• Abandon de Java Web Start : Fait.
• Abandon de Java : En cours.

[TotoParis]

La politique d'Oracle envers Java est tout à fait cohérente.

• Abandon des Applets Java : Fait.
• Abandon de Java Web Start : Fait.
• Abandon de Java : En cours.

Comme si Java se résumait aux Applets et à Web Start...

[pk960]

Bonjour,

Si cette JEP 398 est retenue pour Java 17, c'est au plus tôt dans Java 18 que l'API Applet sera effectivement supprimée.
Ça laisse donc encore au moins un an pour l'éliminer du code que l'on souhaite compiler avec "-release 18".

Il est vrai que Java n'est plus trop à la pointe côté client mais l'arrivée de jpackage en tant que fonctionnalité standard dans Java 16 (et non 17) est une bonne chose.
Cela donne à nouveau un moyen de déployer du code Java sur un poste client.
Par rapport aux applets, cela ajoute une étape de packaging par plateforme avant le déploiement mais on a toujours le "write once" et le "run everywhere".

[bouye]

jpackage sera standard (fin de l'incubation) avec le JDK 16 qui sort ce mois-ci.

[lvr]

jpackage sera standard (fin de l'incubation) avec le JDK 16 qui sort ce mois-ci.

En remplacement de javapackager ?

[bouye]

Oui c'était le but avoué du projet jpackage (JEP 343) car a partir du moment où javapackager a été retiré du JDK (le JDK 13*), ce sont toutes les applications desktop Java (pas juste JavaFX) qui se sont un peu retrouvées dans la mouise (à part en utilisant des soft tiers qui peuvent ou pas supporter correctement telle ou telle plateforme ou telle ou telle release).

jpackage fonctionne de manière similaire (mais pas totalement identique) à javapackager .

*GG well played Oracle...