Le blog de Fabien DUMINY

Un blog utilisant WordPress

Skip to: Content | Sidebar | Footer

Paris JUG – Java.next()

23 mars, 2012 (10:00) | Evènement, Java, Paris JUG | By: fabien

Mardi 13 mars, j’ai assisté à la soirée Java.next() du Paris JUG pour voir la présentation des projets Jigsaw et Lambda.

Alexis Moussine-Pouchkine commence sa présentation du projet Jigsaw en parlant rapidement des nouveautés introduites par Java 7. Il aborde notamment le projet Coin, qui introduit des petites modifications ainsi que quelques fonctions utilitaires dans le JDK. Parmi celles-ci, on trouve une nouvelle classe appelée Objects qui fournit quelques méthodes statiques telles que equals(Object, Object), hashCode(Object), toString(Object) et deepEquals(Object, Object) qui gèrent le cas où l’un des objets passés en paramètre est null. Celles-ci existaient déjà dans la classe ObjectUtils de la librairie apache commons lang mais c’est mieux d’avoir ça en standard dans le JDK.
Ensuite, Alexis aborde le sujet proprement dit, c’est à dire le projet Jigsaw. Le JDK étant monolithique et de plus en plus volumineux au fur et à mesure des versions, ce projet permettra de le rendre plus modulaire. Tous les développeurs qui utiliseront java 8 seront impactés par ce projet. En effet, il n’y aura plus de classpath, que ce soit à la compilation ou à l’exécution. Un fichier jar deviendra un module (fichier jmod). La classe module-info située à la racine du module permet de définir ses caractéristiques :

  • Nom du module et sa version
  • Nom éventuel de la classe principale (même concept que dans le fichier jar)
  • Modules pré-requis, définis par leur nom et leur version
  • Packages à cacher (cela permet aussi de cacher des classes publiques)
  • …etc…

Ce projet introduit aussi le concept de librairie qui est un ensemble de modules. Au départ, il n’y aura qu’une seule librairie constituée par le JDK. Chaque librairie a un parent, qui est par défaut le JDK.
Un autre concept qui apparaît est celui de dépôt qui est un serveur distant contenant des librairies.

Rendre le JDK plus modulaire n’est pas une tache facile. Ainsi, pour faire un simple Hello world, les problèmes de dépendances forcent à avoir le package corba dans le classpath !
Le travail de simplification des dépendances a d’ailleurs déjà commencé dans le JDK 7.

Un mode de compatibilité sera aussi mis en place pour ne pas être forcé de recompiler toutes les librairies java existantes. Sans cela, le JDK 8 risquerait d’être adopté moins rapidement ;-)

Remarques :

  • Il existe dans le projet Jigsaw un prototype utilisant le dépôt Maven central comme dépôt de librairies (sous la forme de fichiers jar). Le problème est que les dépendances ne sont pas toujours correctes.
  • Le projet Penrose a été créé afin d’étudier et fournir une interopérabilité dans les 2 sens entre le projet Jigsaw et OSGI

Pour la deuxième partie de la soirée, Rémi Forax nous présente le projet Lambda. Avant d’aborder le sujet proprement dit, Rémi, en tant que maître de conférence de l’université Paris-Est Marne-la-Vallée, attire notre attention sur le besoin de postes d’apprentis pour ses étudiants (voir la page sur les formations en apprentissage de l’université). Puis il aborde le sujet proprement dit : les Lambdas. Une lambda est une fonction anonyme, ce qui pourrait se traduire en java par une Single Abstract Method (SAM), c’est à dire une interface avec une seule méthode : c’est le cas des interfaces Callable et Runnable. Mais ce n’est pas suffisant pour définir une Lambda car c’est aussi une fonction anonyme qui peut, par exemple, représenter toutes les méthodes prenant 2 entiers et retournant un entier. Il n’est pas possible de représenter cela actuellement en Java sans donner un nom à la méthode.

Pour Rémi, les lambdas seront surtout utiles dans les interfaces du package java.util (en rajoutant par exemple la méthode sort sur l’interface List) mais comment rajouter une méthode dans celles-ci sans casser la compatibilité avec tout le code déjà dévéloppé ? La solution proposée introduit la possibilité de définir une implémentation par défaut pour chaque méthode d’une interface. Pour que cela fonctionne, il faut définir des règles simples pour l’héritage multiple.

Pour de meilleures performances, cette solution sera implémentée par des proxy à l’exécution car la JVM pourra faire des optimisations (pas de nouvelles classes, donc moins de travail pour le vérificateur; optimisation si la méthode n’est jamais appelée …), ce qui ne serait pas le cas pour une implémentation dans le compilateur. Pour l’instant, l’implémentation est plus lente mais Rémi espère résoudre ce problème.

Ces développements devraient être fusionnés avec le JDK 8 d’ici avril, mais peut être pas avant Devoxx France 2012.

Be Sociable, Share!
Share and Enjoy

Write a comment





If your website is claim enabled, it will be notified that you have posted here.

MySQL query error