Apres java 8, java 9 et 10 - BreizhCamp 2018

#ApresJava8 1
Après Java 8,
Java 9 et 10

#ApresJava9#ApresJava8
Java 8
Les expressions lambdas + références de méthodes
Approche fonctionnelle : l’API Stream + Collector
Les interfaces : les méthodes statiques et par défaut
L’API Date & Time
Optional et CompletableFuture
Permgen -> Metaspace
…
2

Java 8
Made Java great again ?
TIOBE : langage de l’année en 2005 et en 2015
3
Un engouement certain
constaté par la popularité de Java 8
Diffusé en mars 2014

Java 9
Sûrement la version la plus controversée
4
Première fois que l’EC du JCP vote Non
Diffusé en septembre 2017
2 updates : 9.0.1, 9.0.4
Introduit des changements majeurs
Tout en tentant d’offrir une certaine compatibilité

Java 9 : les fonctionnalités
API
Fabriques pour des collections immuables
Process API
Reactive Streams (Flow API)
Var Handles
…
Le système de modules (JPMS) issu du projet Jigsaw
Introduit une rupture
Avec un mode de compatibilité, pour faciliter la migration
5
Evolutions mineures dans le langage
Outils
JShell
Jlink pour créer des runtime compacts
Recherche dans la Javadoc en HTML 5
Jdeprscan
…
JVM
G1 est le ramasse-miettes par défaut
Réduction de la taille mémoire (Compact Strings)
Amélioration de la performance et de la sécurité
Multi-Release Jar
…
+ 89 JEPs

Nouveau plan de releases
LTS : le nouveau modèle de support
Version tous les 3 ans à partir de Java 11
6
2 releases majeures de Java par an :
en mars et septembre
Les deux releases suivantes après Java 9 :
Java 10 en mars 2018
Java 11 en septembre 2018
 Java 9 n’est pas LTS
Ni Java 10

Java 10
12 JEPs
1 utile pour les développeurs
+ évolutions dans les API existantes
6 mois après Java 9, release de Java 10
Diffusé le 20 mars 2018
7
2 conséquences :
2) Java 9 quasiment pas utilisé
Mais déjà obsolète avec la sortie de Java 10
1) Durée de release réduite -> nombre de fonctionnalités réduites

#ApresJava8 8
Jean-Michel Doudoux
http://www.jmdoudoux.fr
@jmdoudoux
Co-fondateur du , membre du
Auteur de 2 didacticiels
Diffusés sous licence GNU FDL
• Développons en Java (3400 pages)
• Développons en Java avec Eclipse
CTO et

Roadmap
9
• Les a priori sur Java 9
• Les avantages de Java 9
• Faire un état des lieux avant migration
• La migration vers Java 9 : les stratégies
• Des fonctionnalités pour faciliter la migration
• Les difficultés
• Java 10

#ApresJava8 10
Les a priori
sur Java 9

Mythes et réalités
Le classpath est remplacé par le module-path
11
Le code de l’application doit être modularisé
sun.misc.Unsafe est retiré
NON
NON
NON
Une application Java 8 s’exécute en Java 9
La majorité du code existant n'aura pas besoin d'être modifié
Une application Java 8 compile en Java 9 Ça depend
Ça depend
OUI

#ApresJava8 12
Les avantages
de Java 9

Améliorations de la syntaxe
Méthodes private dans les interfaces
13
Opérateur diamant dans les classes anonymes internes
Variables effectivement finale dans try with ressources
@SafeVarags sur les méthodes d’instances private

API et outils
Fabriques pour collection immuable
Jshell : un outil de type REPL
Process API
14
Flow API (Reactive Stream)
Enrichissement de CompletableFuture
Var Handles
JavaDoc en HTML 5 avec recherche

Améliorations de la JVM
Globalement de meilleures performances
Segmented code Cache
G1 comme GC par défaut
15
Concaténation des chaînes avec InvokeDynamic
Compact String
Unified JVM Logging
Unified GC Logging

Les modules
Sont perçus comme contraignants
16
Exemple de contraintes :
plus d’accès par défaut aux classes public d’un module
plus d’introspection par défaut sur les classes d’un module
plus de split packages
plus dépendances circulaires
La nécessité de définir les dépendances dans les module-info ET les outils de build
…
 moins de liberté
utilisée pendant plus de 20 ans
parfois avec abus
Tous les systèmes de modules sont contraignants

Les modules
Mais on doit profiter des avantages des modules
L’occasion de remettre de l’ordre :
dans le design des livrables
dans les dépendances
dans les API utilisées (notamment celles non supportées du JDK)
17
Une configuration fiable
Réduire les problèmes du classpath hell
L’encapsulation forte
Améliorer la sécurité et la maintenabilité

4 types de modules
18
App Named modules Jar modulaire dans le module path
Automatic modules Jar non modulaire dans le module path
Nom extrait de MANIFEST.MF ou dérivé du nom du jar
Tous les packages sont exposés
Peuvent accéder à tous les autres modules
Pont entre named modules et unnamed module
Unnamed module Un seul module
classes, jars modulaires ou non dans le class path
tous les packages sont exposés
Peut accéder à tous les autres modules
Platform modules Modules du JRE

Runtime personnalisé
Outil jlink (Java Linker)
Pour créer un JRE personnalisé
Ne contenant que le nécessaire pour l’exécution d’une application
Deployer facilement une application
Sans s’appuyer sur un JRE pré-installé
19
Tous les jars doivent être modulaires
Uniquement des named modules (pas d’automatic modules)
Incluant TOUTES les dépendances

#ApresJava8 20
Faire un état
des lieux

Utilité
Recenser les différents points à prendre en compte
 Aider à choisir la stratégie de migration
 Avoir une meilleure visibilité sur l’ampleur de la tâche
Faire une cartographie des dépendances
Vérifier pour chacune si une version modulaire existe
En profiter pour faire du ménage
Et prévoir des upgrades
21
Utiliser l’outil jdeps pour obtenir des informations

jdeps
Fournit dans le JDK depuis Java 8, amélioré en Java 9
Analyse statique du bytecode pour déterminer les dépendances
Travaille sur les .class ou .jar
22
A passer sur l’application
mais aussi sur toutes les dépendances
Pour obtenir de nombreuses informations :
Des dépendances
Les split packages
Les API du JDK qui ne sont plus accessibles

jdeps
23
Dépendances agrégées au niveau des packages ou des jars
Possibilité de filtrage
Différents formats de restitution
dont des fichiers .dot
Par défaut affiche :
les modules du JDK requis
les dépendances de chaque packages
<package> -> <package> <module/JAR>

Les options de jdeps
Nombreuses options : -h pour l’intégralité
24
jdeps --class-path 'libs/*' -recursive monapp-3.2.jar
Option Rôle
--class-path ou -cp définir les dépendances dans le classpath
--module-path définir les dépendances dans le module path
-recursive ou –R parcours récursif des dépendances
--package ou –P seulement les dépendances vers un package
--dot-ouput créer des fichiers .dot par jar utilisable avec GraphViz
-verbose:class dépendances entre classes
--summary ou –s afficher un résumé des dépendances
--generate-module-info générer le fichier module-info.java
--generate-open-info générer le fichier module-info.java pour un module open
--jdk-internals ou -jdkinternals trouver les API internes utilisées

#ApresJava8 25
La migration
vers Java 9

Migrer une bibliothèque
Deux stratégies :
Sans conversion en module
Il faut absolument figer le nom du module
avec l’attribut Automatic-Module-Name dans le fichier MANIFEST.MF
Sinon le nom du module est déterminé à partir du nom du jar -> automatic module
Ne DOIT pas changer lors de la modularisation
La conversion en module d’un jar
Ajout d’un fichier module-info
fixe le nom du module et les dépendances
Permet son utilisation dans le module-path
et donc de le déclarer comme dépendance d’un autre module
Permet toujours son utilisation via le classpath
26
Toujours tester dans le classpath et le module path

Migration d’une application
Différentes stratégies :
27
Pas de migration
Migration vers une autre techno
Attente de la prochaine LTS
Migration vers les modules
Avec prise en compte du nouveau modèle de release
Migration sans les modules
Migration incrémentale

Pas de migration
Il y a encore (de rares) applications qui tournent en Java 4/5 (2004)
Attention : plus de mises à jour gratuites du JRE
Pour profiter des évolutions, des nouvelles fonctionnalités
Et surtout plus de mises à jour relatives à la sécurité (cf GDPR)
et/ou la performance
Un peu plus en Java 6 (2006) et beaucoup en Java 7 (2011)
28
Pas de migration = rester en Java 8
Plus de support gratuit d’Oracle à partir de janvier 2019 (grâce à une extension d’Oracle)
Grosses difficultés / impossibilité d’upgrader les dépendances

Migration vers autre techno
Coût de réécriture et de test
surtout pour de grosses applications
Quel est le R.O.I. pour le back end ?
Choix de la techno ?
Php / ROR
.Net
JavaScript / Node.JS
Smalltalk
Scala, Kotlin
….
29

Attente de la prochaine LTS
Stratégie viable
puisque cela laisserait entre 2 et 3 ans pour migrer
Vrai, sans le nouveau modèle de releases
La prochaine version LTS : Java 11 (25 septembre 2018)
Le support public de Java 8 est étendu à janvier 2019
2020 pour un usage personnel
30
http://www.oracle.com/technetwork/java/eol-135779.html

Mises à jour gratuites ou support payant ?
LTS : support (non gratuit) longue durée proposé par Oracle
Selon plusieurs niveaux
Article de Simon Ritter d’Azul System
https://www.azul.com/java-stable-secure-free-choose-two-three/
31
Le nouveau modèle de release remet en cause
Les longues périodes de maj gratuites appliquées jusqu’ici
Entre deux versions de Java (2 à 4 ans) + 1 an d’extension
Période de support gratuit très courte
Uniquement jusqu’à la prochaine feature release (6 mois)
Exemple : plus de support gratuit pour Java 9

Migrer vers les modules
LA solution cible
qui ne repose que sur des modules
32
N’utilise que des modules :
Plateform modules (JRE)
Et named modules (applications et toutes les dépendances)
Ajouter un module-info à chaque jar
Tenir compte de certaines contraintes et difficultés
Souvent compliqué et parfois pas possible directement
Notamment à cause des dépendances (en particulier les transitives)

Migrer sans les modules
Il est possible de n’utiliser que le classpath
Comme avant Java 9
33
Attention :
le JRE est modulaire
Permet une exécution en Java 9,
généralement non sans certaines adaptations
Prendre en compte certaines contraintes

Le JDK est modulaire
L’application peut être modularisée (partiellement ou intégralement)
ou pas
Les dépendances ne sont pas toutes modulaires
34
Certains modules peuvent coopérer avec les jars non modulaires
=> Nécessité de cohabitation entre jars modulaires et non modulaires

Plusieurs fonctionnalités facilitent cette cohabitation :
L’option --illegal-access par défaut à permit
Les options pour assouplir les règles de JPMS
Multi-Release JAR
35
Facilitée par la coexistence du classpath et du module path
=> Migration incrémentale sera généralement la stratégie utilisée

#ApresJava8 36
Des fonctionnalités
pour faciliter
la migration

Classpath et module path
Peuvent être utilisés en simultané
Jars non modulaires et modulaires peuvent être mis dans l’un ou l’autre
Implique des contraintes d’utilisation
37
Classpath Module path
Jar standard Unnamed module Automatic module
Jar modulaire Unnamed module Application named module

Un jar est il modulaire ?
Utiliser l’option --describe-module ou –d de l’outil jar
38
C:java>jar --file monutil-1.1.jar -d
Descripteur de module introuvable. Module automatique dérivé.
monutil automatic
requires java.base mandated
contains com.oxiane.app.util
C:java>jar -d --file com.oxiane.app.main-1.0.jar
com.oxiane.app.main jar:file:///com.oxiane.app.main.jar/!module-info.class
exports com.oxiane.app.main
requires com.oxiane.app.util
requires java.base mandated
contains com.oxiane.app.common

Accès entre modules
39
Unnamed
…
xxx.jar
yyy.jar
zzz.jar
Classpath Module Path JDK
Platform
…
java.base
java.xml java.logging
Automatic
aaa.jar
bbb.jar
ccc.jar
App named
com.www.jar
com.xxx.jar
com.yyy.jar
java.sql
expliciteimplicite
com.zzz.jar

L’option --illegal-access
Solution temporaire qui sera changée dans une future version
La valeur par défaut sera alors deny
40
Autoriser ou non les accès par introspection
par le unnamed module
Fait perdre une partie des bénéfices de JPMS
Mais permet d’ exécuter plus facilement une application en Java 9
permit affiche un warning à chaque premier accès illégal
Ne pas ignorer ces warnings
Valeur par défaut : permit
qui autorise tous les accès

L’option --illegal-access
Autres valeurs possibles :
41
warning :
Warning à chaque accès
debug :
Warning + informations complémentaires
deny :
Interdire tous les accès
Permet d’anticiper sur le futur

Les options pour assouplir JPMS
JPMS est très strict
42
Parfois bien utile (voire nécessaire) dans certains cas,
Mais il ne faut pas abuser de leur utilisation
--add-module ajouter des modules au graphe
--add-reads permettre à un module d’accéder à un autre
--add-exports exporter un package d’un module
--patch-module ajouter des classes à un module
--add-opens : permettre un accès par introspection à un package
5 options (javac et jvm) permettent des assouplissements :
Elles ne modifient pas le module-info

Multi-Release JAR (MR JAR)
Etendre le format jar
pour inclure des versions spécifiques de .class pour d’autres versions de Java
dans un même fichier jar
43
Racine du fichier jar
MaClasse.class
META-INF
MANIFEST.MF
versions
9
MaClasse.class
10
MaClasse.class
Un jar peut contenir plusieurs .class pour chaque version
La version courante à la racine
Les autres versions, dans META-INF/versions/N
Multi-Release: true dans MANIFEST.MF
Support à partir de Java 9

jdeprscan
Nouvel outil de Java 9
Analyse statique des .class pour rechercher les API deprecated
44
On n’y est pas habitué
Il y a des API deprecated depuis Java 1.1
Notamment les API deprecated for removal
Important car elles seront retirées
Dans un futur plus ou proche
jdeprscan xxx-3.0.7.jar
Jar file xxx-3.0.7.jar:
class xx/xxx/XxxxXxx uses deprecated class javax/security/cert/X509Certificate
class xx/xxx/XxxxXxx uses deprecated method java/lang/Object::finalize()V
class xx/xxx/XxxxXxx$1 overrides deprecated method java/lang/Object::finalize()V
class xx/xxx/XxxxXxx uses deprecated class javax/security/cert/CertificateException

#ApresJava8 45
Les difficultés

Les incompatibilités
L’identifiant _ n’est plus valide
Alignement de la structure des répertoires du JDK et JRE
Fonctionnalités de la JVM retirée
Les fichiers rt.jar et tools.jar
Le mécanisme d’extension
Le mécanisme endorsed
46

Les API internes
La plupart des API internes sont encapsulées
et ne sont donc plus accessibles
47
Ces API sont non standard / non supportées
Elles n’auraient jamais dû être utilisées
Certaines sont remplacées
Ex : sun.misc.BASE64Decoder
Certaines sont encore accessibles
En attendant leur remplacement
Ex : sun.misc.Unsafe (partiellement remplacée par Var Handles)

Les API internes
48
Utiliser jdeps avec l’option --jdkinternals
MaClasse.class -> JDK removed internal API
MaClasse -> sun.misc.BASE64Encoder JDK internal API (JDK removed internal API)
JDK Internal API Suggested Replacement
---------------- ---------------------
sun.misc.BASE64Encoder Use java.util.Base64 @since 1.8
Utiliser --illegal-access=deny pour simuler le futur

Les dépendances cycliques
Des jars non modulaires peuvent avoir des dépendances cycliques
Ce n’est pas une bonne pratique
Mais c’est courant dans le classpath
Cela peut donc compliquer la migration
Les modules NE peuvent PAS avoir de dépendances cycliques
A la compilation ou à l’exécution
49

Split packages
Packages présents dans plusieurs jars
Pour des raisons de compatibilité :
les split packages sont autorisés dans l’unnamed module
Java 9 interdit les split packages
Pour assurer la fiabilité de la configuration
50
S’applique pour les packages
des modules exportés ou NON
Courant dans le classpath

La version est parfois utilisée pour de mauvaises raisons
Nouveau format de version
Solution :
Utiliser l’API Runtime.Version
Utiliser MR JAR
Le format de version change de nouveau en Java 10
Rechercher du code qui parse le numéro de version
Pas évident car aucune API standard
Le format de la version de Java 9 change

Les modules Java EE
Les modules Java EE ne sont pas résolus par défaut
JAX-B, JAX-WS, JavaBeans Activation Framework, JTA, Commons annotations, CORBA
• java.activation (JAF)
• java.corba (CORBA)
• java.transaction (JTA)
• java.xml.bind (JAX-B)
• java.xml.ws (JAX-WS et SAAJ)
• java.xml.ws.annotation (Commons annotations)
Le module java.se.ee regroupe ces 6 modules
Plus 2 modules du JDK
• jdk.xml.ws (outils pour JAX-WS : wsgen, wsimport)
• jdk.xml.bind (outils pour JAXB : xjc, schemagen)
52
Ils sont deprecated for removal en Java 9

Les modules Java EE
53
Ou de préférence, utiliser une tierce dépendance
Utiliser l’option --add-modules <module>(,<module>)*
JAF Automatic-Module-Name: java.activation
<groupId>javax.activation</groupId>
<artifactId>javax.activation-api</artifactId>
<version>1.2.0</version>
JTA
<groupId>javax.transaction</groupId>
<artifactId>javax.transaction-api</artifactId>
<version>1.3</version>
JAXB nom du module java.xml.bind
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
JAX-WS
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-ri</artifactId>
<type>pom</type>
CORBA
???
Seule solution à partir de Java 11
La JEP 320 (Remove the Java EE and CORBA Modules) est intégrée
Common annotations Automatic-Module-Name:
java.annotation
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>

Les dépendances optionnelles
Dépendances utilisées à l’exécution uniquement si présente
Exemple : une implémentation d’un cache
Solution 2 :
Utiliser un service pour découpler consommateur et fournisseur
Fournisseur :
provides xxx with yyy dans le module-info
Consommateur :
uses xxx dans le module-info
Utiliser l’API ServiceLoader pour charger la classe
Solution 1 :
requires static dans le module-info
Utiliser l’introspection pour créer des instances de manière défensive
54

Java 10
Java 10 repose sur Java 9
Avec des corrections et évolutions mineures
12 JEPs :
56
286: Local-Variable Type Inference
304: Garbage-Collector Interface
307: Parallel Full GC for G1
310: Application Class-Data Sharing
312: Thread-Local Handshakes
319: Root Certificates
296: Consolidate the JDK Forest into a Single Repository
313: Remove the Native-Header Generation Tool (javah)
314: Additional Unicode Language-Tag Extensions
316: Heap Allocation on Alternative Memory Devices
317: Experimental Java-Based JIT Compiler
322: Time-Based Release Versioning
Une release tous les 6 mois -> une release plus petite

L’inférence de type des variables locales
Depuis Java 7, l’inférence de type est de plus en plus utilisée
Avec Java 10 : pour faciliter la déclaration de variables locales
57
var i = 2; // int
var j = 2L; // long
var var = "Bonjour"; // String
var references = new HashMap<Integer,String>(); // HashMap<Integer,String>
var chemin = Paths.get("fichier.txt"); // Path
var contenu = Files.readAllBytes(chemin); // byte[]
var objet = new Serializable() {} ; // MaClasse$1
var est utilisable dans les boucles
for (var i = 0; i < 10; i++) { ... }
for (var arg : args) { ... }
Avec l’instruction var
Qui n’est pas un mot clé

Plusieurs situations sont illicites
58
var valeur; // cannot use 'var' on variable without initializer
var obj = null; // variable initializer is 'null'
var a=1, b=2; // 'var' is not allowed in a compound declaration
// var a=1; var b=2;
var chaines = {"e1","e2"}; // array initializer needs an explicit target-type
// var chaines = new String[] {"e1","e2"};
var additionner = (a,b) -> a+b; // lambda expression needs an explicit target-type
// var additionner = (IntBinaryOperator) (a,b) -> a+b
var comparerStr = String::compareTo; // method reference needs an explicit target-type
// var comparerStr = (Comparator<String>) String::compareTo
var valeur = 10;
valeur = "bonjour"; // incompatible types: String cannot be converted to int
// Java n’est pas Javascript et reste fortement typé
Incompatibilité
jshell> class var {}
| Error:
| 'var' not allowed here
| as of release 10, 'var' is a restricted local variable type and cannot be used for type
declarations

59
Utiliser var avec discernement
le code peut être plus ou moins lisible (surtout sans IDE)
Importance accrue du nom des variables
l’abstraction est limitée : pas d’inférence vers un super type ou une interface
le type inféré est ArrayList<String>
List<String> aurait été préférable
jshell> var liste = new ArrayList<String>();
liste ==> []
jshell> liste.trimToSize()
jshell>
jshell> List<String> liste2 = new ArrayList<>();
liste2 ==> []
jshell> liste2.trimToSize()
| Error:
| cannot find symbol
| symbol: method trimToSize()
| liste2.trimToSize()
| ^---------------^

Mises à jour des API
Optional, OptionalInt, OptionalLong, OptionalDouble
orElseThrow() : alternative à get()
java.util.stream.Collectors
toUnmodifiableList()
toUnmodifiableSet()
toUnmodifiableMap(Function, Function)
toUnmodifiableMap(Function, Function, BinaryOperator)
List, Set, Map
static copyOf(Collection) : copie immuable de la collection
60

Support de Docker
Java 10 : Meilleur support des conteneurs Docker
JDK-8189497 et JDK-8186315, JDK-8179498, JDK-8186248, JDK-8146115
61
Option UseContainerSupport (Linux uniquement)
activée par défaut, -XX:-UseContainerSupport pour désactiver
Extraction d’informations du conteneur (cgroup)
nombre de CPU alloué au conteneur
mémoire allouée au conteneur
Détection de l’exécution dans un conteneur

Support de Docker
Java 8u131 et Java 9
-XX:+UnlockExperimentalVMOptions (Linux uniquement)
-XX:+UseCGroupMemoryLimitForHeap (Linux uniquement)
-XX:InitialRAMFraction, -XX:MaxRAMFraction, -XX:MinRAMFraction (1, ½, 1/3, ¼, …)
Java 10 :
62
Ajout de :
-XX:InitialRAMPercentage=n
-XX:MaxRAMPercentage=n
-XX:MinRAMPercentage=n
-XX:ActiveProcessorCount=n
-Xlog:os+container
Deprecated
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction
-XX:InitialRAMFraction
-XX:MaxRAMFraction
Options pour le contrôle de la mémoire

Fonctionnalités retirées
L’outil javah
utiliser javac –h pour générer des headers natifs
-Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads et –Xusealtsigs
Options de la JVM
63
L’outil policytool
C:java>java -d32 MonApp
Unrecognized option: -d32
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
–d32 et –d64

Conclusion
Java évolue, nous devons (devrons) suivre
65
JDK 9 migration guide fourni par Oracle
http://docs.oracle.com/javase/9/migrate
Mais elle peut se faire avec plusieurs stratégies
Dont certaines étapes peuvent être anticipées
La migration vers les modules sera obligatoire
tôt ou tard
Téléchargez Java 10 et essayez
Elle va être délicate et longue
en tout cas plus longue et délicate que pour les précédentes versions

Apres java 8, java 9 et 10 - BreizhCamp 2018

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Apres java 8, java 9 et 10 - BreizhCamp 2018

Similaire à Apres java 8, java 9 et 10 - BreizhCamp 2018 (20)

Plus de Jean-Michel Doudoux

Plus de Jean-Michel Doudoux (7)

Apres java 8, java 9 et 10 - BreizhCamp 2018