Pages

jeudi 4 avril 2013

L'avenir de Java : Normal ou décaféiné par Alexis Moussine-Pouchkine

Alexis Moussine-Pouckine a longtemps travaillé chez Sun Microsystems (notamment sur la promotion du serveur d’application open source Glassfish) avant de rejoindre Google comme Developer Relation. 



Le sujet du jour était de réfléchir si le langage Java avait encore un avenir ou si le langage était dépassé pour s’adapter aux changements actuels ? Il faut garder à l’esprit que Java s’est développé grâce au web et que l'histoire est remplie d’outils qui sont tombés à l’eau car ils n’ont pas su suivre les évolutions.

Quand on fait un constat l’avenir de Java n’est pas forcément tout rose. Par exemple, beaucoup de fournisseurs rencontrent certaines limites pour proposer Java sur leur plateforme cloud. Le cloud apporte la facturation à l’usage. Les différents prestataires proposent des environnements préconfigurés sur des serveurs sur lesquels ils doivent optimiser les ressources pour que chaque client puisse encaisser les pics d'utilisation de ses applications. Ce n’est pas facile de le faire avec Java.

En effet si plusieurs applications tournent sur la même JVM c’est la première qui prend les ressources qui les aura. Pour résoudre ce problème on a détourné le problème en utilisant une instance de JVM par application. Mais ce n’est pas très optimal. Lorsqu’un utilisateur exécute plusieurs applications chaque JVM doit faire les mêmes opérations : charger, parser, vérifier des éléments qui sont communs. Le temps de chargement, l’empreinte mémoire et les temps d’exécution s’en ressentent.

La communauté Java n’est pas restée inactive sur ce sujet puisque que des JSR existent

JSR 121 : Application Isolation Api spécification initiée en 2001 et finalisée en 2006
Cette JSR permet d’isoler et de contrôler le cycle de vie de plusieurs applications sur la même machine virtuelle Java. Chaque application, appelée «Isolate», a l'illusion de fonctionner sur sa propre machine virtuelle mais a également la possibilité de partager des ressources communes avec les autres applications.

JSR 284 : Resource Consumption Management Api initiée en 2006 et achevée en 2009
Cette API donne la possibilité aux applications de mieux gérer les ressources : les réserver, les libérer...

Projet Jigsaw (inspiré de JSR294 : Improved Modularity Support in the Java)
Mise en place d’un système modulaire pour la plate-forme Java qui permettra d’optimiser les performances. Les concepts de modularité sont directement introduits dans le langage.

Malheureusement ces JSR et Jigsaw ne sont pas implémentés dans la JVM pour le moment.

Si on regarde également ce qu’il manque au niveau de Java pour s’adapter mieux au cloud, c’est la notion de multi tenancy (traduit par Alexis en copropriété). Dans un environnement multi tenancy les différents clients partagent la même application, les mêmes ressources mais ils gardent un accès exclusif sur leurs données et ne peuvent pas voir les données des autres. Au lieu de déployer une instance de l’application par client on ne conserve qu’une seule application.

Java sera t’il évolué pour s’adapter à ce monde en mouvement ? Le passé montre que Java a su le faire comme le montre par exemple la version 5 et les generics. La version 8 avec les Lambdas expressions est un autre pas et elle permettra une simplification de syntaxe pour la programmation fonctionnelle. Mais qu’en est t-il des problématiques Web?

Une présentation de Mark Reinhold (Chief Architect of the Java Platform Group at Oracle) lève le voile sur le scope prévisionnel de la version 9 de Java


Apparemment nous aurons la modularité (Jigsaw), la gestion des ressources (JSR 284), le multi tenancy.... 
Donc soyons confiants

Aucun commentaire:

Enregistrer un commentaire

Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.