English version available

Simon Ritter a donné une présentation sur le futur JDK 9 à QCon London.

QCon London 2016 - Projet Jigsaw dans JDK 9 - La modularité arrive sur Java

La politique de compatibilité de Java

Il a commencé avec un fait intéressant: depuis longtemps, Java a une politique de compatibilité permanente.
Si une application utilise uniquement des API prises en charge par une version N de Java, elle devrait parfaitement fonctionner sur la version N+1, sans même devoir être recompilée.
Voilà pourquoi, à ce jour, il y a:

• 23 classes, 18 interfaces et 379 méthodes qui ont été dépréciées
• Et rien qui n’a été supprimé.

JDK 9 apporte des incompatibilités

Le JDK est devenu de plus en plus lourd au fil des années. Les choses vont changer avec la version 9.

• Un petit nombre d’API actuellement supportées sera supprimé
• La structure binaire du JRE et JDK va changer (voire les détails ci-dessous)
• Il est interdit d’utiliser le caractère underscore _ pour nommer une variable. C’est maintenant un mot-clé réservé.
• Il y aura un nouveau système de versionnage de sorte qu’il sera plus facile de faire la distinction entre les versions majeures, mineures, ou les mises à jour liées à la sécurité ; par exemple, Java 9.1.2.1. Le format de versionnage actuel est difficile à comprendre, par exemple les versions 8u51 et 8u60 ne sont pas très explicites.

La structure du JDK va changer. Le dossier JRE est supprimé, tools.jar et rt.jar ne seront plus présents, ces JARs contenaient pas mal de duplication.

Structure Pre-JDK 9

Pour mieux comprendre la structure pre-JDK 9, vous pouvez lire JDK 8 and JRE File Structure.

Structure JDK 9

La structure du JDK 9 est beaucoup plus propre.

JEP 260 proposal est au coeur du JDK 9 et Jigsaw.

L’idée est de rendre la plupart des API internes du JDK inaccessibles par défaut, mais en en laissant tout de même quelques-unes (celles qui sont largement utilisées et sont donc critiques) jusqu’à ce qu’elles soient remplacées.

Le but est d’encapsuler toutes les API dépréciées dans un module, et finalement de s’en débarrasser plus tard (JDK 10?).

Depuis la version 8 du JDK, un outil en ligne de commande existe pour analyser les dépendances de votre JAR ou de vos classes: jdeps. Essayez-le! Il peut être utile pour savoir si vous utilisez encore des API internes du JDK. Vous devriez éviter d’utiliser de telles dépendances, car elles peuvent être supprimées dans une future version du JDK.

Jigsaw et les modules

Nous parlons de module, mais qu’est-ce que c’est en fait?
Jigsaw apporte de la modularité au JDK. Il rend Java plus évolutif et flexible, tout en améliorant la sécurité, la maintenabilité et la performance.
Le JDK est divisé en modules, l’idée est de prendre seulement ce dont on a besoin.

Module

Un module est un regroupement de code (collection de packages), il peut également contenir:

• Du code natif
• Des ressources
• Des données de configuration

Mon premier module

Pour définir un module, vous devez créer un fichier module-info.java, qui contiendra (par exemple):

module com.company.mymodule { 
  requires com.company.myothermodule; 
  requires java.sql; 
}

Vous pouvez avoir des dépendances transitives (un peu comme dans Maven) grâce au mot-clé public.

module java.sql { 
  requires public java.logging; 
}

Cela signifie que si j’ai une dépendance sur le module java.sql, je vais avoir accès à toutes les classes incluses dans java.logging (tout du moins tous les types marqués public).

Nous avons maintenant un graphe de dépendances des modules.

Visibilité d’un package

Avec l’utilisation du mot-clé exports.

module com.company.myothermodule { 
  exports com.company.myothermodule.alpha;  
  exports com.company.myothermodule.beta; 
}

Ce qui est exporté est visible, ça ne l’est pas par défaut!

Avec Java 9 et l’arrivée des modules, nous devons redéfinir le mot-clé public. Il a maintenant plusieurs significations:

• Public à tout le monde
• Public, mais seulement à des modules particuliers
• Public, uniquement à l’intérieur d’un module

Public ne signifie plus nécessairement accessible, c’est un changement fondamental.
Vous pouvez lire la spécification de Jigsaw pour en savoir plus.

Compilation et exécution avec le « module path »

Oubliez le classpath, il y a un nouveau paramètre modulepath (ou -mp) disponible avec la commande javac / java. Sa valeur contient un ou plusieurs répertoires qui contiennent les modules nécessaires pour compiler / exécuter votre application.

Enfin, notez qu’il y aura des modules par défaut pour les fichiers JAR qui ne sont pas encore modularisés (module automatique).

 English version available

Juergen Hoeller, le co-fondateur du Framework Spring a fait une présentation la semaine dernière au QCon London.

QCon London 2016 - Spring Framework 5 - Preview & Roadmap

Commençons par un bref historique, le Framework Spring a été créé en 2002 avec une première version en 2004 (oui, c’était il y a 12 ans!), un bon bout de temps pour un framework qui est encore largement utilisé et en cours de développement. Depuis sa création, l’adoption et le nombre de projets au sein de Spring n’ont jamais cessé de croître. Au début, Spring a été créé pour gérer des POJOs dans un conteneur léger en utilisant l’injection de dépendances (en suivant le principe d’Inversion de contrôle), Spring était une alternative aux conteneurs JEE dits lourds tels que GlassFish ou WebSphere.

Spring est maintenant devenu un ensemble de projets disponibles pour satisfaire toutes les exigences du développement d’une application. Spring est comme un jeu de Legos, vous pouvez sélectionner et assembler ces sous-projets comme des briques pour construire quelque chose de plus grand.

• Imaginez que vous avez besoin d’utiliser une base de données, vous pouvez utiliser Spring Data
• Vous avez besoin d’une application sécurisée avec un système d’authentification, il vous suffit d’utiliser Spring Security
• Vous voulez être en mesure de vous connecter à votre application par le biais des réseaux sociaux, Spring Social est là pour vous
• Et ainsi de suite

Vous pouvez jeter un oeil à la liste complète des projets Spring.

Spring 4.3

Avant de passer à Spring 5, Juergen a parlé de Spring 4. Quand j’écris cet article, la version actuelle est 4.2.5. Une release candidate (RC) de Spring 4.3 sera disponible en mars 2016 suivie d’une General availability (GA) en mai 2016. Cette version comprendra quelques changements pratiques:

• Dans le framework Spring core:
  L’annotation @autowired utilisée pour injecter une dépendance sera implicite et sera donc désormais optionnelle
• Dans Spring MVC (fait partie du core):
  La déclaration d’un contrôleur MVC est simplifiée. Avant, value était le nom de l’attribut à utiliser:

  @RequestMapping(value = '/mypath', method = RequestMethod.POST)
  

  Désormais, nous allons utiliser un nom plus significatif path:

  @RequestMapping(path = '/mypath', method = RequestMethod.POST)
  

  De nouvelles annotations font leur apparition, des raccourcis pour éviter de spécifier la méthode HTTP. Le nom de l’attribut étant facultatif, la déclaration du contrôleur devient extrêmement simple.

  @PostMapping('/mypath')
  

  Et l’équivalent pour un GET

  @GetMapping('/mypath')
  

Spring 5.0 annoncé

Ensuite, Juergen a annoncé que Spring 5.0 sera disponible dans le courant de l’année 2017 et compatible avec le JDK 8 et 9. Sur la roadmap, la version AG devrait être disponible en Mars 2017 (en même temps que le JDK 9 sera publié). Dans le cas où la release du JDK 9 serait retardée, Spring 5.0 le sera probablement aussi.

Quelles sont les principales nouveautés de Spring 5?

Il y a 3 thèmes clés qui vont modifier le framework:

• JDK 9 et les modules Jigsaw
• Servlet 4.0 et HTTP/2
• Architecture réactive

JDK 9 et l’utilisation de Jigsaw

En une phrase, Jigsaw apporte de la modularité au JDK. Le JDK est divisé en modules et vous pouvez utiliser seulement ceux dont vous avez besoin pour créer votre application.

Le JDK sera livré avec un ensemble de modules, mais vous pouvez également définir vos propres modules. Pour définir un module, vous devez créer un fichier module-info.java:

module my.app.db {
  requires java.sql;
  requires spring.jdbc;
}

A l’intérieur d’un module, vous spécifiez les modules dont vous avez besoin avec le mot-clé requires. Les modules gèrent les dépendances transitives, un peu comme Maven. Si j’utilise le module my.app.db ci-dessus, je peux accéder à l’ensemble des classes venant du module java.sql. Le principal avantage est que cela rend votre application plus modulaire en reposant sur un sous-ensemble de modules au lieu d’un JDK complet.

Tous les jars de Spring 5 seront packagés avec ces métadonnées Jigsaw, le nom du module suivra les conventions déjà utilisées sur le repo Maven Central afin d’éviter toute confusion (spring-context, spring-jdbc, spring-webmvc…). Il sera très facile de construire vos applications en spécifiant les modules Spring dont vous avez besoin.

HTTP/2

HTTP/1.1 est un vieux protocole (1999) et souffre de limitations. Dans le monde du front-end, nous utilisons des solutions de contournement, mais ce n’est pas l’idéal. Par exemple, pour éviter de surcharger le serveur avec de multiples requêtes lorsqu’une page contient beaucoup d’images, nous utilisons des sprites CSS (c.-à-d. combiner ces images dans un seul fichier que nous « découpons » ensuite côté client via CSS). Avec HTTP/2, le protocole est plus rapide car il permet des requêtes simultanées. Il y a d’autres avantages que vous pouvez lire sur la FAQ HTTP/2 Frequently Asked Questions.

Comme l’a déclaré Juergen, « Nous devons adopter HTTP/2 dans les terres de Java! »

Pour ce faire, Spring 5 utilisera la dernière version de la librairie Servlet, Servlet 4.0 qui:

• Impose le support pour HTTP/2 dans des conteneurs de servlet
• Contient des fonctionnalités pour prioriser les Streams et le push de ressources via une API

Programmation réactive

Un autre point fort a été l’annonce de la création d’un nouveau projet Spring appelé Spring Reactive. Ce sera un Spring MVC-like avec des endpoints basés sur une fondation réactive.

• Réutilisation de style de modèle de programmation de Spring MVC
• Mais en acceptant ou en retournant des reactive streams (par exemple, Mono – 1 élément, Flux – liste d’éléments)

Spring Reactive sera basé sur le Project Reactor, un ensemble de bibliothèques pour construire des applications réactives cloud-ready sur la JVM. Ce nouveau projet ne sera pas indépendant et sera inclus dans le noyau Spring Framework à un moment donné.

Juergen nous rappelle que le « Reactive arrive »:

• Pas de blocage de thread
• Les drivers réactif pour les bases de données deviennent disponibles (PostgreSQL, Mongo, Couchbase…)
• Il y a aussi des clients HTTP réactifs (Netty, Jetty, OkHttp…)

Note pour moi-même et peut-être aussi pour vous, il est important de se documenter sur le Reactive Programming et se familiariser avec les concepts. Il y a de grandes chances qu’il se démocratise dans les années qui viennent.

Enfin, Spring 5 utilisera toutes les dernières fonctionnalités introduites avec Java 8:

• Lambdas, références de méthode, méthodes par défaut dans les interfaces
• Nouvelles classes utilitaires: java.util.Optional, java.util.function, java.util.stream

Evidemment, Spring 5 nécessite Java 8. Si votre projet utilise encore une ancienne version, vous devrez vous contenter de Spring 4.X. La bonne nouvelle est que Spring 4 aura un support étendu jusqu’en 2020, de sorte que vous aurez encore un peu de temps pour migrer!

Les slides de la présentation sont disponibles sur le site de QCon.