Ça va accélérer un peu le processus...
Version imprimable
Ça va accélérer un peu le processus...
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.Citation:
Envoyé par spyserver
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).Citation:
Envoyé par esperanto
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.
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 ;)Citation:
Envoyé par Uther
Ça fait longtemps que plus personne n'essaye de palier les lacunes de HTML avec des applets Java.Citation:
Envoyé par OButterlin
Parle pour toi, nous, on a encore des besoins qui serait nettement simplifiés par l'usage d'une applet...Citation:
Envoyé par Traroth2
et d'autres besoins ne concernant pas html qu'on ne pourrait couvrir QUE par une applet...
Je pense que cette discussion omet un facteur décisif : les applets Java c'est juste trop moche ! :mouarf:
Et toi je pense que tu oublies une chose décisive : les applets n'ont pas forcément besoin d'avoir une interface graphique ;)Citation:
Envoyé par yahiko
On peut par exemple s'en servir pour lancer des commandes sur le poste client... j'dis ça, j'dis rien... :mouarf:
Je parlais des applets Java qui apparaissent (ou apparaissaient ^^) sur une page Web évidemment.
Et reconnais toi-même que ce n'était pas des plus esthétiques :p
Ben ça avait un peu la tête que tu lui donnais, en fait...Citation:
Envoyé par yahiko
Complètement d'accordCitation:
Envoyé par Traroth2
Si tu regardes ce que propose Quaqua (pour n'en citer qu'un), c'est plutôt pas mal, en tout cas, ça te donne une idée de ce qu'il est possible de faire...
Nan mais je comprends que tu aimes les applets Java, mais faut se faire une raison c'est fini, faut tourner la page ^^
N'importe quoi... :D Je te rassure, je me passerais bien des applets...Citation:
Envoyé par yahiko
Bon, on ne va pas non plus tourner en rond avec nos avis divergents sur la question, on acte que tu n'aimes pas et que j'estime que dans certains cas, c'est encore nécessaire, ne t'en déplaise...
Oui, nécessaire pour legacy reasons, pas nécessaire comme c'est la seule solution ;)
Faudrait au moins lire les derniers messages avant de s'avancer avec tant d'assurance ...Citation:
Envoyé par yahiko
Le problème des SmartCard a été évoqué seulement sur la page précédente. Ensuite je ne serais pas assez présomptueux pour dire que c'est la seule problématique.
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 8-). 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.
Bah l'explication est pas bien compliquée : il n'y a pas d'API Web qui permette d'utiliser un lecteur de smartcards. Donc il faut passer par un plugin Java. Et globalement, tout ce qui nécessite de piloter du matériel non géré par le W3C nécessitera des plugins.
Si tu dis que c'est une mauvaise idée de vouloir faire ça, je suis entièrement d'accord. Il n’empêche que c'est quelque-chose qui peut être exigé par ton client.
Explication pas compliquée, mais compliquée à obtenir. ;)
Mais bon, cette solution ouvre la porte à pas mal de problèmes de sécurité qui sont justement la cause de l'abandon des applets...
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.Citation:
Envoyé par yahiko
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.
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...
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é.
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 ;)
Je vois en tout cas qu'on progresse et qu'il n'y a plus de caractère technique indispensable de l'applet ;)
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.Citation:
Envoyé par yahiko
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.
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.Citation:
Envoyé par yahiko
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 :aie:. 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".
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.
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 ?
:fleche: Regrettez-vous les applets Java ? Quelles technologies de remplacement utilisez-vous étant donné que Java Web Start a également été déprécié ?
:fleche: Pourquoi ? Partagez votre expérience
Voir aussi :
:fleche: Oracle envisage de passer à un Web sans plugin et recommande de migrer des applets Java vers la technologie Java Web Start
:fleche: 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
:fleche: 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
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...:mouarf:Citation:
Envoyé par yahiko
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".
jpackage sera standard (fin de l'incubation) avec le JDK 16 qui sort ce mois-ci.
En remplacement de javapackager ?Citation:
Envoyé par 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...
