Java Web Start - Popularité

Question

J'ai récemment utilisé une application Java Web Start. Je l'ai lancé de mon navigateur Web en utilisant un lien jnlp intégré dans la page que je regardais. L'application a été téléchargé, lancé et fonctionnait très bien. Il avait accès à mon système de fichiers local et rappeler mes préférences entre le redémarrer.

Ce que je veux savoir est pourquoi les applications Java Web Start pas un format de livraison plus populaire pour les applications complexes sur le web? Pourquoi les développeurs passent souvent beaucoup de temps et la fonctionnalité de bureau répliquant l'énergie en html / javascript lorsque la puissance d'une application de bureau pourrait être livré plus facilement en utilisant Java et Java Web Start?

Je sais que dans certains environnements d'entreprise, par exemple les banques, ce sont des moyens relativement populaires de fournir des applications commerciales complexes aux clients, mais pourquoi sont-ils pas omniprésent sur le Web dans son ensemble?

(Par souci de discussion, supposons un monde où: sources de téléchargement sont des applications et « de confiance » sont « signés » (pas de problèmes de sécurité), des vitesses de téléchargement sont rapides (temps de chargement est rapide) et les développeurs savent Java (en les chiffres qu'ils connaissent html / js / php)).

Answer 1

Je pense que la raison est pas le temps de sécurité, ni le démarrage de l'application. Comprenons bien ce qui se cache derrière la scène avant de trouver la cause racine.

Panneau de configuration Java a des paramètres qui permettent aux utilisateurs d'utiliser les paramètres de proxy du navigateur par défaut ou de les remplacer. En d'autres termes, les équipes d'infrastructure sont en mesure de personnaliser les images d'installation Windows ou OS d'avoir JVM pré-installé avec les paramètres de proxy d'entreprise. Je crois donc que ce n'est pas un problème du tout.

Java Web Start met en cache réellement toutes les applications avec des paramètres personnalisables dans le Panneau de configuration Java. Une fois que l'application est mise en mémoire cache, l'application est « installé » comme d'autres applications. Bien que la première exécution de temps peut être lente, la deuxième fois sera rapide en raison de la technique intelligente d'allocation de mémoire de JVM. Donc, le temps de démarrage pourrait être un problème, mais beaucoup de sites web (même entreprise interne) sont désormais migré vers le portail. Un portail Web contient normalement beaucoup de bibliothèques non utilisées à des fins de développement en raison du fait que le portail lui-même ne prévoit pas ce genre de portlets sont construites et déployées sur une page spécifique. Par conséquent, le téléchargement d'une seule page de portail pourrait consommer jusqu'à mbs et compléter une page dans plus de 5 secondes; ce n'est une page et la mise en cache aide jusqu'à 30%, mais il y a encore beaucoup de composants HTML / Javascript / CSS nécessaires pour télécharger à chaque fois. Avec cela, je suis sûr que Java Web Start est un avantage ici.

Java Web Start ne télécharge pas encore si elle est mise en mémoire cache tant que la copie du serveur est non mis à jour. Par conséquent, si, par exemple un logiciel de gestion de projet comme MS Project, est complété en utilisant SmartClient (similaire à JWS), l'échange d'informations entre le client et le serveur serait purement données sans présentation comme rafraîchir la page complète du navigateur. Même avec l'aide d'Ajax, il ne supprime pas le téléchargement de pleine page entièrement. En outre, beaucoup d'entreprises considèrent Ajax être immature et sans garantie encore. Voilà pourquoi Ajax est un sujet brûlant dans les cercles de développeurs, mais pas dans encore un logiciel d'entreprise. Dans cet esprit, JWS applications ont certainement plus d'avantages tels que la façon dont les applications JWS sont déployées et exécutées dans des sandbox, signé, et avoir une interface graphique beaucoup plus interactif.

D'autres avantages comprennent le développement plus rapide (plus facile à déboguer dans le code et les performances), l'interface utilisateur réactive (ne nécessite pas des serveurs Comet pour fournir des fonctionnalités PUSH), et l'exécution plus rapide (pour sûr parce que les ordinateurs clients rend l'interface graphique sans traduction comme HTML / Javascript / CSS, et moins le traitement des données).

Après tout cela, je n'ai pas touché la question encore, pourquoi JWS est pas si célèbre?

Mon opinion est qu'il est le même que le commentaire de Brian Knoblauch, il est sans conscience.

les gens IT sont trop attirés par le battage médiatique des technologies Web, Ajax PUSH, GWT, et tous ces mots à la mode en font parti pris vers le plaisir d'utiliser différentes technologies ou pour résoudre les problèmes techniques au lieu de ce qui fonctionne vraiment pour les clients.

Jetez un oeil à Citrix. Je pense que Citrix est en fait une excellente idée. Citrix vous permet de créer vos propres fermes app derrière la scène. Il y a des tonnes de stratégies de mise à niveau et la mise en œuvre, vous pouvez aller sans impact sur l'expérience client. le déploiement Citrix est extrêmement facile, stable et sûr. Les entreprises utilisent encore. Cependant, je pense que JWS est encore mieux que Citrix. L'idée de JWS est d'exécuter des applications sur les machines clientes au lieu de tonnes d'hébergement des fermes de serveurs où les machines clientes sont capables d'exécuter ces applications elles-mêmes. Cela permet d'économiser une entreprise beaucoup d'argent !!! Avec JWS, l'équipe de développement peut encore construire la logique métier et les données sur le côté serveur. Cependant, sans l'unité de traitement web et laissez les ordinateurs clients font le processus de rendu, il réduit considérablement la quantité de consommation de réseau et de la puissance de traitement du serveur.

Un autre exemple des raisons pour lesquelles JWS est une idée étonnante est Blackberry MDS. applications Blackberry sont en fait les applications Java translated de Javascript. Avec le studio MDS BB, vous utilisez l'outil GUI pour construire GUI BB application, le codage logique GUI en Javascript. Ensuite, les applications sont ensuite traduites et déployées sur un serveur BES. Ensuite, le serveur BES distribuera ces applications à BB. Sur chaque BB, il exécute une mince Java App avec une interface graphique de rendu et la mise en réseau que la capacité. Chaque fois que l'application requiert des données, il communique avec le BES grâce à des services Web à utiliser les services d'autres serveurs. Ne serait-ce que la version JWS BB? Il a été un grand succès.

Enfin, je pense que JWS n'est pas populaire en raison de la façon dont Sun fait la publicité. BB annonce ne la qualité de leurs applications Java BB sont, ils croient que les clients vont même se soucient pas ce qu'il est. BB annonce les avantages de l'utilisation MDS pour développer des applications. Rapide, économie de coûts, d'affaires retour

Juste mes, un peu long, 2 cents ...:)

Answer 2

Un obstacle majeur pour Java Webstart est probablement que vous devez toujours avoir une machine virtuelle Java installée avant même de tenter de télécharger et démarrer votre application. Tout le monde a un navigateur. Pas tout le monde a une machine virtuelle Java.

Edit: Je l'ai depuis quelques acquis une expérience pratique webstart et peut maintenant ajouter ces deux points:

• Script de déploiement Toolkit et la machine virtuelle Java a publié quelque part modularisé autour de Java 1.6u10 faire l'exigence JVM moins problématique car il peut télécharger automatiquement une machine virtuelle Java et le noyau de l'API et démarrer le téléchargement du programme Wile le reste.
• Web Start est sérieusement buggy. Même parmi les Java 1.6 versions il y avait un qui a téléchargé l'ensemble de l'application à chaque fois, et un autre qui a téléchargé, puis a échoué avec un message d'erreur obscure. Dans l'ensemble, je ne peux pas recommander vraiment compter sur un tel système fragile.

Answer 3

Je pense qu'il est la plupart du temps en raison d'un manque de sensibilisation. Il fonctionne très bien. Tout à fait transparente. App ne télécharge si elle est la première fois, il y a eu une mise à niveau, ou si l'utilisateur final a effacé le cache. Un excellent moyen de déployer bureau complet apps que l'utilisateur ne sera pas à vous soucier de la mise à niveau manuelle!

Answer 4

Le problème avec Webstart est que vous avez réellement à «commencer quelque chose qui est pas du tout aussi vite, même avec une connexion rapide, alors qu'avec une webapp vous entrez l'URL et l'application est là.

Aussi beaucoup de choses peuvent aller mal avec webstart. Peut-être que l'utilisateur prévu n'a pas les privilèges nécessaires, ou le proxy de webstart est mal configuré, ou quelque chose a mal tourné avec les dépendances ou jre il n'y a tout simplement pas java installé en premier lieu. Donc, pour la moyenne john doe dans l'Internet, il est pas du tout agréable.

Dans un environnement contrôlé comme une entreprise, il est une bonne solution et facile dans de nombreux cas.

Answer 5

Je travaille sur une application déployée JWS depuis quelques années sur une base d'utilisateurs de quelques milliers et ses mises à jour automatiques sont en fait une douleur énorme.

Sur chaque mise à jour pour quelques dizaines raison d'utilisateurs se « coincé au milieu ». Tout ce que vous obtenez est l'exception « classe not found » (si vous êtes chanceux) ou uninformative « incapable de lancer » de JWS avant qu'il ne soit même à votre code. On dirait que la mise à jour est téléchargée à moitié. Ou, en d'autres termes, il n'a pas télécharger et appliquer la mise à jour atomiquement et a une mauvaise mise en cache de sorte que relançant l'application de la même URL ne résout rien.

Il n'y a aucun moyen de le résoudre autre que la compensation cache JWS ou de fournir une URL différente (par exemple append ?dummyparam=jwssucks à la fin). Même en tant que développeur, je frappe parfois et ne vois pas autour.

Quand cela fonctionne, cela fonctionne. Mais trop souvent, il ne fonctionne pas et il est une douleur énorme pour vous et votre service d'assistance. Je ne le recommanderais pas pour l'entreprise ou d'une mission critique utilisation.

Answer 6

Il y a un très gros problème à savoir qu'il ne permet pas de déploiements « démarrer le programme instantanément et puis vérifier et télécharger les mises à jour en arrière-plan », qui est ce que le comportement des applications sont defacto à convergeant.

Je considère personnellement si grand désagrément que nous recherchons activement une autre technologie qui prévoit que.

Answer 7

De ces postes, il ressemble en utilisant Web Start, il est important de faire un bon soin sur le serveur. La « douleur énorme » de télécharger l'application sur chaque démarrage peut être causée par horodatage incorrect délivré à partir du serveur. Ici pas l'application mais le serveur doit être configuré pour utiliser correctement la mise en cache et pas seulement pour le désactiver. A propos de départ poussette, je ne suis pas bien sûr, mais il me semble que cela peut aussi être causée par une connexion peu fiable.

Avantage important du démarrage du Web est que cela fonctionne bien avec OpenJDK sous Linux. Les clients de certains développeurs heureux utilisent Windows uniquement, mais mes clients ne le font pas.

HTML et JavaScript, mentionné dans la question initiale, sont des approches plus légères qui fonctionnent bien avec de petites tâches comme des boutons animés ou même des tables interactives. Java niche semble des tâches autour de beaucoup plus complexes.

Answer 8

Java Web Start est en quelque sorte un successeur de Java Applets, et applets a été brûlée autour du nouveau millénaire. Mais, je pense toujours Applets Java sont bien mieux que l'enfer GWT ou Javascript.

Java Web Start vs intégré Java Applet