Alors y'a t-il des diférences ou aucune ? Personnellement j'image qu'il y en a mais les voit pas vraiment...
Avantages, inconvénients ? ..
Merci.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[Architecture] Différence entre Java Web Start et une Applet ?
Alors y'a t-il des diférences ou aucune ? Personnellement j'image qu'il y en a mais les voit pas vraiment...
Avantages, inconvénients ? ..
Merci.
La grosse différence tient dans le fait qu'avec webstart tu réalise un application swing normale alors qu'avec une applet tu as une certaine forme à respecter
A savoir également qu'une fois chargée sur ton ordi l'appli webstart peut être relancée sans avoir à acéder au net, et possède un mécanisme de mise à jour automatique
Donc la grosse différence se situerait dans le fait qu'une applet n'a pas de système de mise à jour automatique ?
Pourtant si je modifie une applet sur le serveur il me semble que les utilisateurs vont charger la nouvelle version de l'applet ?
La différence serait alors le simple fait que pour JWS on ne charge que ce qui a été mofidié ou ajouté alors que pour une applet on recharge la totalité ?
Slt,
Une applet se lance via un navigateur , en tapant une url au prealable.
Une appli JWS une fois telecharger est autonome , et peut s'executé sans connexion au net (enfin si l'appli ne le necessite pas).
En gros une JWS une fois telecharger c'est une appli desktop comme une autre, sauf qu'elle sait se mettre a jours toutes seul.
Une applet c'est une parti d'un site web, c'est finalement tres different dans le concept.
Salut,
Java Web Start a été concus pour corriger certain problèmes des Applets. A la rigeur le seul point commun c'est que les deux sont sécurisé et qu'ils neccessitent d'être signés afin d'avoir l'authorisation d'effecter certain traitement...
Au niveau des avantages de JWS :A noter enfin qu'il est possible de déployer des Applets via JWS, afin de simplifier la migration...
- Le plugin Java du navigateur n'est pas neccessaire, seul la présence d'un JRE avec JWS est requise (JWS est installé avec le JRE depuis le JRE 1.4, et installable à part pour le 1.3).
- Il est possible d'authoriser (ou non) le mode "offline" (en local).
- On peut créer un raccourci vers l'application sur le bureau ou dans les menus (selon le système).
- On peut associer des types de fichiers avec l'application JWS.
- On peut spécifier la(les) version(s) de Java à utiliser, et eventuellement fournir du codes différents selon la version.
- Utiliser un ensemble de "BasicServices", qui permettent d'effectuer des actions normalement interdite (ouvrir/sauvegarder/télécharger/imprimer), sans pour autant avoir à signer son application (avec certaine limitation toutefois, voir le package javaws.jnlp pour plus de détail).
- Spécifier des options d'exécution, en particulier le memory head size (min et max).
- Enfin le navigateur n'est plus qu'un outil et non pas une neccessité : on peut très bien déployer et exécuter l'application sans navigateur : seul l'URL suffit...
a++
Merci beaucoup pour vos réponses, et particulièrement à adiGuba pour sa réponse + que précise
Bonjour, le sujet m'interresse beaucoup, aussi j'aimerais quelque précisions:
A-t-on accès aux .class d'une appli JWS ?
JWS permet de lancer une appli à partir du web, mais une fois sur le desktop, qu'a-t-on comme données en local et où ?
Par exemple si l'appli JWS utilise un fichier de config xml, suis-je capable de retrouver ce fichier en local une fois l'appli téléchargée ?
Puis-je développer une appli JWS qui utilise des fichiers situés sur le serveur ?
Oui. Le fichier .jnlp se situe dans Document and Setting\Administrateur.NOMDETASESSION\Application DATA\SUN\JAVA\DEPLOYMENT\CACHE\JAVAWS\HTTP\etc...\Envoyé par Regis.C
A noter que si le fichier jnlp est généré à la volée d'extension .php (par exemple), dans le cache on ne trouvera uniquement le .jnlp "static". Ce qui est d'ailleurs logique.
Oui. Tu peux utiliser des fichiers venant du serveur, ou de ton jar (lui même situé sur le serveur)
Reste cette question...
Les .class sont ils stockés en mémoire ?
Le jar est en local puisque tu peux utiliser le programme hors ligne. En décompressant le .jar avec winrar tu trouvera les .class et même les .java si le programmeur les a inclus.
Le jar se situe lui aussi dans le cache (voir le chemin dans ma réponse au dessus)
Bonsoir,
Est-ce qu'une application JWS s'exécute dans une page html ? Si je veux l'utiliser à l'intérieur d'une page web comme une applet, est-ce que c'est possible ?
Une application JWS c'est juste une application Java déployée via Java Web Start.
Donc non elle ne s'insère pas dans une page HTML !
Fait une applet dans ce cas !
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Le jar est aussi local dans le cas d'une applet, non ? par ailleurs, mettre les .java dans le .jar qu'on fournit, on ne le fait que si on veut que les sources soient accessibles.Le jar est en local puisque tu peux utiliser le programme hors ligne. En décompressant le .jar avec winrar tu trouvera les .class et même les .java si le programmeur les a inclus.
En principe, dans le déploiement, on "obfusque" les class, et on ne joint pas les sources ni les infos de débuggage...
Ca va être pratique pour assurer le support de ton application
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Mmmh, oui pourquoi ?Ca va être pratique pour assurer le support de ton application
Ok merci et +1.
*****************
L'applet n'a-t-elle pas plus de possibilité qu'une application JWS ? Par exemple si on a besoin de communiquer avec le serveur pour diverses raisons ? (Supposons que je veuille afficher des textes (cours, définitions...) en fonction des paramètres entrés par l'utilisateur).
Bah t'es stacktrace vont être moisi :
java.lang.IllegalArgumentException: id
at a.a.a.A.a(Unknown source)
at a.a.a.A.b(Unknown source)
at a.a.a.A.c(Unknown source)
at a.a.a.A.d(Unknown source)
at a.a.a.B.a(Unknown source)
at a.a.a.B.b(Unknown source)
at a.a.a.B.c(Unknown source)
at a.a.a.B.d(Unknown source)Une Applet peut interagir avec la page qui l'intègre puisqu'elle est exécuté à travers un plugin du navigateur. Ce que tu ne peux faire quand tu es dans une application à part entière.
Parce qu'une application Java ne peut pas communiquer avec un serveur ?
Il suffit de faire un formulaire qui pointe vers une "page dynamique" qui va générer un JNLP customisé à partir des saisies de l'utilisateur.
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Salut,
Juste pour info : il est tout à fait possible de déployer une applet via JNLP : http://www.oracle.com/technetwork/ja...707.html#USAGE
a++
Bah tes stacktrace vont être moisis
Il y a toujours un conflit stratégique entre deux buts non corrélés, en l'occurrence :
A) Pouvoir facilement régler un problème imprévu
B) Augmenter le coût d'un désassemblage du code
Toute stratégie de déploiement est un compromis entre ces deux buts.
Soit on privilégie la protection des sources (B), et du coup forcément il y a moins d'indices côté client pour A, soit on privilégie le debuggage style "programme en cours de développement", et on diminue le coût du désassemblage.
On peut aussi faire un log... Et en plus on peut toujours aussi renvoyer une version "debug" du .jar à un utilisateur déterminé, le jour où il a des soucis sérieux...
En tout cas, un programme avec les sources et les informations de debuggage, amha ça ne peut pas être autre chose qu'une version de test, quelque chose de très provisoire, voire limité à mon ordi, mais en aucun cas "dans la nature".
Là, pour le coup, je ne vois pas le but ?Juste pour info : il est tout à fait possible de déployer une applet via JNLP
Est-ce qu'il s'agit réellement de Java Web Start ou juste la réutilisation du format JNLP comme descripteur de déploiement ?
En tout cas dans la FAQ c'est indiqué qu'on peut lancer une Applet avec JWS mais ca s'ouvre dans l'AppletViewer qui ne couvre pas toute la spécification des conteneur d'Applet.
Si tu fournies une application dont le code est relativement "critique", l'obfuscation peut-être à envisager mais cela ne fera que limiter (ou augmenter le cout) du désassemblage. Si quelqu'un estime que c'est économiquement valable il mettra les moyens qu'il faut et tu n'auras que fait perdre un peu de temps à une équipe d'ingénieur voir à un programme.Il y a toujours un conflit stratégique entre deux buts non corrélés, en l'occurrence :
A) Pouvoir facilement régler un problème imprévu
B) Augmenter le coût d'un désassemblage du code
Toute stratégie de déploiement est un compromis entre ces deux buts.
Soit on privilégie la protection des sources (B), et du coup forcément il y a moins d'indices côté client pour A, soit on privilégie le debuggage style "programme en cours de développement", et on diminue le coût du désassemblage.
On peut aussi faire un log... Et en plus on peut toujours aussi renvoyer une version "debug" du .jar à un utilisateur déterminé, le jour où il a des soucis sérieux...
En tout cas, un programme avec les sources et les informations de debuggage, amha ça ne peut pas être autre chose qu'une version de test, quelque chose de très provisoire, voire limité à mon ordi, mais en aucun cas "dans la nature".
Là, pour le coup, je ne vois pas le but ?
Car il existe des programmes qui en analysant la structure d'un code, le réécrit proprement ; certes sans les commentaires et les bons noms mais ce n'est pas le plus long.
Dans une bonne application les "logs techniques" (appelées "traces") sont stockés dans un fichier bien particulier. A la demande tu peux récupérer les logs et les traces (ex : Fonction d'envoi de rapport de bugs).
Quand tu assures le support sur une application, tu as intérêt à avoir des informations précises afin d'être réactif. Sinon tu ne garderas pas longtemps ta clientèle.
La robustesse (aussi bien la capacité à "résister" aux erreurs et à fournir des informations claires en cas d'erreur ou non) est un point critique pour une application distribuée au grand public !
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Répondre avec citation
Partager