Discussion :

[ionix]

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.

[sinok]

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

[ionix]

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é ?

[FreshVic]

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.

[adiGuba]

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 :

• 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 noter enfin qu'il est possible de déployer des Applets via JWS, afin de simplifier la migration...

a++

[ionix]

Merci beaucoup pour vos réponses, et particulièrement à adiGuba pour sa réponse + que précise

[Regis.C]

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 ?

[ionix]

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

Oui. Le fichier .jnlp se situe dans Document and Setting\Administrateur.NOMDETASESSION\Application DATA\SUN\JAVA\DEPLOYMENT\CACHE\JAVAWS\HTTP\etc...\

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.

Puis-je développer une appli JWS qui utilise des fichiers situés sur le serveur ?

Oui. Tu peux utiliser des fichiers venant du serveur, ou de ton jar (lui même situé sur le serveur)

[Regis.C]

Bonjour, le sujet m'interresse beaucoup, aussi j'aimerais quelque précisions:

A-t-on accès aux .class d'une appli JWS exécutée en local ?

Reste cette question...
Les .class sont ils stockés en mémoire ?

[ionix]

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)

[Beginner.]

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 ?

[Logan Mauzaize]

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 !

[JoeChip]

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

En principe, dans le déploiement, on "obfusque" les class, et on ne joint pas les sources ni les infos de débuggage...

[Logan Mauzaize]

Ca va être pratique pour assurer le support de ton application

[JoeChip]

Ca va être pratique pour assurer le support de ton application

Mmmh, oui pourquoi ?

[Beginner.]

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 !

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

[Logan Mauzaize]

Mmmh, oui pourquoi ?

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)

L'applet n'a-t-elle pas plus de possibilité qu'une application JWS ?

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.

Par exemple si on a besoin de communiquer avec le serveur pour diverses raisons ?

Parce qu'une application Java ne peut pas communiquer avec un serveur ?

Supposons que je veuille afficher des textes (cours, définitions...) en fonction des paramètres entrés par l'utilisateur.

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.

[adiGuba]

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

[JoeChip]

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

Juste pour info : il est tout à fait possible de déployer une applet via JNLP

Là, pour le coup, je ne vois pas le but ?

[Logan Mauzaize]

Juste pour info : il est tout à fait possible de déployer une applet via JNLP : http://www.oracle.com/technetwork/ja...707.html#USAGE

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.

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 ?

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