Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quel avenir pour la solution de déploiement Java Web Start

Venez partager votre expérience sur cette technologie

Le 6 octobre 2015 à 22:15, par Mickael Baron

18 commentaires

73PARTAGES

Voter pour

4

Voter contre

0

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

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

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

18 commentaires

Commenter Signaler un problème

Rédacteur/Modérateur

Le 06/10/2015 à 22:38

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

Voter pour

1

Voter contre

0

Rédacteur

Le 06/10/2015 à 22:51

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

Mickael

Voter pour

0

Voter contre

0

Membre actif

Le 15/10/2015 à 10:53

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.

Voter pour

0

Voter contre

0

Membre régulier

Le 21/10/2015 à 9:39

JavaWebStart était disponible en J2SE 1.4

http://www.oracle.com/technetwork/java/javase/tech/archive-download-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.

Voter pour

0

Voter contre

0

Membre régulier

Le 21/10/2015 à 10:01

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.

Voter pour

0

Voter contre

0

Membre habitué

Le 21/10/2015 à 12:12

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.

Voter pour

0

Voter contre

0

Membre habitué

Le 21/10/2015 à 16:47

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

Voter pour

0

Voter contre

0

Membre chevronné

Le 21/10/2015 à 18:36

Citation

Envoyé par FranT

Voir le message

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.

Voter pour

0

Voter contre

0

Rédacteur

Le 21/10/2015 à 21:28

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

Voter pour

0

Voter contre

0

Modérateur

Le 22/10/2015 à 13:34

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 :

Sélectionner tout

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.

Voter pour

0

Voter contre

0

Commenter Signaler un problème