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