Maxim_Kazmin - Fotolia

Retraite du plug-in Java : quelles conséquences pour les développeurs ?

Le support des plug-ins disparaît progressivement des navigateurs Web. De quoi pousser à la réécriture des applications métiers les utilisant.

C’est fin janvier qu’Oracle a dévoilé ses projets pour l’abandon progressif de son extension Java pour navigateurs Web. Une vraie-fausse surprise en fait : l’éditeur ne faisait que tirer les conséquences de l’abandon programmé du support des plug-ins NPAPI par les navigateurs Web. Google l’avait annoncé pour Chrome en septembre 2013. La version 42 de son navigateur, lancée en avril 2015, le désactivait déjà par défaut.

Il y près d’un an, Oracle s’était déjà ému de l’abandon programmé des extensions NPAPI par Firefox, alors tout juste annoncé par la fondation Mozilla, et programmé pour la fin 2016. Il mettait alors en cause les navigateurs Web des terminaux mobiles – ceux-là même qui avaient été moqués initialement pour leur absence de support de Java et de Flash.

Mais aujourd’hui, Oracle reconnaît ne pas avoir le choix : « fin 2015, de nombreux éditeurs de navigateurs Web ont soit supprimé soit annoncé un calendrier de retrait du support des plug-ins basés sur des standards, éliminant la possibilité d’intégrer des technologies basées sur des extensions telles que Flash, Silverlight et Java ».

Et Microsoft n’est pas absent de ce mouvement : son navigateur Edge, dans Windows 10, ne supporte pas les plug-ins. Internet Explorer les supporte encore, mais il est clairement appelé à être remplacé. Safari et Opera continuent toutefois de supporter les plug-ins.

Le plug-in Java sera donc considéré comme obsolète avec la version 9 du kit de développement Java, programmée pour 2017, et il sera recommandé aux développeurs de migrer leurs applets sur Java Web Start, qui permet d’exécuter des applets dans un navigateur Web, sans utiliser de plug-in.

Le monde merveilleux des plug-ins

Les plug-ins sont apparus aux débuts du Web, lorsque les capacités des navigateurs Web étaient plus limitées qu’aujourd’hui. Les plug-ins permettaient d’apporter des fonctionnalités à l’environnement du navigateur sans forcer les utilisateurs à installer localement des applications.

NPAPI (Netscape Plugin API) s’est alors imposé comme standard. Il a permis de faire d’une réalité l’interopérabilité fonctionnelle entre navigateurs et plateformes. Des technologies telles que Flash, Silverlight et Java ont tiré profit de NPAPI pour fournir aux applications Web des capacités comparables à celles d’applications natives. De quoi transformer le Web en plateforme pour applications grand public et entreprises.

Mais le nirvana NPAPI a rapidement montré ses travers : le code exécuté via les plug-ins disposait des privilèges de l’utilisateur sans isolation. Les vulnérabilités en résultant se sont avérées nombreuses, faisant des plug-ins une cible de choix pour les cybercriminels. Le prix, en termes de sécurité, a été lourd.

Quelles perspectives pour les développeurs ?

Les développeurs ont déjà commencé à explorer de nouvelles pistes pour se passer des plug-ins. Ils réécrivent leur code pour se passer de technologies anciennes et profiter des nouvelles. L’émergence de HTML5 et les avances de JavaScript et de CSS ont joué un rôle clé dans l’évolution des applications Web.

Les développeurs peuvent toujours utiliser l’API Applet Java – elle est déconseillée, mais pas abandonnée –, mais son support sera limité. Et c’est sans compter avec les erreurs de compilation induites par cette évolution.

Pour les grandes organisations, cette situation peut représenter un défi, compte tenu du grand nombre d’applications distribuées que certaines utilisent, sans être sûres que l’API Applet a été implémentée. Les équipes de développement peuvent toutefois utiliser la console d’administration avancée de Java pour suivre leur recours à Java et déterminer où l’API est utilisée.

Lorsqu’il s’agit d’adapter le code pour éliminer l’API Applet, les développeurs peuvent se tourner vers HTML5, ou encore adopter l’une des options proposées par Oracle. L’éditeur suggère par exemple de passer à Java Web Start, un framework qui permet de lancer des applications Java depuis Internet, sans recourir à un plug-in. Mais certains s’inquiètent du risque d’utilisation de Web Start par des pirates pour exploiter des vulnérabilités Java, de la même manière qu’ils passaient par les plug-ins. Fin janvier dernier, Morey Haber, vice-président technologie chez BeyondTrust, alertait d’ailleurs sur ce risque : « les vulnérabilités Java Web Start peuvent être exploitées tout autant que celles des applets. Donc, même une fois que le plug-in sera en fin de vie, les utilisateurs devront mettre à jour Java pour profiter des correctifs ».

Dès lors, les équipes de développement semblent contraintes de chercher d’autres options. Les applications s’appuyant sur des plug-ins devraient être réécrites, et les nouvelles applications devraient tout simplement essayer d’éviter ces technologies.

Avec nos confrères de SearchEnterpriseDesktop.com.

Pour approfondir sur Applications métiers

Close