Après Java 8, Java 9 et 10 - Jean-Michel Doudoux CTO @jmdoudoux - RainFocus

Après Java 8,
 Java 9 et 10            Paris, 3 juillet 2018

   Jean-Michel Doudoux
   CTO
   @jmdoudoux

Java 8
  Les expressions lambdas                   Approche fonctionnelle :
  références de méthodes                    l’API Stream + Collector

                  L’API Date & Time              Optional

CompletableFuture                           Permgen -> Metaspace

            Les interfaces : les méthodes
               statiques et par défaut                      …
       #ApresJava9 #OracleCodeParis
   #ApresJava9                          2

Java 8
Made Java great again ?

Un engouement certain
     constaté par la popularité de Java 8

TIOBE : langage de l’année en 2005 et en 2015

Diffusé en mars 2014

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 3

Java 9
Sûrement la version la plus controversée
Première fois que l’EC du JCP vote Non

Introduit des changements majeurs
     Tout en tentant d’offrir une certaine compatibilité

Diffusé en septembre 2017
     2 updates : 9.0.1, 9.0.4

    #ApresJava9 #OracleCodeParis
#ApresJava9                              4

Java 9 : les fonctionnalités
Le système de modules (JPMS) issu du projet Jigsaw
     Introduit une rupture
     Avec un mode de compatibilité, pour faciliter la migration

+ 89 JEPs                                       Outils
                                                JShell
                                                Jlink pour créer des runtime compacts
                                                Recherche dans la Javadoc en HTML 5
Evolutions mineures dans le langage             Jdeprscan
                                                …
API
 Fabriques pour des collections immuables       JVM
 Process API                                    G1 est le ramasse-miettes par défaut
 Reactive Streams (Flow API)                    Réduction de la taille mémoire (Compact Strings)
 Var Handles
                                                Amélioration de la performance et de la sécurité
 …
                                                Multi-Release Jar
                                                …

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 5

Nouveau modèle de releases
2 releases majeures de Java par an (OpenJDK) :
   en mars et septembre

Les deux releases suivantes après Java 9 :
     Java 10 en mars 2018
     Java 11 en septembre 2018

LTS : le nouveau modèle de support (Oracle JDK)
     Version tous les 3 ans à partir de Java 11
     Pour les clients

Java 9 n’est pas LTS
Ni Java 10

    #ApresJava9 #OracleCodeParis
#ApresJava9                                6

Java 10
6 mois après Java 9, release de Java 10
   Diffusé le 20 mars 2018
2 conséquences :

1) Durée de release réduite -> nombre de fonctionnalités réduites
    12 JEPs
       1 utile pour les développeurs
       + évolutions dans les API existantes
2) Java 9 quasiment pas utilisé

   Mais déjà obsolète avec la sortie de Java 10

    #ApresJava9 #OracleCodeParis
#ApresJava9                           7

Jean-Michel Doudoux
                                                          http://www.jmdoudoux.fr
CTO                                et
                                                           @jmdoudoux

Auteur de 2 didacticiels
Diffusés sous licence GNU FDL
• Développons en Java (3400 pages)

• Développons en Java avec Eclipse

Co-fondateur du                             , membre du

    #ApresJava9 #OracleCodeParis
#ApresJava9                             8

Roadmap
 • Les a priori sur Java 9
 • Les avantages de Java 9
 • Java 10
 • 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

    #ApresJava9 #OracleCodeParis
#ApresJava9                           9

Les a priori
                       sur Java 9

#ApresJava9   #OracleCodeParis   10

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

    #ApresJava9 #OracleCodeParis
#ApresJava9                        11

Les avantages
                   de Java 9

#ApresJava9   #OracleCodeParis   12

Améliorations de la syntaxe
 Méthodes private dans les interfaces

 Variables effectivement finales dans try with resources

 Opérateur diamant dans les classes anonymes internes

 @SafeVarags sur les méthodes d’instances private

    #ApresJava9 #OracleCodeParis
#ApresJava9                        13

API et outils
 Fabriques pour collection immuable

 Process API

 Flow API (Reactive Stream)

 Var Handles
 Enrichissement de CompletableFuture

 JavaDoc en HTML 5 avec recherche

 JShell : un outil de type REPL

    #ApresJava9 #OracleCodeParis
#ApresJava9                        14

Améliorations de la JVM
 Globalement de meilleures performances
      Compact String

      Concaténation des chaînes avec InvokeDynamic

      G1 comme GC par défaut

      Segmented code Cache

 Unified JVM Logging

 Unified GC Logging

    #ApresJava9 #OracleCodeParis
#ApresJava9                        15

Les modules
Sont perçus comme contraignants

 moins de liberté
       utilisée pendant plus de 20 ans
       parfois avec abus

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 de dépendances circulaires
      La nécessité de définir les dépendances dans les module-info ET les outils de build
      …

Tous les systèmes de modules sont contraignants

    #ApresJava9 #OracleCodeParis
#ApresJava9                              16

Les modules
 Mais on doit profiter des avantages des modules

 L’encapsulation forte
      Améliorer la sécurité et la maintenabilité

 Une configuration fiable
      Réduire les problèmes du classpath hell

 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)

    #ApresJava9 #OracleCodeParis
#ApresJava9                             17

4 types de modules
  Platform modules                 Modules du JRE

  App Named modules                Jar modulaire dans le module path

  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

  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

    #ApresJava9 #OracleCodeParis
#ApresJava9                          18

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

 Déployer facilement une application
      Sans s’appuyer sur un JRE pré-installé

 Tous les jars doivent être modulaires
      Uniquement des named modules (pas d’automatic modules)
      Incluant TOUTES les dépendances

    #ApresJava9 #OracleCodeParis
#ApresJava9                              19

Java 10

#ApresJava9   #OracleCodeParis      20

Java 10
    Java 10 repose sur Java 9

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

    Avec des corrections et évolutions mineures

       #ApresJava9 #OracleCodeParis
   #ApresJava9                              21

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
 Avec l’instruction var
      Qui n’est pas un mot clé
      var   i = 2;                                      // int
      var   j = 2L;                                     // long
      var   var = "Bonjour";                            // String
      var   references = new HashMap(); // HashMap
      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 et try with resources
      for (var i = 0; i < 10; i++) { ... }
      for (var arg : args) { ... }
      try (var file = new FileInputStream(new File("monfichier.txt"))) { ... }

    #ApresJava9 #OracleCodeParis
#ApresJava9                                  22

L’inférence de type des variables locales

 Plusieurs situations sont illicites
  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::compareTo
  var valeur = 10;
  valeur = "bonjour";                    // incompatible types: String cannot be converted to int
                                         // Java n’est pas Javascript et reste statiquement 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

    #ApresJava9 #OracleCodeParis
#ApresJava9                                   23

L’inférence de type des variables locales

 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
     jshell> var liste = new ArrayList();   jshell> List liste2 = new ArrayList();
     liste ==> []                                   liste2 ==> []

     jshell> liste.trimToSize()                     jshell> liste2.trimToSize()
                                                    | Error:
     jshell>                                        | cannot find symbol
                                                    |    symbol:   method trimToSize()
    le type inféré est ArrayList            | liste2.trimToSize()
                                                    | ^---------------^
    List aurait été préférable

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 24

Mises à jour des API
Optional, OptionalInt, OptionalLong, OptionalDouble
      orElseThrow() : alternative à get()

List, Set, Map
      static copyOf(Collection) : copie immuable de la collection

java.util.stream.Collectors
      toUnmodifiableList()
      toUnmodifiableSet()
      toUnmodifiableMap(Function, Function)
      toUnmodifiableMap(Function, Function, BinaryOperator)

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 25

Support de Docker
 Java 10 : Meilleur support des conteneurs Docker
      JDK-8189497 et JDK-8186315, JDK-8179498, JDK-8186248, JDK-8146115

 Option UseContainerSupport (Linux uniquement)
      activée par défaut, -XX:-UseContainerSupport pour désactiver

      Détection de l’exécution dans un conteneur

      Extraction d’informations du conteneur (cgroup)
          nombre de CPU alloué au conteneur
          mémoire allouée au conteneur

    #ApresJava9 #OracleCodeParis
#ApresJava9                             26

Support de Docker
Options pour le contrôle de la mémoire

Java 8u131 et Java 9
      -XX:+UnlockExperimentalVMOptions (Linux uniquement)
      -XX:+UseCGroupMemoryLimitForHeap (Linux uniquement)
      -XX:InitialRAMFraction, -XX:MaxRAMFraction, -XX:MinRAMFraction (1, ½, 1/3, ¼, …)

Java 10 :

      Deprecated                                         Ajout de :
         -XX:+UseCGroupMemoryLimitForHeap                   -XX:InitialRAMPercentage=n
         -XX:MaxRAMFraction                                 -XX:MaxRAMPercentage=n
         -XX:InitialRAMFraction                             -XX:MinRAMPercentage=n
         -XX:MaxRAMFraction                                 -XX:ActiveProcessorCount=n
                                                            -Xlog:os+container

    #ApresJava9 #OracleCodeParis
#ApresJava9                              27

Faire un état
                      des lieux

#ApresJava9   #OracleCodeParis   28

Fonctionnalités retirées
 L’outil javah
    utiliser javac –h pour générer des headers natifs
 L’outil policytool
 Options de la JVM
      –d32 et –d64
      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.

      -Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads et –Xusealtsigs

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 29

Utilité
Recenser les différents points à prendre en compte

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

Utiliser l’outil jdeps pour obtenir des informations

 Aider à choisir la stratégie de migration

 Avoir une meilleure visibilité sur l’ampleur de la tâche

    #ApresJava9 #OracleCodeParis
#ApresJava9                               30

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

 Pour obtenir de nombreuses informations :
   Des dépendances
   Les split packages
   Les API du JDK qui ne sont plus accessibles

 A passer sur l’application
 mais aussi sur toutes les dépendances

    #ApresJava9 #OracleCodeParis
#ApresJava9                              31

jdeps
 Dépendances agrégées au niveau des packages ou des jars

 Par défaut affiche :
   les modules du JDK requis
   les dépendances de chaque packages
        ->  

 Possibilité de filtrage

 Différents formats de restitution
      dont des fichiers .dot

    #ApresJava9 #OracleCodeParis
#ApresJava9                         32

Les options de jdeps
Nombreuses options : -h pour l’intégralité
  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

  jdeps --class-path 'libs/*' -recursive monapp-3.2.jar

    #ApresJava9 #OracleCodeParis
#ApresJava9                                  33

La migration
                     vers Java 9

#ApresJava9   #OracleCodeParis   34

Migrer une bibliothèque
 Deux stratégies :
 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

 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

Toujours tester dans le classpath et le module path

    #ApresJava9 #OracleCodeParis
#ApresJava9                               35

Migration d’une application
Différentes stratégies :
      Pas de migration
      Migration vers une autre techno
      Attente de la prochaine LTS
      Migration vers les modules
      Migration sans les modules
      Migration incrémentale

Avec prise en compte du nouveau modèle de release

    #ApresJava9 #OracleCodeParis
#ApresJava9                        36

Pas de migration
 Il y a encore (de rares) applications qui tournent en Java 4/5 (2004)

 Un peu plus en Java 6 (2006) et beaucoup en Java 7 (2011)

 Pas de migration = rester en Java 8
      Plus de support gratuit d’Oracle à partir de janvier 2019 (grâce à une extension d’Oracle)

 Attention : plus de mises à jour gratuites du JRE
      Pour profiter des corrections, des nouvelles fonctionnalités dans la JVM
      Et surtout plus de mises à jour relatives à la sécurité (cf RGPD)
           et/ou la performance

 Grosses difficultés / impossibilité d’upgrader les dépendances

    #ApresJava9 #OracleCodeParis
#ApresJava9                                  37

Migration vers autre techno
 Coût de réécriture et de test
   surtout pour de grosses applications

 Choix de la techno ?
   Php / ROR
   .Net
   JavaScript / Node.JS
   Scala, Kotlin
   ….

 Quel est le R.O.I. pour le back end ?

    #ApresJava9 #OracleCodeParis
#ApresJava9                        38

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

 http://www.oracle.com/technetwork/java/eol-135779.html

    #ApresJava9 #OracleCodeParis
#ApresJava9                          39

Mises à jour gratuites ou support payant ?

 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 mises à jour gratuites très courte
     Uniquement jusqu’à la prochaine feature release (6 mois)
     Exemple : plus de support gratuit pour Java 9

 LTS : support longue durée proposé par Oracle
      Pour les clients, selon plusieurs niveaux

     #ApresJava9 #OracleCodeParis
 #ApresJava9                              40

Migrer vers les modules
 LA solution cible
      qui ne repose que sur des modules

 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 impossible directement
       Notamment à cause des dépendances (en particulier les transitives)

    #ApresJava9 #OracleCodeParis
#ApresJava9                               41

Migrer sans les modules
 Il est possible de n’utiliser que le classpath
     Comme avant Java 9

 Permet une exécution en Java 9,
   généralement non sans certaines adaptations

 Attention :
      le JRE est modulaire
      Prendre en compte certaines contraintes

    #ApresJava9 #OracleCodeParis
#ApresJava9                        42

Migration incrémentale
Le JDK est modulaire

L’application peut être modularisée (partiellement ou intégralement)
ou pas

Les dépendances ne sont pas toutes modulaires

=> Nécessité de cohabitation
   entre jars modulaires et non modulaires
      Certains modules peuvent coopérer avec les jars non modulaires

    #ApresJava9 #OracleCodeParis
#ApresJava9                            43

Migration incrémentale
=> Migration incrémentale sera généralement la stratégie utilisée

Facilitée par la coexistence du classpath et du module path

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

    #ApresJava9 #OracleCodeParis
#ApresJava9                             44

Des fonctionnalités
      pour faciliter
       la migration

#ApresJava9   #OracleCodeParis   45

Classpath et module path
Peuvent être utilisés en simultané

Jars non modulaires et modulaires
peuvent être mis dans l’un ou l’autre

                                     Classpath           Module path

    Jar standard                                       Automatic module
                                   Unnamed module
   Jar modulaire                                    Application named module

Implique des contraintes d’utilisation

    #ApresJava9 #OracleCodeParis
#ApresJava9                                46

Un jar est il modulaire ?
Utiliser l’option --describe-module ou –d de l’outil jar

 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

 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

    #ApresJava9 #OracleCodeParis
#ApresJava9                                47

Accès entre modules
Classpath                                Module Path                          JDK
 Unnamed                     Automatic               App named           Platform

   xxx.jar                     aaa.jar               com.www.jar         java.base
   yyy.jar                     bbb.jar               com.xxx.jar
     …
                                                                   java.xml       java.logging
   zzz.jar                     ccc.jar               com.yyy.jar
                                                                              …
                                                     com.zzz.jar

                                                                          java.sql
       implicite                    explicite

     #ApresJava9 #OracleCodeParis
 #ApresJava9                                    48

L’option --illegal-access
Autoriser ou non les accès par introspection
  par le unnamed module

Valeur par défaut : permit
     qui autorise tous les accès

Fait perdre une partie des bénéfices de JPMS
     Mais permet d’ exécuter plus facilement une application en Java 9

Solution temporaire qui sera changée dans une future version
     La valeur par défaut sera alors deny

permit affiche un warning à chaque premier accès illégal
     Ne pas ignorer ces warnings

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 49

L’option --illegal-access
Autres valeurs possibles :

warning :
     Warning à chaque accès

debug :
     Warning + informations complémentaires

deny :
     Interdire tous les accès
     Permet d’anticiper sur le futur

    #ApresJava9 #OracleCodeParis
#ApresJava9                            50

Les options pour assouplir JPMS
 JPMS est très strict
 5 options (javac et jvm) permettent des assouplissements :
    --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

      --add-opens :                permettre un accès par introspection à un package
      --patch-module               ajouter des classes à un module

 Elles ne modifient pas le module-info
 Parfois bien utile (voire nécessaire) dans certains cas,
   Mais il ne faut pas abuser de leur utilisation
    #ApresJava9 #OracleCodeParis
#ApresJava9                             51

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

 Un jar peut contenir plusieurs .class pour différentes versions
      La version courante à la racine
                                                              Racine du fichier jar
      Les autres versions (>=9), dans META-INF/versions/N       MaClasse.class
                                                                META-INF
Multi-Release: true dans MANIFEST.MF                              MANIFEST.MF
                                                                  versions
                                                                    9
 Support à partir de Java 9                                           MaClasse.class
                                                                    10
                                                                      MaClasse.class

    #ApresJava9 #OracleCodeParis
#ApresJava9                               52

jdeprscan
 Nouvel outil de Java 9
      Analyse statique des .class pour rechercher les API deprecated
       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

 Notamment les API deprecated for removal

 Important car elles seront retirées
      Dans un futur plus ou moins proche

 On n’y est pas habitué
      Il y a des API deprecated depuis Java 1.1

    #ApresJava9 #OracleCodeParis
#ApresJava9                                 53

Les difficultés

#ApresJava9   #OracleCodeParis   54

Les incompatibilités
L’identifiant _ n’est plus valide

Fonctionnalités de la JVM retirée
  Les fichiers rt.jar et tools.jar
  Le mécanisme d’extension
  Le mécanisme endorsed

Alignement de la structure des répertoires du JDK et JRE

    #ApresJava9 #OracleCodeParis
#ApresJava9                         55

Les API internes
 La plupart des API internes sont encapsulées
      et ne sont donc plus accessibles

 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)

    #ApresJava9 #OracleCodeParis
#ApresJava9                                56

Les API internes
 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

    #ApresJava9 #OracleCodeParis
#ApresJava9                               57

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

 Les modules NE peuvent PAS avoir de dépendances cycliques
    A la compilation ou à l’exécution

 Cela peut donc compliquer la migration

    #ApresJava9 #OracleCodeParis
#ApresJava9                        58

Split packages
 Packages présents dans plusieurs jars

 Courant dans le classpath

 Java 9 interdit les split packages
      Pour assurer la fiabilité de la configuration

 S’applique pour les packages dans les modules
    des modules exportés ou NON

 Pour des raisons de compatibilité :
      les split packages sont autorisés dans l’unnamed module

    #ApresJava9 #OracleCodeParis
#ApresJava9                                59

Nouveau format de version
La version est parfois utilisée pour de mauvaises raisons

Le format de la version de Java 9 change

Rechercher du code qui parse le numéro de version
      Pas évident car aucune API standard

Le format de version change de nouveau en Java 10

Solution :
   Utiliser l’API Runtime.Version
   Utiliser MR JAR

    #ApresJava9 #OracleCodeParis
#ApresJava9

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

 Ils sont deprecated for removal en Java 9
       •    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)

    #ApresJava9 #OracleCodeParis
#ApresJava9                                    61

Les modules Java EE
     Utiliser l’option --add-modules (,)*
     Ou de préférence, utiliser une tierce dépendance
JAF Automatic-Module-Name: java.activation             JAX-WS
  javax.activation                    com.sun.xml.ws
  javax.activation-api          jaxws-ri
  1.2.0                               2.3.0
                                                         pom
JAXB nom du module java.xml.bind
  javax.xml.bind                    Common annotations Automatic-Module-Name:
  jaxb-api                    java.annotation
  2.3.0                               javax.annotation
                                                         javax.annotation-api
JTA                                                      1.3.1
  javax.transaction
  javax.transaction-api       CORBA
  1.3                               ???

    Seule solution à partir de Java 11
         La JEP 320 (Remove the Java EE and CORBA Modules) est intégrée

       #ApresJava9 #OracleCodeParis
   #ApresJava9                                    62

Les dépendances optionnelles
 Dépendances utilisées à l’exécution uniquement si présente
      Exemple : une implémentation d’un cache

 Solution 1 :
      requires static dans le module-info
      Utiliser l’introspection pour créer des instances de manière défensive

 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

    #ApresJava9 #OracleCodeParis
#ApresJava9                               63

Conclusion

#ApresJava9   #OracleCodeParis   64

Conclusion
 Java évolue, nous devons (devrons) suivre

 La migration vers JPMS et les modules sera obligatoire
      tôt ou tard

 Elle va être délicate et longue
      en tout cas plus longue et délicate que pour les précédentes versions

 Mais elle peut se faire avec plusieurs stratégies
      Dont certaines étapes peuvent être anticipées

 JDK 9 migration guide fourni par Oracle
      http://docs.oracle.com/javase/9/migrate

 Téléchargez Java 10.0.1 et essayez

    #ApresJava9 #OracleCodeParis
#ApresJava9                              65

Merci

#ApresJava9   #OracleCodeParis     66