Discussion :

[Nico02]

Au mieux faudrait générer un jnlp à la volée avec le session id dedans, le mettre dans le jar, signer le jar à la volée, bonjour la charge pour le serveur. Peut être faisable mais complexe, sujet à de nombreuses erreurs d'exécution.

Je fais déjà quelque chose de similaire sur notre projet au boulot, c'est pour ça que je pensais ça possible (après je connais rien au smartcard donc j'ai laissé des réserves). Et même si effectivement l’utilisateur télécharge une nouvelle version du JNLP, il n'a pas besoin de re-télécharger toute l'appli à chaque fois.

Il est d’ailleurs aussi possible de contrôler que l'application Java est déjà lancée pour éviter d'en lancer plusieurs instances. De cette façon on peut faire communiquer facilement les 2 parties et l'utilisateur peut utiliser les 2 applis en même temps.

Reste que dans un formulaire ça complique quand même encore les choses car il faudra arriver à synchroniser l'appel à la partie Java, la génération du JNLP, le retour de l'appli Java et tout ça dans des appels AJAX si on veut rendre ça transparent à l'utilisation

[Uther]

Oui, c'est la partie:

Mais c'est très lourd pour l'utilisateur car de son point de vue, à chaque fois, il télécharge une nouvelle application.

Oui lancer un jnpl c'est moins transparent pour l'utilisateur final.
Mais Il ne re-téléchargera que le jnpl, par toute l'application. Si seul les paramètres de l’applications sont changés dans le jnpl, Java Web Start, redémarrera le programmé déjà installé.

[tchize_]

Sans compter les nombreux appels au helpdesk parce que java n'est pas à jour depuis au moins 2 releases et donc le jnlp ne se lance plus... On en reviens à ce que je disais, on change un truc qui nécessite 2 jours de mise en place tests compris en un sous projet d'un à 2 mois sans garanties de fonctionnement potable au final

[Uther]

Les problèmes de mise a jour sont normalement les même pour les applet et JWS.

[gerard66]

bonjour,

si j'ai bien compris adieu .jar et applet !
il faut donc se tourner vers webstart.
Petite question, est-il encore judicieux de développer en java étant donné que pour qu'une application java (même gratuite) soit diffuser il faut mettre la main à la poche (et pas qu'un peu!).

[Uther]

Non il n'y a rien a payer pour diffuser son application Java, D’où tu sors cela?

[gerard66]

si j'ai bien compris il faut signer les jar et applets avec des certificats qui doivent provenir d'organismes privés moyennant finances
j'ai réalisé une applet qui ne s'ouvre même pas en local pour cause de sécurité car non signée
J'ai téléchargé l'appli de signature gratuite sous webstart d'un fournisseur de clés et firefox refuse de l'ouvrir pour cause de sécurité

Meme Netbeans me signale qu'il faut des signatures robustes donc privées pour le déploiement d'une appli webstart (les cles perso n'etant pas fiables ! mickey ou donald peuvent les certifier) donc je ne vois pas comment échapper au paiement de plusieurs centaines d'euros par an.
je suis donc un peu perdu et dubitatif ...

[sinople]

si j'ai bien compris il faut signer les jar et applets avec des certificats qui doivent provenir d'organismes privés moyennant finances

Normalement pour ce genre de truc, il faut signer avec des certificats qui sont reconnus par la machine. Si tu as le contrôle sur l'infrastructure cible, tu ne devrais pas avoir trop de problème a t'auto-certifié. Si tu vises le grand public, effectivement qu'il faudra passé par un organisme de certification qui va probablement te facturer la prestation.

Pour revenir à la news, ce machin c'est un peu l'équivalent de ClickOnce en .Net ?

[gerard66]

merci
c'est bien ce que j'avais compris donc exit pour moi le développement java pour grand public.
je vais retourner à mon bon vieux c++ et mon .exe

ORACLE ne prépare t il pas les funérailles de JAVA ?

[sinople]

Bon si c'est la même chose que ClickOnce ces histoires de certificats c'est simplement pour réduire l'agressivité des message d'avertissement, ça ne bloque pas complétement l'execution.

[tomlev]

Pour revenir à la news, ce machin c'est un peu l'équivalent de ClickOnce en .Net ?

Oui tout à fait. En gros tu télécharges un manifeste, ça installe l'appli si elle est pas déjà installée (ou ça la met à jour si besoin), et ça la lance.

[ddoumeche]

Pour revenir à la news, ce machin c'est un peu l'équivalent de ClickOnce en .Net ?

Non, c'est clickOnce est l'équivalent de Java Web Start sur .Net, pas l'inverse.

Pour moi, l'abandon des applets est un très bonne nouvelle qui aurait pu être prise dès Java 8, lorsqu'il apparaissait clairement que de multiples bugs de sécurité mettait en péril la sécurité des plateformes. Tout cela pour conserver une technologique de plus de 15 ans et qui était déjà obsolète voila 10 ans ? et que pas grand monde voir personne n'utilise ?

Rien n'interdisait à ceux qui avait besoin des applets de continuer à utiliser Java 7, ni à Oracle de continuer à faire des updates de sécurité comme il est fait actuellement.
Mais le plugin était déjà plus une plaie qu'autre chose.

Evidemment, une telle décision ne se prend pas à la légère.

[yahiko]

C'était quand même génial les applets Java pour faire planter un site

[tchize_]

merci
c'est bien ce que j'avais compris donc exit pour moi le développement java pour grand public.
je vais retourner à mon bon vieux c++ et mon .exe

ORACLE ne prépare t il pas les funérailles de JAVA ?

Ne pas confondre. Les signatures sont nécessaires pour ce qui viens du domaine web comme webstart et applets. Les applications standalone n'ont pas besoin de signature. Les exes ne pouvant être que standalone par nature, pas besoin de signature.
Tu es occuper de comparer pommes et poires. En 12 ans de dev java pro, seulement deux fois j'ai eu besoin d'un certificat.

[gerard1638]

merci pour ces précisions

[bouye]

Payer (et de manière récurrente en plus) un certificat n'a rien de trivial pour un jeune développeur ou un petit studio qui débute. Normalement, a moins d'aller bidouiller dans les fichiers de sécurité de la JVM, il n'est pas non-plus possible désormais d'utiliser un certificat auto-généré depuis les maj de sécurité de 2014-2015 (ce qui est bien normal d'ailleurs). Donc, oui, par un certain coté, JWS n'est pas vraiment un mode de distribution gratuit.

[gerard66]

En gros webstart peut être utilisé gratuitement (moyennant bidouille en interne). Pour le grand public ou pro il faudra développer dans une optique commerciale en pariant sur un minimum de retour sur investissement annuel (signature tiers) ! "La gratuité" est un concept bien virtuel et relatif ! çà va faire les beaux jours des RAD (j'exagère un peu mais pas trop !)!

[OButterlin]

On s'écarte un peu de la problématique, il ne s'agit pas de comparer applications desktop et applications web.
La problématique des plugins et en particulier du plugin java pour une application web est entière : comment contourner les lacunes html/javascript ?
L'applet est (et donc "était" si on supprime les plugins) une solution très intéressante voir incontournable. Il ne s'agit pas de mettre une applet là où on peut faire en html/javascript... pas plus qu'il ne s'agirait de faire une application web pour gérer un robot...

[gerard66]

je pense qu'il est nécessaire de connaitre l'impact financier (visible ou caché) d'une technologie avant de la choisir sinon comme dans mon cas on se retrouve à développer des semaines entières une appli gratuite qui s'avère devenir payante !

[Uther]

Payer (et de manière récurrente en plus) un certificat n'a rien de trivial pour un jeune développeur ou un petit studio qui débute. Normalement, a moins d'aller bidouiller dans les fichiers de sécurité de la JVM, il n'est pas non-plus possible désormais d'utiliser un certificat auto-généré depuis les maj de sécurité de 2014-2015 (ce qui est bien normal d'ailleurs). Donc, oui, par un certain coté, JWS n'est pas vraiment un mode de distribution gratuit.

Un certificat auto-signé, non, mais il doit être possible d'installer des certificats gratuits de type de "Let's encrypt". Et puis généralement c'est le client qui va payer pour le certificat, pas le développeur