Quel avenir pour la solution de déploiement Java Web Start, venez partager votre expérience sur cette techno

La technologie Java Web Start facilite le déploiement d'applications Java de type client lourd depuis une URL. Le fonctionnement est supposé sécurisé et le gros avantage est de pouvoir déployer rapidement en accédant à chaque lancement à la dernière version de l'application.

Java Web Start a été introduit depuis Java 5 et les nouveautés sur cette technologie depuis Java 8 se font assez rares.

Nous aimerions par le biais de ce débat que vous veniez partager votre expérience sur cette technologie.

• L'utilisez-vous au sein de votre entreprise ou de vos projets personnels ?
• Avez-vous été confronté à des problèmes de comportements étranges ou êtes-vous complètement satisfaits ?
• Peut-être également que vous avez une certaine maitrise, alors n'hésitez pas à proposer des tutoriels sur cette technologie.

Merci pour vos commentaires qui feront vivre ce débat.

L'équipe Java

Avis perso : négatif. Cet avis ne concerne qu'un usage sur Internet et pas un usage exclusif sur un réseau local.

Raisons :

• Non-pérenne : régulièrement les divers maj d'Oracle concernant la sécurité viennent casser encore plus la chose au niveau de la gestion des certificats web ou changent des comportements de manière non-documentée.
• Instable : l'app se lance ou pas sans raison apparente, parfois après un long timeout, parfois jamais, parfois instantanément...
• Prompte a se casser d'elle-même :
  
  • Foirage de raccourcit sur le bureau ou le menu Démarrer. Ceux-ci perdent régulièrement leur icone, voir disparaissent sans crier gare (sans que cela soit du au nettoyage de bureau Windows). Les maj du JRE ont également tendance a détruire ou faire disparaître les raccourcis.
  • Foirage de cache : JWS bousille régulièrement de lui-même le contenu de son cache d'application (ou plutôt de ses caches, il y en a au moins 2 il me semble) en corrompant les fichiers qu'il contient. Il n'arrive alors plus a récupérer une application (il faut vider le cache et retenter l'installation).
  • Impossibilité de gérer le cache correctement : l'application n'a pas été mise a jour et le cache contient la dernière version mais non JWS va chercher a la télécharger quand même bouffant de la bande passante ou empêchant le lancement de la copie déjà présente de l'application. Inversement parfois JWS met plusieurs jours a se rendre compte qu'une application a été mise a jour sur le site web. Parfois JWS met a jour le JNLP en cache mais par les JAR, parfois c'est l'inverse............... :aie:
  • Mode offline qui ne fonctionne pas la moitié du temps. En mode offline, l'application est sensée démarrer et les vérifications de mise a jour sont sensée avoir lieu en tache de fond (si le réseau est disponible) mais non, l'application va quand même démarrer en mode en ligne et donc tenter de se connecter au web.
• Parfois avec deux PC identiques avec les mêmes configs et JVM ca fonctionne sur un mais pas sur l'autre sans qu'on en comprenne la raison (JWS est notoirement difficile a diagnostiquer).
• Les erreurs sont difficiles a tester/déboguer/tracer par le programmeur /développeur d'autant plus qu'elles ne proviennent pas forcement de problèmes réseaux (voir plus bas). Tester en local est difficile également puisque le JNLP référence son propre base code de manière absolue (ce qui rend également pénible le déplacement des fichiers sur le serveur web final si on change l'arborescence par exemple).
• L'utilisateur est souvent accueilli par des boites de dialogues et des messages d'erreurs assez abscons du style "Application requested to go online" ou "Application requested to go offline" (un comble celle-la) sans réelle précision sur ce qui bloque. J'ai avec plusieurs autres intervenant faire remonter ce problème devant l’équipe chargée du déploiement lors de la JavaOne '11 mais j'ignore si des modifications ont été apportées depuis, nous avons cesse d'utiliser JWS en 2012.
• Avoir de multiples JNLP dépendants les uns des autres (un JNLP par module) relève presque du cauchemar.

Astuce :

• Forum OTN Java Web Start & JNLP : j'y ai passé je ne sais combien de jours à voir des pauvres hères poster des problèmes similaires aux miens et qui sont eux-aussi restés sans solution la plupart du temps.
• JaNeLa : page initiale (ne fonctionne plus), fork sur GitHub. L'auteur initial, Andrew Thompson, était un résident sur le forum OTN (et probablement le plus gros posteur du forum à l’époque). JaNeLa est un outils très important vis a vis de JWS : c'est un validateur de fichiers JNLP ! En effet une partie des problèmes avec JWS est liée à Internet, un autre au serveur Web, une autre à votre propre accès réseau (proxy, sécurité, etc.), voir à votre navigateur (si JWS utilisé avec des Applets au lieu de application standalones) mais il y a également une partie non-négligeable qui provient de la structure même du fichier JNLP qui s'il est mal formaté peut amener tout un tas de problèmes plus ou moins bizarres. Et cela n'aide pas non plus que les fichiers JNLP générés par NetBeans soient généralement tronqués, pas complets ou pas bien formatés/organisés. Donc au final, je revalidais systématiquement tous mes JNLP avec JaNeLa quitte a les modifier lourdement après pour corriger tous les problèmes ou warning soulevés (ex : pré-calculer la taille des JAR/Pack.gz pour les indiquer dans le JNLP aide le process de téléchargement à donner une estimation correcte du temps restant). Valider de multiples JNLP dépendants les uns des autres (un JNLP par module) reste assez pénible cependant.
• Pack200 : compresser les JAR avec Pack200 ajoute un niveau de complexité dans les étapes de génération et de publication du logiciel et du JNLP mais le gain de taille permet de faire sensiblement descendre le besoin en bande passante pour télécharger l'application.
• A l’époque (2010-2012), avoir un certificat numérique valide au lieu d'un certificat numérique auto-généré aidait pas mal au niveau des messages de certaines boites de dialogues qui devenaient bien plus claires. MAIS certains messages d’avertissements liés aux certificats s'affichaient quand même alors qu'ils n'auraient pas du ; ce qui portait à confusion auprès de l'utilisateur. Désormais, suite aux derniers changements sur la sécurité, les certificats auto-générés ne devraient plus être supportés.

Merci Bouye pour ton retour très complet. On sent le vécu.

Mickael

Pour ma part, après avoir eu pas mal de souci avec mon application en mode applet sur mes postes client (Chrome ne veut plus d'applet, les autres navigateurs désactivent l'exécution d'applet si on n'a pas la toute dernière version de java), j'ai décidé de passer à JWS. J'ai pensé, supprimer la barrière du navigateur et ne supporter que la barrière de java.
De mon expériences, ça fonctionne correctement, sauf sur certains postes clients où l'application ne télécharge pas la nouvelle version quand il y en a une et on est obligé de forcer le vidage du cache avant de relancer. Pourtant j'ai mis les bonnes options dans le JNLP...
La documentation sur JWS est assez succincte et j'ai l'impression que pas beaucoup de mon de l'utilise.
Je pense que la prochaine étape pour moi est de ré-écrire mon application comme une application web "classique" sans java ce qui évitera pas mal de souci sur mes postes clients.

JavaWebStart était disponible en J2SE 1.4

http://www.oracle.com/technetwork/ja...ad-142935.html

Perso, je l'ai utilisé pour un projets en 2005 notamment pour embarquer une application qui commandait un scanner via TWAIN.
Depuis, je n'ai pas eu l'occasion de le réutiliser.

Pour moi, c'est l'accès périphérique d'acquisition externe qui justifiait ce genre de programme. Avec l'arrivé des téléphones portables, je fais partie de ce qui pense que c'est le navigateur/os qui doit permettre l'accès à la demande à ce genre de ressource.

Avis pas aussi négatif que Bouye, je l'utilise depuis quelques années en perso sur internet et globalement ça marche une fois que l'on a fait un JNLP réellement propre (passage par JaNeLa vivement recommandé).

Effectivement, des problèmes de temps en temps sur certains ordinateurs, réglés par une désinstallation/installation.

Le plus gros problème à mon avis est de suivre les mises à jour de sécurité, mais ça semble se calmer depuis que les certificats numériques validés par une véritable AC sont obligatoires.

Personnellement, je l'ai utilisé sur quelques projets et j'en garde un bon souvenir.

Ça date d'il y a 3/4 ans, donc je ne sais pas comment ça a évolué depuis.

On avait pas mal de soucis au départ, mais on s'est rendu compte que c'était le serveur Web qui ne renvoyait pas que les fichiers avaient été mis à jour (date de dernière modification).
Ensuite on est passé à la fonctionnalité de versions dans JNLP (JWS ne se base plus sur le timestamp de dernière modif mais sur un n° de version) et là, ça marchait beaucoup mieux.

On utilisait un plugin maven pour générer un war qui embarquait les n° de versions Maven en version JNLP. Le tout déployé dans un Tomcat et ça marchait nickel.

Bonjour,

Personnellement, je ne serai pas aussi catégorique que Bouye.

Pour pallier les insuffisances de notre ERP, j'ai mis en place une appli JWS qui permet aux membres d'un service d'attaquer notre base Oracle et de se voir présenter (à un seul endroit) une tonne d'information sur les clients, de les modifier et de les classer en fonction de leurs besoins.
Notre ERP étant déja une appli web, j'ai choisi JWS à l'époque parce qu'il avait l'avantage de cumuler l'ergonomie d'une appli client lourd (Swing/SWT) et la facilité de déploiement/centralisation d'une appli web. En plus, n'étant pas designer pour un rond, très peu pour moi de m'amuser avec les CSS s'il avait fallu faire du full web.

L'appli tourne tous les jours depuis un peu plus de 5 ans et si c'était à refaire, je n'hésiterais pas une seconde. Je n'ai jamais eu de soucis avec la JVM et quand j'ai eu des lenteurs, c'était à cause des paramètres du JNLP.

J'ai cru voir une techno équivalente sur la plate forme .NET (d'ailleurs si vous connaissez, ça m'intéresse) mais franchement j'espère que JWS survivra !
Ceci dit, on est d'accord: mon avis vaut pour un usage de type intranet. Sur le web, ça se discute.

Voili, voilou :)

Citation:

---

Envoyé par FranT

Bonjour,

Personnellement, je ne serai pas aussi catégorique que Bouye.

Pour pallier les insuffisances de notre ERP, j'ai mis en place une appli JWS qui permet aux membres d'un service d'attaquer notre base Oracle et de se voir présenter (à un seul endroit) une tonne d'information sur les clients, de les modifier et de les classer en fonction de leurs besoins.
Notre ERP étant déja une appli web, j'ai choisi JWS à l'époque parce qu'il avait l'avantage de cumuler l'ergonomie d'une appli client lourd (Swing/SWT) et la facilité de déploiement/centralisation d'une appli web. En plus, n'étant pas designer pour un rond, très peu pour moi de m'amuser avec les CSS s'il avait fallu faire du full web.

L'appli tourne tous les jours depuis un peu plus de 5 ans et si c'était à refaire, je n'hésiterais pas une seconde. Je n'ai jamais eu de soucis avec la JVM et quand j'ai eu des lenteurs, c'était à cause des paramètres du JNLP.

J'ai cru voir une techno équivalente sur la plate forme .NET (d'ailleurs si vous connaissez, ça m'intéresse) mais franchement j'espère que JWS survivra !
Ceci dit, on est d'accord: mon avis vaut pour un usage de type intranet. Sur le web, ça se discute.

Voili, voilou :)

---

Sur .NET c'est ClicOnce, cela dit je ne suis pas fan. Sinon coté Microsoft ça sera surement remplacé par le store d'entreprise dans le futur.

Citation:

---

JavaWebStart était disponible en J2SE 1.4

---

Tu as tout à fait raison. Je n'ai pas vérifié lors de l'écriture du débat. Je me suis surpris de voir qu'il existait même depuis 2001 en tant qu'outil externe.

Dans mon cas, je ne l'ai jamais vraiment utilisé en production. Sur mon blog pour montrer des exemples d'application Swing, je l'ai utilisé mais très simplement. J'apprécié également de l'utiliser sur le site de Sun pour certains tutoriels.

Le plus barbant avec JWS c'est quand tu exécutes le JNLP et que ça ne fonctionne pas. Parfois tu ne sais pas pourquoi.

Mickael

Pour ma part j'ai découvert JWS durant mes études et j'en garde plutôt un mauvais souvenir.

Les tutoriels ne sont pas nombreux à ce sujet lorsqu'on souhaite utiliser les fonctionnalités avancées (ps: je considère le tuto du site officiel assez moyen). Je dirais que comme la majorité des personnes qui cherchent à résoudre des trucs auxquels peu de gens touchent nous sommes allés du coté de mkyong et jmdoudoux.
Première présentation devant notre professeur (un grand spécialiste de Java, je préfère le préciser) : On s'est littéralement fait démonter par ce dernier parce qu'il a vu la balise suivante dans le JNLP :

Code:

---

1 2 3

<security> <all-permissions/> </security>

---

En effet il s'agit là de la solution de facilité, en gros nous avions fait en sorte que notre application puisse avoir tous les droits afin de simplifier le déploiement... mais ce n'est pas ce qu'il voulait ! Il fallait faire en sorte de signer notre .jar (encore une partie où j'ai du mal à maitriser les étapes aujourd'hui), aller modifier le fichier de policy sur le répertoire du runtime afin de restreindre un maximum de droit par rapport aux méthodes sensibles exécutées par notre application (tout ce qui est réflexion, accès réseau, accès aux fichiers sur le disque etc), bien sûr au passage nous avons appris qu'il y avait une étape différente à mettre en place au niveau du fichier manifest entre Java 6 et 7.

Autrement au travail j'ai eu l'occasion de lancer l'application Control-M via son jnlp... il y avait des conflits de version de JVM, celle de ma machine était trop récente par rapport aux autres, mais en regardant le contenu du jnlp j'ai remarqué qu'il y avait 1.5+ ou 1.6+, du coup je me dis que cela aurait du fonctionner... Bref en théorie JWS c'est bien, en pratique ça l'est beaucoup moins.

Bon ben moi, je rentre dans la catégorie "JWS" ça marche pas trop mal.
Mais il faut dire que je ne le fais tourner que sur le réseau interne des clients.

J'ai une bonne vingtaine d'applications qui fonctionnent bien et qui doivent accéder à toutes les ressources du poste :
fabrication de fichiers locaux, impressions, mails, communication avec des machines industrielles via port COM, utilisation de scanner en local, patin, couffin ...
Bref la totale.

JWS est pour moi la solution car de temps à autres, ils installent un nouveau poste et ils peuvent y mettre les applications sans problème.

Maintenant, comme Bouye, j'ai eu des "désinstallations" inexplicables sur des postes : l’icône est encore là mais quand on clique il ne se passe plus rien.
Les utilisateurs savent maintenant qu'ils doivent retourner sur le site interne pour recharger l'appli.
Mais parfois cela ne marche pas. C'est pénible car il faut aller dans le panneau de config java et désinstaller puis réinstaller complètement.

Côté apprentissage, cela a été difficile : les tutos complets sont introuvables alors il faut additionner diverses recherches.
Mes jars sont auto-signés (on est sur réseau local !). Mais j'utilise aussi des bibliothèques (pour sql server par exemple) où l'éditeur a cru bon de signer lui-même son jar.
Manque de pot, JWS n'accepte pas d'avoir une application avec des jars signés par différentes personnes.
La solution (trouvée sur dvp) a été de patouiller dans le jar pour retirer sa signature et que je signe à la place :aie:

Donc, une fois que tout est réglé, c'est une techno qui fonctionne
mais qui mériterait d'être remise à plat pour prendre en compte toutes ces petites merdouilles.

Le probleme de JWS, c'est qu'il est intimement lié au succes de java sur le poste client (desktop) qui globalement est un echec. peu d'applications java sont disponibles coté client (hors IDE, et applications metier) et on a pas l'impression que ca va s'arranger.
Swing est abandonné, le status de javaFX est pas clair (oracle semble s'en desinteresser, suffit de voir que scene builder n'est plus distribué via oracle).

a mon avis, c'est une techno morte.

Pour ma part, j'utilise JWS depuis plus de 4 ans dans une application, sans problèmes majeurs.

J'ai un peu râlé lors des durcissement progressif des options de sécurités, mais comme cette application utilise le "<all-permissions/>" (accès disques locaux, sgbd et services sockets distants) cela me semble quand même nécessaire.

Cela ne permet plus un déploiement initial accessible à un utilisateur lambda (exception de sécurité dans jcontrol et import d'un certificat auto-signé) mais comme c'est une application libre pour laquelle je ne facture pas les mises à jour mais uniquement l'installation et la formation initiale, JWS est un super outil pour un déploiement automatique des mises à jours chez les clients.

J'utilise JWS depuis plusieurs années, avec des galères et des bonheurs.

La galère c'est le manque d'expérience et de documentation qui fait que quand on a un soucis, il faut faire de nombreux essai ou de l'aide pour résoudre ce qu'on avait pas compris.

En effet même si la doc d'Oracle existe et est plutôt claire, elle ne vous permet pas de comprendre ce qui ne va pas dans le comportement de JWS (par exemple j'ai remarqué que si on place un doctype dans le XML du JNLP qui pointe sur la DTD JNLP on ne peut pas exécuter l'application offline même si on a déclaré offline allowed. L'utilisation des "properties" peut produire des bugs...). Il faut pas se rater avec le JNLP, car JWS n'est pas robuste, c'est à dire que la technologie ne prend pas en charge vos erreurs en tant qu'utilisateur.

Malgré les casses têtes reportés par Bouye (j'y ai eu droit aussi), les avantages de cette technologie sont incontestables. En entreprise, on va sur le portail Web, on clique sur le bouton installer, et ça tourne. C'est transparent pour la mise à jour.
C'est la partie bonheur.

Faire un logiciel avec un système de mise à jour automatique n'est pas triviale à cause des environnements Window et Mac OS et des systèmes de sécurité.

En conclusion je dirai que c'est une technologie qui doit être encouragée, notamment avec la mise en place d'une doc pour le trouble-shooting.

Bonjour,

Personnellement, je n'ai jamais utilisé.

Mais je voudrais savoir, si c'est une bonne solution pour déployer, surtout pour les utilisateurs.
Quand ça marche accepte t-il bien cette solution.
Peut on comparer cela à un installeur ?
Surtout il y a t-il un intérêt à l'utiliser, si on ne fait pas des mises à jour régulières de son application?
C'est bien pour déployer des clients lourds ? Car vous parler aussi d'application web.

Moi quand je fais des petites applications je donne souvent une archive avec un jar executable.

Citation:

---

Envoyé par CoderInTheDark

Moi quand je fais des petites applications je donne souvent une archive avec un jar executable.

---

C'est pour ne pas être obligé de faire cette manipulation que JWS existe.
Quand tu fais une nouvelle version (même une fois tous les 6 mois ...) alors il faut faire le tour des utilisateurs et leur installer le jar.

Alors que le principe général de JWS c'est :
1) Tu installes ton jar sur un petit site web
2) L'utilisateur clique sur le lien et ça s'installe automatiquement.
3) Quand tu mets à jour ta version, tu copies ton jar sur le site et les postes clients se mettront à jour au prochain démarrage de l'application.

donc en principe c'est cool !

dans la pratique, ce qu'on lui reproche c'est que la mise en œuvre effective nécessite une recette de cuisine longue comme le soulier de satin
avec pas mal d'embuches qui t'attendent au coin du bois (voir posts ci-dessus).

J'utilise JWS depuis plus de 2 ans maintenant et même si effectivement cette techno apporte son lots de problèmes, pour ma part je trouve que le simple avantage apporté pour le déploiement reste largement supérieur aux petits tracas que l'on peut rencontrer.

Ceci dis tous les points évoqués plus haut (la hausse de la sécurité, les problèmes de cache, le manque de docs..) restent vrai et malheureusement il faut composer avec.. Après une fois que ça marche.. ben ça marche! :mouarf:

De toute façon vu que maintenant la tendance est plus sur des applis Web, ça m'étonnerait que les choses change beaucoup à ce sujet.

Du nouveau pour Java Web Start : http://www.developpez.com/actu/95357...ava-Web-Start/

Mickael