Télécharger en tant que PDF, PPTX
![#ApresJava9#ApresJava8
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é](https://image.slidesharecdn.com/breizhcamp2018-apresjava8java9et10-180409180842/85/Apres-java-8-java-9-et-10-BreizhCamp-2018-57-320.jpg)
![#ApresJava9#ApresJava8
L’inférence de type des variables locales
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](https://image.slidesharecdn.com/breizhcamp2018-apresjava8java9et10-180409180842/85/Apres-java-8-java-9-et-10-BreizhCamp-2018-58-320.jpg)
![#ApresJava9#ApresJava8
L’inférence de type des variables locales
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()
| ^---------------^](https://image.slidesharecdn.com/breizhcamp2018-apresjava8java9et10-180409180842/85/Apres-java-8-java-9-et-10-BreizhCamp-2018-59-320.jpg)
Téléchargé parJean-Michel Doudoux
Apres java 8, java 9 et 10 - BreizhCamp 2018
Le document traite des évolutions majeures de Java après la version 8, notamment les changements introduits dans Java 9, 10 et la stratégie de migration vers les modules. Java 9 a suscité de vives controverses en raison de sa rupture avec la compatibilité précédente et a introduit le système de modules, tandis que Java 10 a apporté des évolutions mineures. Il aborde également les défis de la migration, les outils disponibles pour faciliter cette transition, et les ramifications des nouvelles politiques de support des versions Java.
Contenu connexe
Similaire à Apres java 8, java 9 et 10 - BreizhCamp 2018
Apres java 8, java 9 et 10 - BreizhCamp 2018
- 1. #ApresJava8 1 Après Java8, Java 9 et 10
- 2. #ApresJava9#ApresJava8 Java 8 Les expressionslambdas + 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
- 3. #ApresJava9#ApresJava8 Java 8 Made Javagreat 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
- 4. #ApresJava9#ApresJava8 Java 9 Sûrement laversion 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é
- 5. #ApresJava9#ApresJava8 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
- 6. #ApresJava9#ApresJava8 Nouveau plan dereleases 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
- 7. #ApresJava9#ApresJava8 Java 10 12 JEPs 1utile 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
- 8. #ApresJava8 8 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#ApresJava8 Roadmap 9 • Les apriori 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
- 10. #ApresJava8 10 Les apriori sur Java 9
- 11. #ApresJava9#ApresJava8 Mythes et réalités Leclasspath 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
- 12.
- 13. #ApresJava9#ApresJava8 Améliorations de lasyntaxe 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
- 14. #ApresJava9#ApresJava8 API et outils Fabriquespour 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
- 15. #ApresJava9#ApresJava8 Améliorations de laJVM 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
- 16. #ApresJava9#ApresJava8 Les modules Sont perçuscomme 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
- 17. #ApresJava9#ApresJava8 Les modules Mais ondoit 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é
- 18. #ApresJava9#ApresJava8 4 types demodules 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
- 19. #ApresJava9#ApresJava8 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
- 20. #ApresJava8 20 Faire unétat des lieux
- 21. #ApresJava9#ApresJava8 Utilité Recenser les différentspoints à 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
- 22. #ApresJava9#ApresJava8 jdeps Fournit dans leJDK 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
- 23. #ApresJava9#ApresJava8 jdeps 23 Dépendances agrégées auniveau 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>
- 24. #ApresJava9#ApresJava8 Les options dejdeps 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
- 25.
- 26. #ApresJava9#ApresJava8 Migrer une bibliothèque Deuxstraté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
- 27. #ApresJava9#ApresJava8 Migration d’une application Différentesstraté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
- 28. #ApresJava9#ApresJava8 Pas de migration Ily 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
- 29. #ApresJava9#ApresJava8 Migration vers autretechno 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
- 30. #ApresJava9#ApresJava8 Attente de laprochaine 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
- 31. #ApresJava9#ApresJava8 Mises à jourgratuites 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
- 32. #ApresJava9#ApresJava8 Migrer vers lesmodules 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)
- 33. #ApresJava9#ApresJava8 Migrer sans lesmodules 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
- 34. #ApresJava9#ApresJava8 Migration incrémentale Le JDKest 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
- 35. #ApresJava9#ApresJava8 Migration incrémentale Plusieurs fonctionnalitésfacilitent 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
- 36. #ApresJava8 36 Des fonctionnalités pourfaciliter la migration
- 37. #ApresJava9#ApresJava8 Classpath et modulepath 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
- 38. #ApresJava9#ApresJava8 Un jar estil 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
- 39. #ApresJava9#ApresJava8 Accès entre modules 39 Unnamed … xxx.jar yyy.jar zzz.jar ClasspathModule 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
- 40. #ApresJava9#ApresJava8 L’option --illegal-access Solution temporairequi 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
- 41. #ApresJava9#ApresJava8 L’option --illegal-access Autres valeurspossibles : 41 warning : Warning à chaque accès debug : Warning + informations complémentaires deny : Interdire tous les accès Permet d’anticiper sur le futur
- 42. #ApresJava9#ApresJava8 Les options pourassouplir 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
- 43. #ApresJava9#ApresJava8 Multi-Release JAR (MRJAR) 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
- 44. #ApresJava9#ApresJava8 jdeprscan Nouvel outil deJava 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
- 45.
- 46. #ApresJava9#ApresJava8 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
- 47. #ApresJava9#ApresJava8 Les API internes Laplupart 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)
- 48. #ApresJava9#ApresJava8 Les API internes 48 Utiliserjdeps 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
- 49. #ApresJava9#ApresJava8 Les dépendances cycliques Desjars 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
- 50. #ApresJava9#ApresJava8 Split packages Packages présentsdans 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
- 51. #ApresJava9#ApresJava8 La version estparfois 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
- 52. #ApresJava9#ApresJava8 Les modules JavaEE 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
- 53. #ApresJava9#ApresJava8 Les modules JavaEE 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> <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>
- 54. #ApresJava9#ApresJava8 Les dépendances optionnelles Dépendancesutilisé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
- 55.
- 56. #ApresJava9#ApresJava8 Java 10 Java 10repose 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
- 57. #ApresJava9#ApresJava8 L’inférence de typedes 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é
- 58. #ApresJava9#ApresJava8 L’inférence de typedes variables locales 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. #ApresJava9#ApresJava8 L’inférence de typedes variables locales 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() | ^---------------^
- 60. #ApresJava9#ApresJava8 Mises à jourdes 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
- 61. #ApresJava9#ApresJava8 Support de Docker Java10 : 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
- 62. #ApresJava9#ApresJava8 Support de Docker Java8u131 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
- 63. #ApresJava9#ApresJava8 Fonctionnalités retirées L’outil javah utiliserjavac –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
- 64.
- 65. #ApresJava9#ApresJava8 Conclusion Java évolue, nousdevons (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
- 66.