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.
Version imprimable
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...\Citation:
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)Citation:
Envoyé par Regis.C
Reste cette question...Citation:
Envoyé par Regis.C
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 !
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.Citation:
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 :lol:
Mmmh, oui pourquoi ?Citation:
Ca va être pratique pour assurer le support de ton application
Ok merci et +1.Citation:
Envoyé par Nemek
*****************
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 :Citation:
Envoyé par BenWillard
Citation:
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.Citation:
Envoyé par Beginner.
Parce qu'une application Java ne peut pas communiquer avec un serveur ? :roll:Citation:
Envoyé par Beginner.
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.Citation:
Envoyé par Beginner.
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++
Citation:
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 ? :koi:Citation:
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 ?Citation:
Envoyé par adiGuba
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.Citation:
Envoyé par BenWillard
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 !
Encore merci et +1...
Ben en fait je m'interrogeais...Citation:
Envoyé par Nemek
Ah je ne sais pas ce qu'est un JNLP, en fait je n'y connait pas grand chose... J'ai d'ailleurs ouvert une discussion pour savoir s'il fallait un hébergeur/serveur particulier pour exécuter une applet Java... Je pense que non mais j'en suis pas sûr et de toute façon je me demande si il y a quelque chose à faire au niveau du serveur pour pouvoir utiliser les applets Java...Citation:
Envoyé par Nemek
Tu devrais lire la doc
Justement, l'idée, c'est de rendre le désassemblage plus cher que la réécriture.Citation:
Si quelqu'un estime que c'est économiquement valable
Citation:
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).
[...]
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 !
Justement, si mon appli fait de bons logs, pas besoin des infos symboliques des sources ; en plus rien n'empêche de chiffrer le log. Inutile de laisser des choses en clair qui ne vont m'aider que marginalement, mais baisseront beaucoup le coût du désassemblage. Une appli bien faite gère toutes les erreurs silencieusement... J'ai tout de même rarement (jamais ?) un e.printStackTrace() dans mes sources "définitives"...
Quelle doc ?Citation:
Envoyé par BenWillard
http://download.oracle.com/javase/6/.../contents.html , entre autres
Obfusquer ou pas, ton code il fonctionne alors pourquoi le réécrire ? Il faut donc qu'avoir l'information exacte est une valeur ajoutée.Citation:
Envoyé par BenWillard
Citation:
Envoyé par BenWillard
Tu supposes que tu arrives à tirer suffisamment d'information via le code des APIs dont tu dépends. Exemple une IOException sur un fichier ou un socket ...Citation:
Envoyé par BenWillard
C'est une facon de "cacher" les choses ...Citation:
Envoyé par BenWillard
Si tu passes sous "silence" (cf. try { /*Do Work*/ } catch (IOException e) { /*Does nothing*/ }), je vois pas comment tu peux analyser un problème.Citation:
Envoyé par BenWillard
Moi non plus mais plutôt LogManager.getTracer(Foobar.class).warning("Unable to make something", exception);Citation:
Envoyé par BenWillard
Oui, en effet.Citation:
C'est une facon de "cacher" les choses ...
Bin, ya l'user qui t'appelle et te dit "quand j'essaie de Do Work ça ne fait rien" :DCitation:
Tu supposes que tu arrives à tirer suffisamment d'information via le code des APIs dont tu dépends. Exemple une IOException sur un fichier ou un socket ...
[...]
Si tu passes sous "silence" (cf. try { /*Do Work*/ } catch (IOException e) { /*Does nothing*/ }), je vois pas comment tu peux analyser un problème.
Et puis, "silencieusement", ça veut pas forcément dire "Does nothing" dans le catch... Ca peut aussi logger un code d'erreur compréhensible seulement par moi... Ca peut même dumper des variables etc, en tout cas quelque chose de plus sécu et/ou complet que la stacktrace...
Il y a plein de possibilités, mais en tout état de cause, je ne vois pas de raison de laisser des infos symboliques dans l'appli que j'envoie "dans la nature", et de ne pas obfusquer...
PS: j'oubliais, en plus, que quand tu obfusque, t'as un mappage qui te permet de déchiffrer des trucs du genreCitation:
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)
Il n'est pas question de l'applet dans ce lien à moins que cela m'aie échappé...Citation:
Envoyé par BenWillard