Téléchargé 25 fois
![#ApresJava9#ApresJava9 #voxxeddaysLU22
Depuis Java 7, l’inférence de type est de plus en plus utilisée
L’inférence de type des variables locales
Avec Java 10 : pour faciliter la déclaration de variables locales
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 et try with resources
for (var i = 0; i < 10; i++) { ... }
for (var arg : args) { ... }
try (var file = new FileInputStream(new File("monfichier.txt"))) { ... }
Avec l’instruction var
Qui n’est pas un mot clé](https://image.slidesharecdn.com/voxxeddayslux2018apresjava8java9et10-180626225421/75/Voxxeddays-lux-2018-apres-java-8-java-9-et-10-22-2048.jpg)
![#ApresJava9#ApresJava9 #voxxeddaysLU23
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>) 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](https://image.slidesharecdn.com/voxxeddayslux2018apresjava8java9et10-180626225421/75/Voxxeddays-lux-2018-apres-java-8-java-9-et-10-23-2048.jpg)
![#ApresJava9#ApresJava9 #voxxeddaysLU24
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
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()
| ^---------------^](https://image.slidesharecdn.com/voxxeddayslux2018apresjava8java9et10-180626225421/75/Voxxeddays-lux-2018-apres-java-8-java-9-et-10-24-2048.jpg)
Téléchargé parJean-Michel Doudoux
Voxxeddays lux 2018 apres java 8, java 9 et 10
Ce document présente un état des lieux des évolutions des versions de Java 9 et 10 après Java 8, mettant en avant leurs nouvelles fonctionnalités, la structure des modules, et les améliorations de performance. Il aborde également les stratégies de migration vers ces versions et les défis associés, notamment la nécessité de modulariser le code existant. Enfin, le document souligne l'importance de choisir une version LTS pour le support à long terme.
Contenu connexe
Similaire à Voxxeddays lux 2018 apres java 8, java 9 et 10
Voxxeddays lux 2018 apres java 8, java 9 et 10
- 1. #voxxeddaysLU#ApresJava9 1 Après Java8, Java 9 et 10
- 2. #ApresJava9#ApresJava9 #voxxeddaysLU2 Java 8 Lesexpressions 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 CompletableFuture Optional Permgen -> Metaspace …
- 3. #ApresJava9#ApresJava9 #voxxeddaysLU3 Made Javagreat again ? Java 8 TIOBE : langage de l’année en 2005 et en 2015 Un engouement certain constaté par la popularité de Java 8 Diffusé en mars 2014
- 4. #ApresJava9#ApresJava9 #voxxeddaysLU4 Sûrement laversion la plus controversée Java 9 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é
- 5. #ApresJava9#ApresJava9 #voxxeddaysLU5 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 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
- 6. #ApresJava9#ApresJava9 #voxxeddaysLU6 Nouveau modèlede releases LTS : le nouveau modèle de support (Oracle JDK) Version tous les 3 ans à partir de Java 11 Pour les clients 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 Java 9 n’est pas LTS Ni Java 10
- 7. #ApresJava9#ApresJava9 #voxxeddaysLU7 Java 10 12JEPs 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 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
- 8. #ApresJava9#ApresJava9 #voxxeddaysLU8 Jean-Michel Doudoux http://www.jmdoudoux.fr @jmdoudoux Co-fondateurdu , 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
- 9. #ApresJava9#ApresJava9 #voxxeddaysLU9 • Lesa 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 Roadmap
- 10. #ApresJava8 #voxxeddaysLU10 Les apriori sur Java 9
- 11. #ApresJava9#ApresJava9 #voxxeddaysLU11 Le classpathest remplacé par le module-path Mythes et réalités 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
- 12.
- 13. #ApresJava9#ApresJava9 #voxxeddaysLU13 Méthodes privatedans les interfaces Améliorations de la syntaxe Opérateur diamant dans les classes anonymes internes Variables effectivement finales dans try with resources @SafeVarags sur les méthodes d’instances private
- 14. #ApresJava9#ApresJava9 #voxxeddaysLU14 Fabriques pourcollection immuable API et outils JShell : un outil de type REPL Process API Flow API (Reactive Stream) Var Handles JavaDoc en HTML 5 avec recherche Enrichissement de CompletableFuture
- 15. #ApresJava9#ApresJava9 #voxxeddaysLU15 Globalement demeilleures performances Améliorations de la JVM Segmented code Cache G1 comme GC par défaut Concaténation des chaînes avec InvokeDynamic Compact String Unified JVM Logging Unified GC Logging
- 16. #ApresJava9#ApresJava9 #voxxeddaysLU16 Sont perçuscomme contraignants Les modules 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 … moins de liberté utilisée pendant plus de 20 ans parfois avec abus Tous les systèmes de modules sont contraignants
- 17. #ApresJava9#ApresJava9 #voxxeddaysLU17 Les modules Maison 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) Une configuration fiable Réduire les problèmes du classpath hell L’encapsulation forte Améliorer la sécurité et la maintenabilité
- 18. #ApresJava9#ApresJava9 #voxxeddaysLU18 4 typesde modules 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
- 19. #ApresJava9#ApresJava9 #voxxeddaysLU19 Outil jlink(Java Linker) Pour créer un JRE personnalisé Ne contenant que le nécessaire pour l’exécution d’une application Runtime personnalisé 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
- 20.
- 21. #ApresJava9#ApresJava9 #voxxeddaysLU21 Java 10repose sur Java 9 Java 10 Avec des corrections et évolutions mineures 12 JEPs : 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
- 22. #ApresJava9#ApresJava9 #voxxeddaysLU22 Depuis Java7, l’inférence de type est de plus en plus utilisée L’inférence de type des variables locales Avec Java 10 : pour faciliter la déclaration de variables locales 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 et try with resources for (var i = 0; i < 10; i++) { ... } for (var arg : args) { ... } try (var file = new FileInputStream(new File("monfichier.txt"))) { ... } Avec l’instruction var Qui n’est pas un mot clé
- 23. #ApresJava9#ApresJava9 #voxxeddaysLU23 L’inférence detype 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>) 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
- 24. #ApresJava9#ApresJava9 #voxxeddaysLU24 L’inférence detype 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 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() | ^---------------^
- 25. #ApresJava9#ApresJava9 #voxxeddaysLU25 Optional, OptionalInt,OptionalLong, OptionalDouble orElseThrow() : alternative à get() Mises à jour des API java.util.stream.Collectors toUnmodifiableList() toUnmodifiableSet() toUnmodifiableMap(Function, Function) toUnmodifiableMap(Function, Function, BinaryOperator) List, Set, Map static copyOf(Collection) : copie immuable de la collection
- 26. #ApresJava9#ApresJava9 #voxxeddaysLU26 Support deDocker 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 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
- 27. #ApresJava9#ApresJava9 #voxxeddaysLU27 Java 8u131et Java 9 -XX:+UnlockExperimentalVMOptions (Linux uniquement) -XX:+UseCGroupMemoryLimitForHeap (Linux uniquement) -XX:InitialRAMFraction, -XX:MaxRAMFraction, -XX:MinRAMFraction (1, ½, 1/3, ¼, …) Support de Docker Java 10 : 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
- 28. #ApresJava8 #voxxeddaysLU28 Faire unétat des lieux
- 29. #ApresJava9#ApresJava9 #voxxeddaysLU29 L’outil javah utiliserjavac –h pour générer des headers natifs Fonctionnalités retirées -Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads et –Xusealtsigs Options de la JVM 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
- 30. #ApresJava9#ApresJava9 #voxxeddaysLU30 Recenser lesdifférents points à prendre en compte Utilité 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 Utiliser l’outil jdeps pour obtenir des informations
- 31. #ApresJava9#ApresJava9 #voxxeddaysLU31 Fournit dansle JDK depuis Java 8, amélioré en Java 9 jdeps Analyse statique du bytecode pour déterminer les dépendances Travaille sur les .class ou .jar 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
- 32. #ApresJava9#ApresJava9 #voxxeddaysLU32 jdeps Dépendances agrégéesau 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>
- 33. #ApresJava9#ApresJava9 #voxxeddaysLU33 Nombreuses options: -h pour l’intégralité Les options de jdeps 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
- 34.
- 35. #ApresJava9#ApresJava9 #voxxeddaysLU35 Deux stratégies: Migrer une bibliothèque 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 Toujours tester dans le classpath et le module path
- 36. #ApresJava9#ApresJava9 #voxxeddaysLU36 Différentes stratégies: Migration d’une application 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
- 37. #ApresJava9#ApresJava9 #voxxeddaysLU37 Il ya encore (de rares) applications qui tournent en Java 4/5 (2004) Pas de migration 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 GDPR) et/ou la performance 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) Grosses difficultés / impossibilité d’upgrader les dépendances
- 38. #ApresJava9#ApresJava9 #voxxeddaysLU38 Coût deréécriture et de test surtout pour de grosses applications Migration vers autre techno Quel est le R.O.I. pour le back end ? Choix de la techno ? Php / ROR .Net JavaScript / Node.JS Scala, Kotlin ….
- 39. #ApresJava9#ApresJava9 #voxxeddaysLU39 Stratégie viable puisquecela laisserait entre 2 et 3 ans pour migrer Attente de la prochaine LTS 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
- 40. #ApresJava9#ApresJava9 #voxxeddaysLU40 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/ 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
- 41. #ApresJava9#ApresJava9 #voxxeddaysLU41 LA solutioncible qui ne repose que sur des modules Migrer vers les 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)
- 42. #ApresJava9#ApresJava9 #voxxeddaysLU42 Il estpossible de n’utiliser que le classpath Comme avant Java 9 Migrer sans les modules Attention : le JRE est modulaire Permet une exécution en Java 9, généralement non sans certaines adaptations Prendre en compte certaines contraintes
- 43. #ApresJava9#ApresJava9 #voxxeddaysLU43 Le JDKest modulaire L’application peut être modularisée (partiellement ou intégralement) ou pas Les dépendances ne sont pas toutes modulaires Migration incrémentale Certains modules peuvent coopérer avec les jars non modulaires => Nécessité de cohabitation entre jars modulaires et non modulaires
- 44. #ApresJava9#ApresJava9 #voxxeddaysLU44 Migration incrémentale Plusieursfonctionnalités facilitent cette cohabitation : L’option --illegal-access par défaut à permit Les options pour assouplir les règles de JPMS Multi-Release JAR Facilitée par la coexistence du classpath et du module path => Migration incrémentale sera généralement la stratégie utilisée
- 45. #ApresJava8 #voxxeddaysLU45 Des fonctionnalités pourfaciliter la migration
- 46. #ApresJava9#ApresJava9 #voxxeddaysLU46 Peuvent êtreutilisés en simultané Jars non modulaires et modulaires peuvent être mis dans l’un ou l’autre Classpath et module path Implique des contraintes d’utilisation Classpath Module path Jar standard Unnamed module Automatic module Jar modulaire Application named module
- 47. #ApresJava9#ApresJava9 #voxxeddaysLU47 Utiliser l’option--describe-module ou –d de l’outil jar Un jar est il modulaire ? 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
- 48. #ApresJava9#ApresJava9 #voxxeddaysLU48 Accès entremodules 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
- 49. #ApresJava9#ApresJava9 #voxxeddaysLU49 L’option --illegal-access Solutiontemporaire qui sera changée dans une future version La valeur par défaut sera alors deny 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
- 50. #ApresJava9#ApresJava9 #voxxeddaysLU50 Autres valeurspossibles : L’option --illegal-access warning : Warning à chaque accès debug : Warning + informations complémentaires deny : Interdire tous les accès Permet d’anticiper sur le futur
- 51. #ApresJava9#ApresJava9 #voxxeddaysLU51 JPMS esttrès strict Les options pour assouplir JPMS 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
- 52. #ApresJava9#ApresJava9 #voxxeddaysLU52 Etendre leformat jar pour inclure des versions spécifiques de .class pour d’autres versions de Java dans un même fichier jar Multi-Release JAR (MR JAR) Racine du fichier jar MaClasse.class META-INF MANIFEST.MF versions 9 MaClasse.class 10 MaClasse.class Un jar peut contenir plusieurs .class pour différentes versions La version courante à la racine Les autres versions (>=9), dans META-INF/versions/N Multi-Release: true dans MANIFEST.MF Support à partir de Java 9
- 53. #ApresJava9#ApresJava9 #voxxeddaysLU53 Nouvel outilde Java 9 Analyse statique des .class pour rechercher les API deprecated jdeprscan 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 moins 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
- 54.
- 55. #ApresJava9#ApresJava9 #voxxeddaysLU55 L’identifiant _n’est plus valide Les incompatibilités 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
- 56. #ApresJava9#ApresJava9 #voxxeddaysLU56 La plupartdes API internes sont encapsulées et ne sont donc plus accessibles Les API internes 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)
- 57. #ApresJava9#ApresJava9 #voxxeddaysLU57 Les APIinternes 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
- 58. #ApresJava9#ApresJava9 #voxxeddaysLU58 Des jarsnon modulaires peuvent avoir des dépendances cycliques Ce n’est pas une bonne pratique Mais c’est courant dans le classpath Les dépendances cycliques Cela peut donc compliquer la migration Les modules NE peuvent PAS avoir de dépendances cycliques A la compilation ou à l’exécution
- 59. #ApresJava9#ApresJava9 #voxxeddaysLU59 Packages présentsdans plusieurs jars Split packages 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 S’applique pour les packages dans les modules des modules exportés ou NON Courant dans le classpath
- 60. #ApresJava9#ApresJava9 #voxxeddaysLU La versionest 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
- 61. #ApresJava9#ApresJava9 #voxxeddaysLU61 Les modulesJava EE ne sont pas résolus par défaut JAX-B, JAX-WS, JavaBeans Activation Framework, JTA, Commons annotations, CORBA Les modules Java EE • 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) Ils sont deprecated for removal en Java 9
- 62. #ApresJava9#ApresJava9 #voxxeddaysLU62 Ou depréférence, utiliser une tierce dépendance Les modules Java EE 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> <version>2.3.0</version> JAX-WS <groupId>com.sun.xml.ws</groupId> <artifactId>jaxws-ri</artifactId> <version>2.3.0</version> <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> <version>1.3.1</version>
- 63. #ApresJava9#ApresJava9 #voxxeddaysLU63 Dépendances utiliséesà l’exécution uniquement si présente Exemple : une implémentation d’un cache Les dépendances optionnelles 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
- 64.
- 65. #ApresJava9#ApresJava9 #voxxeddaysLU65 Java évolue,nous devons (devrons) suivre Conclusion 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 JPMS et les modules sera obligatoire tôt ou tard Téléchargez Java 10.0.1 et essayez Elle va être délicate et longue en tout cas plus longue et délicate que pour les précédentes versions
- 66.