Question

Depuis la sortie d'Adobe AIR, je me demande pourquoi Java Web Start n'a pas attiré plus d'attention dans le passé, il semble être très similaire, mais Web Start est disponible depuis beaucoup plus longtemps.

Est-ce principalement à cause d'un mauvais marketing de Sun ou existe-t-il d'autres problèmes techniques que le besoin d'installer la bonne machine virtuelle Java? Avez-vous eu de mauvaises expériences avec Web Start? Si oui lequel? Quelles sont vos recommandations lorsque vous utilisez Web Start pour distribuer des applications?

Était-ce utile?

La solution

Dans mon entreprise, nous avons utilisé Java Web Start pour déployer des applications Eclipse RCP. La configuration a été pénible, mais cela fonctionne très bien une fois en place. Donc, la seule recommandation que je puisse faire est de commencer petit, de bien comprendre. Déployer une application simple en premier. Essayer de déployer un produit complet déjà fait sans expérience de JWS se complique assez rapidement.

De plus, apprendre à passer des arguments à l’application JWS était d’une aide inestimable pour le débogage. Définition de la variable d'environnement JAVAWS_VM_ARGS permet de définir toute propriété arbitraire sur la machine virtuelle Java. Dans mon cas:

-Xdebug -Xnoagent -Xrunjdwp: transport = dt_socket, serveur = y, suspendre = y, adresse = 4144

Utile lorsque vous devez vérifier les problèmes lors du démarrage (suspend = y)

Je pense que le principal problème pour l'acceptation de Java Web Start est qu'il est relativement difficile à configurer. En outre, il existe une certaine dissonance: lorsque vous avez une application de bureau, les utilisateurs attendent d’un installateur qu’ils peuvent double-cliquer. Lorsque vous avez une application Web, les utilisateurs s'attendent à pouvoir l'utiliser directement à partir du navigateur. Java Web Start n’est ni ici ni là ...

Il est cependant très utilisé dans les intranets.

Autres conseils

Je travaille dans l’intranet d’une banque depuis 5 ans. Mon département a développé et distribué BEAUCOUP d’applications Java Web Start qui sont utilisées dans le monde entier. J’estime que Java Web Start possède le meilleur des applications de bureau ( développement facile, interface utilisateur riche, puissance de traitement sur la machine client) et les applications Internet (déploiement et mise à niveau faciles).

J'aime beaucoup Java Web Start

J’ai fait un projet une fois dans JWS et c’était pénible de courir. Pire encore, je ne traitais même pas avec tout Internet, c’était une petite application que seules quelques personnes de mon bureau allaient utiliser. Je levai les mains avec dégoût plus d'une fois, tout en configurant le serveur et en les aidant à configurer l'application sur les ordinateurs clients.

Je pense qu'AIR est de plus en plus populaire (bien que je ne sache jamais jusqu'où il ira) parce qu'il contient des applications que les gens veulent réellement utiliser (nommez votre application JWS préférée ... allez-y, j'attends), comme twhirl . Je ne suis toujours pas un grand partisan du fonctionnement d’AIR, mais c’est beaucoup mieux que JWS.

Voici une liste de mindprob :

  • Les applications Java Web Start sont très lentes à démarrer. Le moniteur charge une nouvelle JVM pour lui-même et pour chaque application. Les applications vérifient toujours sur le Web les mises à jour, le téléchargement et le traitement d'un nouveau fichier JNLP complet, plutôt que de simplement vérifier sa date. Toutefois, s'il faut environ 80 secondes pour rechercher une nouvelle version, cela signifie que vous rencontrez probablement des problèmes avec un serveur proxy. Démarrez javaws.exe et cliquez sur Modifier & # 8658; Préférences & # 8658; Paramètres réseau & # 8658; Direct. Vous ne souhaitez pas que JWS tente d'utiliser le proxy Google Accelerator. Vérifiez également dans IE, cliquez sur Outils & # 8658; Options Internet & # 8658; Connexions & # 8658; Paramètres réseau et assurez-vous que tout est conforme à vos attentes.
  • Le téléchargement des mises à jour prend à peu près autant de temps que l’application originale. Presque aucune intelligence n’a été appliquée pour rendre les mises à jour compactes.
  • Un code personnalisé s'exécutant sur le fournisseur de services Internet est nécessaire pour servir correctement les fichiers Jardiff ou pour utiliser la prochaine compression hyper pack Pack200.
  • Cela n'a pas beaucoup changé depuis sa première version. Ce peut être encore un autre produit orphelin. Cela ne mérite pas d'être. Cependant, Sun a publié une nouvelle version bêta 1.2 au bout d’un an ou presque et elle a été intégrée à JRE. Nous allons donc voir si elle reprend de la vigueur. Ils ont ignoré certains problèmes majeurs, tels que le certificat OK se cachant derrière l'écran de démarrage et nécessitant ok pour chaque pot séparément. Même s'il est orphelin, rien de grave ne se produira. Sauf si vous écrivez des applications JWS non signées et utilisez le bac à sable JWS, celles-ci fonctionneront de manière autonome.
  • Une configuration spéciale du type MIME JNLP est nécessaire, à la fois chez le fournisseur de services Internet et dans le navigateur du client. Aucune de celles-ci n'est sous le contrôle direct du développeur.
  • Si vous avez une mise à jour urgente, vous ne pouvez pas forcer son installation avant la prochaine exécution de l'application.
  • Un schéma rigide permettant d’attribuer de l’espace sur le disque dur de la machine du client possédant les propriétés suivantes est nécessaire:
    • Les noms des répertoires affectés doivent éviter les conflits de noms avec d'autres fournisseurs. Ils devraient inclure le nom du paquet principal de l'application.
    • Les noms doivent avoir un sens pour l'utilisateur final. Celles-ci devraient être quelque chose dont il puisse se souvenir, trouver et taper quand il a besoin de trouver des fichiers avec des outils de bureau.
    • Le schéma doit fournir un emplacement pour les fichiers par utilisateur et par application.
    • Un programme devrait fonctionner sur n’importe quelle plate-forme sans modification pour pouvoir retrouver ses fichiers.

Java Web Start est le bon moyen de démarrer des applications Java plus grandes, car il permet de mettre à jour et d’installer / télécharger facilement l’application et offre une meilleure interface utilisateur / UX que les applets Java.

Cependant , il existe des obstacles au lancement d'applications Java Web Start à partir d'une page Web à l'aide de navigateurs courants avec des paramètres par défaut:

  1. Impossible pour Sun / Oracle de créer une intégration de navigateur fonctionnelle. Voir http://crbug.com/10877 pour plus d'informations sur Google Chrome / Chromium. Fondamentalement, le plug-in Java ne parvient pas à implémenter les éléments NPAPI requis pour que Firefox et Chrome transmettent de manière fiable le application / x-java-jnlp-fichier de type MIME à javaws / < code> javaws.exe binaire.

  2. Impossible pour Sun / Oracle d'obtenir un type de MIME enregistré réel pour les fichiers .jnlp de Java Web Start. Le préfixe application / x - signifie techniquement brouillon ou privé.

  3. Sun / Oracle n'a pas réussi à utiliser le schéma d'URL au lieu du type MIME lorsque l'intention est que Java Web Start gère le téléchargement et le lancement de l'application. Par exemple, si au lieu d'utiliser une URL telle que https://exemple.com/app/launch.jnlp , Java Web Start a été lancé sous le nom javaws: //example.com/app/launch. Les choses .jnlp fonctionneraient beaucoup mieux. En effet, dans ce cas, le navigateur Web n'a même pas besoin de charger le fichier .jnlp , il passe simplement l'URL complète au gestionnaire de schéma (ce qui serait le javaws binaire).

Notez que la partie qui se répète (" Sun / Oracle a échoué ... ") et que vous n'avez plus besoin de vous demander pourquoi Java Web Start n'a jamais suscité autant d'intérêt. La grande partie manquante consiste à obtenir un lien de page Web pour fiablement lancer le binaire javaws avec le fichier .jnlp donné. Ce devrait être techniquement très simple (il suffit d'enregistrer un nouveau schéma d'URL lorsque le binaire javaws est installé), mais Sun / Oracle n'a pas réussi à le faire. Personnellement, je pense que tout le gâchis a été causé par le fait d'essayer de modifier le type MIME au lieu d'utiliser simplement un nouveau schéma d'URL. Et même le truc de type MIME a été très mal fait, pour avoir crié.

Si vous souhaitez toujours utiliser Java Web Start, préparez simplement une bonne documentation pour une configuration correcte du navigateur afin de remédier au désordre laissé par Sun / Oracle. L'avantage est que cela ne doit être fait qu'une seule fois et que cela fonctionnera pour tout site utilisant Java Web Start. Le problème est qu’en règle générale, le navigateur n’a jamais été configuré pour utiliser correctement les fichiers .jnlp et que vous obtenez le blâme de l’utilisation de "technologies difficiles à utiliser". parce que les utilisateurs ne veulent pas configurer leurs navigateurs uniquement pour utiliser votre application. Ai-je mentionné que c'est Sun / Oracle qui n'a pas pu configurer le navigateur automatiquement?

Mon expérience:
Je l’utilisais depuis 2006, application intranet pour une banque.

Le premier téléchargement s'est bien passé, Cependant, lorsque vous voulez sortir une nouvelle version, la mise en cache des fichiers jar ne fonctionnait pas, les nouveaux fichiers n'ont donc pas été envoyés au client.

Nous avons passé une semaine à essayer de résoudre ce problème sans succès.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top