ParisJUG du 13/03/2012 : Java.next !

Le ParisJUG du 13 mars 2012 présentait les prochaines évolutions de Java en commençant par le classique retour sur l’historique de Java et en particulier Java 7.

Java 7 sorte de version intermédiaire avant la version 8 de Java contenait l’ensemble des améliorations visibles ici : http://openjdk.java.net/projects/jdk7/features/

Pour faire un rapide tour :

  • JSR 334 “project coin” : String dans les switch, Multi-catch, Try-with-ressources (AutoCloseable), Diamond operator pour éviter de repeater le type d’un generic, Simplified varargs, Binary literals and underscores in numeric literals
  • JSR 203 « NIO2 » : Un design facilitant les extensions, accès au metadata des fichiers, des méthodes utilitaires comme move ou copy, une abstraction de plus haut niveau (java.nio.file.Path), une gestion des exceptions consistante
  • JSR 166y Fork/Join et Parallel Array pour encore faciliter la programmation parallèle.
  • JSR 292 InvokeDynamic pour améliorer les performances des langages dynamiques (type Groovy) sur la JVM.

Mais la présentation s’attachait surtout à présenter JDK 8 prévu pour l’été 2013 dont la liste des améliorations contient le projet Jigsaw, le projet lambda, une nouvelle API Date (le retour de la vengeance), une convergence entre les VM JRockit et Hotspot ou encore JavaFX 3.0. Il est possible de suivre les évolutions sur le site d’OpenJDK : http://openjdk.java.net/projects/jdk8/

C’est sur ce premier projet Jigsaw qu’est revenu Alexis Moussine-Pouchkine.

Il y a déjà eu de nombreux essais pour améliorer la modularisation de Java : JSR 277 Java module, OSGi, JSR 294 et maintenant JigSaw

Le problème actuel est que la construction, le packaging et la publication d’une application tombe souvent dans l’enfer des JAR. Il faut donc trouver une meilleure solution pour améliorer la scalabilité par rapport à la plateforme en particulier pour les petits périphériques et améliorer les performances surtout les temps de téléchargement et de démarrage.

Le but est donc de créer un système de modules statiques et simples, assez performant pour modulariser le JDK lui-même, améliorer les performances et utilisable par n’importe quel développeur java.

Les conséquences sont plus de classpath, plus de rt.jar. L’idée est de résoudre les problèmes de dépendances en amont !

La mise en place des modules Jigsaw offrira différentes possibilités : Grouping, Versioning, Encapsultation avec le mot clé permits, splitting, aggregation avec le mot clé provides.

Voila un exemple de modularisation avec Jigsaw :

module com.greetings @ 0.1 {
	requires jdk.base; // default to the highest available version
	requires org.astro @ 1.2;
	class com.greetings.Hello;
}

Vous trouverez tous les détails sur cette page : http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html

Avec Jigsaw, le fichier jmod remplace le jar mais il sera toujours possible d’utiliser des repositories : librairies mis en ligne au bout d’une url. Il est prévu une intéropérabilité avec OSGi. La compatibilité sera toujours existante par on pourra rajouter des informations au jar existant pour les rendre compatible jigsaw.

Le deuxième présentateur Remi Forax qui est venu nous présenter les lambdas ou l’arche d’alliance de java 😉

Pourquoi les lambdas ? L’idée est de se rapprocher des langages fonctionnels et de simplifier l’utilisation des « closures » ou méthodes anonymes dans Java même si une partie du fonctionnement est déjà réalisable avec les Inner Class.

La grosse question est de connaître quel est le type d’une lambda et la solution a été trouvée dans les Single Abstract Method qui sont des interfaces qui contiennent une seule déclaration de méthode. On peut même les nommer interfaces fonctionnelles et Java en possède déjà tel que Runnable ou ActionListener.

Voila des exemples du futur code utilisant les lambdas :

	(int x, int y) -> x + y

	FileFilter java = (File f) -> f.getName().endsWith(".java");

	new Thread(() -> {
		connectToService();
		sendNotification();
	}).start();

Contrairement au Inner class, une lambda peut capturer les valeurs des variables du scope : le this ne référence pas la pseudo inner class mais l’englobant. Pour clarifier les choses, les inner class sont des classes, les lambdas sont des fonctions anonymes.

Les lambdas ajoutent beaucoup d’expressivité au langage Java mais l’idée est aussi d’ajouter les librairies pouvant en tirer partie. Ajouter des nouvelles fonctionnalités aux librairies existantes est quelque chose  de très difficile en Java actuellement si on veut garder la compatibilité. Il a donc fallu trouver une solution et celle-ci a été de mettre en place les « Default methods »

Par exemple :

interface Iterable<E> {
	public  Interable<E> filter(Predicate<E> predicate) default {
		//code
	}
}

Les defaults methods sont en fait des traits (Scala) ou mixins (Ruby) simplifiés.

Les defaults methods et les lambdas sont bien sur faits pour fonctionner ensemble. Actuellement si on veut écrire du code qui trie les personnes par leur nom on va écrire :

Collections.sort(people, new Comparator<Person>() {
	public int compare(Person x, Person y) {
		return x.getLastName().compareTo(y.getLastName());
});

Demain avec les lambdas, de l’ajout de l’interface Mapper et de l’ajout de la default method comparing à Collections, il suffira d’écrire :

Collections.sort(people, comparing(p -> p.getLastName()));

La encore vous trouverez tous les détails sur le site d’OpenJDK : http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *