Les versions de Java se suivent et leurs engouements ne se ressemblent pas : la version 8 de Java est probablement celle qui a suscité le plus d’intérêts chez les développeurs. Java 9, au contraire, est la version de Java qui génère le plus de craintes et d’interrogations voir de peurs. Il faut se préparer pour utiliser Java 9 d’autant que Java 10 est déjà là et les versions suivantes vont s’enchaîner. Le but de ce talk est de parcourir les avantages et les intérêts à utiliser ces nouvelles versions mais aussi certaines difficultés possibles lors de la migration.
Formation Gratuite Total Tests par les experts Java Ippon Ippon
Garantissez la qualité des vos applications par des tests efficaces : unitaire, d'intégration, de performance... Apprenez à mettre en oeuvre un harnais de tests complet et efficace avec Junit, AssertJ, Mockito, Spring Test, Arquillian, ... et assimilez les concepts du TDD et du BDD, illustré avec Cucumber. La formation Total Test Training ira encore plus loin en vous présentant l'utilisation de Sonar et le rôle des tests dans un système d'intégration continue. Enfin, les aspects liés à la mesure de la performance (instrumentation avec Metric et stress test avec JMeter et Gatling) et à l'optimisation ciblée vous permettront d'être en mesure de produire un code "propre", protégé des risques de regressions.
Formation Spring Avancé gratuite par Ippon 2014Ippon
Spring est le principal framework de développement Java utilisé en entreprise. Ce succès tient au fait qu'il permet de développer facilement et rapidement des applications robustes, légères et bien testées.
Apprécié également par les cellules d'architecture et les DSI, Spring permet d'avoir des applications bien découpées en couches, facilement maintenables et évolutives.
Cependant, si une configuration Spring simple est à la portée de tous, avoir une architecture Spring correcte, en comprendre le fonctionnement interne et connaître les fonctionnalités avancées du framework sont des tâches nettement plus ardues.
L'objectif de cette formation est de donner les bonnes bases pour comprendre les principaux aspects de Spring, de manière à ce que les participants soient capables de :
- Développer une application Spring complète (persistance, métier, validation, transactions, sécurité, Web, Ajax...).
- Comprendre le fonctionnement interne de Spring et donc être autonomes lorsqu'un bug ou une situation anormale se produit.
- Avoir intégré la philosophie de développement Spring, afin de pouvoir facilement prendre en main un sous-projet ou une fonctionnalité Spring qu'ils ne connaissent pas encore.
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et MobileIppon
Présentation donnée par Julien Dubois lors de Devoxx France 2012, présentant comment réaliser une application moderne avec les technologies HTML5, Spring, NoSQL (Cassandra) et mobiles.
Formation JPA Avancé / Hibernate gratuite par Ippon 2014Ippon
Les ORM, c’est pratique. Mais cela peut rapidement devenir complexe ou subtile. JPA permet de rapidement modéliser la couche d’accès aux données avec une facilité indiscutable. Cependant, il est préférable de bien en comprendre le fonctionnement pour éviter quelques anti patterns fâcheux.
La formation JPA Avancé proposée par Ippon détaille les aspects techniques et permet d’aller plus loin dans la compréhension et la maîtrise. Enrichie par des TP très fournis lorsqu’elle est dispensée par les formateurs Ippon, elle permet d’assimiler en 3 jours les subtilités et offre les outils pour réaliser une couche d’accès aux données de qualité, performante et maintenable.
Techniques de modélisation, gestion et subtilités du cache (L1, L2), mécanismes transactionnels, langage de requêtage… Tous ces aspects et bien d’autres sont détaillés et illustrés afin de vous apporter les clefs pour vos prochains projets.
Découvrez dès aujourd’hui les slides de cette formation, mis à disposition dans le cadre de l’OpenFormation.
Au sein d’une démarche DevOps, le build et le déploiement continue sont les premiers piliers à mettre en place.
Cette session avancé de notre NighClazz “Build Tools & Continuous Delivery” a pour objectif de présenter les modes de déploiement "Blue-Green Deployment" et "Feature toggle" ainsi que les principes d'automatisation des schémas de base de données.
Depuis quelques années Git s'est imposé comme le système de gestion de sources de référence. Simple, rapide , souple, il convient à la fois aux workflows traditionnels et aux workflows distribués. Après une introductions aux principes fondateurs de Git le stagiaire aura l'occasion d'apprendre à créer son premier repository git et à le manipuler localement avant de le partager avec les autres. La formation insistera sur la gestions des branches et la résolution des conflits et sur les commandes permettant d'aborder ces problématiques sereinement. A l'issue de cette formation le stagiaire sera autonome pour utiliser Git aussi bien individuellement qu'au sein d'une équipe.
Cette présentation montre plusieurs outils gratuits qui peuvent être utilisés pour gérer plusieurs aspects de la gestion de projets, en particulier informatique, de manière collaborative. On y voit comment versioner son code avec Git, déployer son code avec Heroku, tester son code avec Travis, gérer et planifier son temps et ses tâches avec Trello, FreedCamp et Tom'splanner, comment communiquer avec Slack et comment rédiger sa documentation avec Read the Docs.
Web API & Cache, the HTTP way - Ippevent 10 Juin 2014Ippon
Chacun connait les fondamentaux pour développer une API Web, mais quand il s’agit de performance, de capacité, de montée en charge, avez vous toutes les clefs pour mettre en oeuvre un cache efficace ?
Le protocole HTTP dispose d’un mécanisme de cache adapté aux architectures distribuées, découvrez ou redécouvrez-le dans cette session et tirez-en profit dans vos API.
Le speaker : David développeur, architecte Java EE et directeur du Pôle Conseil d’Ippon Technologies. Passionné de nouvelles technologies, il s’intéresse aux architectures Java alliant simplicité et efficacité, aptes à répondre aux problèmes concrets. Il est aussi un supporter des API Web et du style d’architecture REST.
2018.11.15 Lyon JUG Maven 3&5 et java 9Hervé Boutemy
Maven et Java 9
Maintenant que Java 9 est sorti, on va pouvoir ajouter des descripteurs de modules dans tous nos projets, n'est-ce pas?
Pas si sûr...
Les modules Java 9 sont très puissants, mais sans maîtrise, ils risquent de tout casser non seulement au niveau de vos programmes Java mais aussi au niveau de l'écosystème Maven.
Avez vous déjà réfléchi au nom de module de votre jar ? Un conseil d'ami : ne vous contentez pas du nom par défaut.
Cette session vous donnera de nombreux conseils pratiques qui ne sont pas directement dans la spécification, mais qui doivent absolument être gardés en tête au fil de l'adoption générale du système de modules Java.
Maven 3 & 5
Ca fait bien longtemps que Maven 3 est sorti. Depuis, il n'y a que des releases mineures : plus rien de bouge ? C'est mort ? Même pour Java 9, il n'y a pas eu besoin de release Maven !
Je vous rassure, Maven continue d'évoluer : simplement, il le fait sans bruit inutile et en vous garantissant une évolution à votre rythme.
Pourtant, une évolution majeure va être nécessaire, qui méritera une nouvelle version : Maven 5.
Pourquoi pas 4 ? Quelle est cette évolution ? Et comment l'équipe Maven va t'elle faire pour conserver la stabilité à laquelle on était habitués, malgré ce grand changement ?
Bonus : Java 9, 10, 11, le nouveau rythme de release et les questions de licence
Beaucoup d’applications utilisent encore Java 8 mais Java a beaucoup évolué depuis notamment avec la diffusion de deux versions LTS.
L’objectif de ce talk est de revenir sur certaines de ces nombreuses évolutions de Java, notamment récentes afin d’en profiter dans nos applications. Au-delà des évolutions syntaxiques et dans les API, ce sera aussi l’occasion de justifier la migration vers des versions plus récentes de Java.
Au cours des 10 précédentes années, nous avons eu des sessions de Devoxx FR et plusieurs versions dont certaines majeures de Java.
L’objectif de ce talk est de revenir rétrospectivement sur certaines annonces et sur certaines des nombreuses évolutions de Java, notamment récentes afin d’en profiter dans nos applications. Au-delà des évolutions syntaxiques et dans les API, ce sera aussi l’occasion de justifier la migration vers des versions plus récentes de Java.
Présentation réalisée au CIGREF pour éclairer le sujet de l'évolution de l'écosystème JAVA suite au changement de licence et de modèle économique d'Oracle sur l'exploitation en production du JDK
Ce chapitre est destiné pour les étudiants de la 2ème année année master Mathématiques, Cryptologie et Sécurité Informatique (MMCSI) Semestre 3. Il traite les concepts de base du langage Java.
Java 9 arrive et avec lui son mécanisme de modularisation Jigsaw. Notre manière de concevoir et livrer nos applications va évoluer de même que les outils que nous utilisons. Cette évolution n’aura pas les mêmes enjeux et contraintes en fonction du type de développement ciblé: une application serveur ou bien une application cliente. Une sensibilisation aux nouveautés de Java 9 ainsi qu’une application utilisant JavaFX seront réalisés au cours de cette présentation. Ces dernières permettront de mettre en lumière les impacts de Java 9 sur les phases de développement, de construction et de livraison d’une application cliente de même que nos pratiques au quotidien.
MarsJUG - Le classpath n'est pas mort, mais presqueAlexis Hassler
En 2009, la mort du classpath a été annoncée. Les classloaders à plat ou hiérarchiques devaient être remplacés par des systèmes modulaires et tous nos problèmes de dépendances devaient se résoudre d'eux-même. Quatre ans plus tard, le classpath vit toujours et pour quelques années encore.
Dans la première partie de cette session, nous reviendrons sur le fonctionnement des classloaders du JDK et les problèmes infernaux posés par le classpath. Nous verrons aussi comment les serveurs d'applications, comme Tomcat, gèrent leur classloaders de façon hiérarchique, afin d'isoler les applications entre elles.
Dans la deuxième partie, nous parlerons de modularité et de son impact sur la gestion des dépendances, à l'exécution des applications. Des solutions existent déjà, comme OSGi et Jigsaw, d'autres émergent, comme JBoss Modules. Nous vous montrerons comment ce dernier fonctionne, dans JBoss AS 7, en autonome, ou même dans Tomcat.
Avec Java 8, publier en 2014, Java a fait une révolution puisque aucune autre version n’aura apporté autant de nouveautés et d’avancées fonctionnelles permet une écriture du code grandement facilitée et des performances nettement améliorées.
Les applications, notamment de gestion, manipulent beaucoup de chaînes de caractères.
Le compilateur et la JVM ont aussi amélioré les performances des traitments des chaînes de caractères
La syntaxe et les API ont beaucoup évolué pour faciliter la vie des développeurs
Cette présentation est l'occasion de faire un tour complet de l'utilisation et de la manipulation de chaînes de caractères en Java.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 22 du JDK issues des projets d’OpenJDK :
- Amber : String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
Mais aussi des fonctionnalités dans les API de Java Core et dans la JVM HotSpot qui ne font pas l'objet de JEP.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 22 du JDK issues des projets d’OpenJDK :
- Amber : String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
Mais aussi des fonctionnalités dans les API de Java Core et dans la JVM HotSpot qui ne font pas l'objet de JEP.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 21 LTS du JDK issues des projets d’OpenJDK :
- Amber : Record Patterns, Pattern Matching for switch, String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Virtual Threads, Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
mais aussi de fonctionnalités dans les API de Java Core qui ne font pas l'objet de JEP et dans la JVM HotSpot.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 21 LTS du JDK issues des projets d’OpenJDK :
- Amber : Record Patterns, Pattern Matching for switch, String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Virtual Threads, Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
mais aussi de fonctionnalités dans les API de Java Core qui ne font pas l'objet de JEP et dans la JVM HotSpot.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 21 LTS du JDK issues des projets d’OpenJDK :
- Amber : Record Patterns, Pattern Matching for switch, String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Virtual Threads, Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
mais aussi de fonctionnalités dans les API de Java Core qui ne font pas l'objet de JEP et dans la JVM HotSpot.
Les nouveautés de Java 21 - Rencontres dev Toulon octobre 2023.pdfJean-Michel Doudoux
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 21 LTS du JDK issues des projets d’OpenJDK :
- Amber : Record Patterns, Pattern Matching for switch, String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Virtual Threads, Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
mais aussi de fonctionnalités dans les API de Java Core qui ne font pas l'objet de JEP et dans la JVM HotSpot.
Cette présentation brosse une revue détaillée des nouveautés qui sont proposées en standard, en preview et en incubation dans la version 21 LTS du JDK issues des projets d’OpenJDK :
- Amber : Record Patterns, Pattern Matching for switch, String Templates, Unnamed Patterns and Variables, Unnamed Classes and Instance Main Methods
- Loom : Virtual Threads, Structured Concurrency, Scoped Values
- et Panama : Foreign Function & Memory API, Vector API
mais aussi de fonctionnalités dans les API de Java Core qui ne font pas l'objet de JEP et dans la JVM HotSpot.
Les versions 19 et 20 de Java, publiées en septembre et mars derniers, sont les 10eme et 11eme release en application du modèle de release tous les 6 mois.
En attendant la publication de Java 21, la prochaine version LTS publiée en septembre de cette année, et pour en donner quelques aperçus, cette présentation brosse une revue détaillée des nouveautés introduites dans ces nouvelles versions de Java, issues des projets Amber, Panama et Loom d’OpenJDK ainsi que des fonctionnalités non incluses dans des JEPs.
En attendant la publication de Java 21, la prochaine version diffusée en septembre de cette année, et pour en donner quelques aperçus, cette présentation brosse une revue détaillée des nouveautés qui devraient être proposées dans cette future version LTS de Java, issues des projets Amber, Loom et Panama d’OpenJDK.
Les versions 19 et 20 de Java, publiées en septembre et mars derniers, sont les 10eme et 11eme release en application du modèle de release tous les 6 mois.
En attendant la publication de Java 21, la prochaine version LTS publiée en septembre de cette année, et pour en donner quelques aperçus, cette présentation brosse une revue détaillée des nouveautés introduites dans ces nouvelles versions non-LTS de Java, issues des projets Amber, Panama et Loom d’OpenJDK ainsi que des fonctionnalités non incluses dans des JEPs.
Voxxeddays Lux 2022 - Profiling et monitoring avec le JDKJean-Michel Doudoux
Java Flight Recorder (JFR) est une fonctionnalité de la JVM qui après activation enregistre des événements émis par son activité mais aussi celle de l’application et même du système d’exploitation avec un très faible overhead. Il est possible d’émettre ses propres événements et même de consommer des événements grâce à une API de Java 14. Depuis Java 11, JFR est open source et il est donc utilisable maintenant en production sans licence commerciale. L’exploitation de ces événements avec l’outil JMC peut être particulièrement appréciable lors d’activité de profiling et de monitoring. Cette session sera l’occasion de faire un tour d’horizon de ces fonctionnalités qui peuvent s’avérer utiles pour certaines problématiques.
Java SE 8 est sûrement la version la plus importante et la plus impactante pour les développeurs. Deux ans après sa sortie, ce talk propose des retours sur les bonnes ou moins bonnes utilisations des principales fonctionnalités de Java 8. Une connaissance de ces fonctionnalités est requise.
2. #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
3. #ApresJava9#ApresJava8
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
4. #ApresJava9#ApresJava8
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é
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 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
7. #ApresJava9#ApresJava8
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
9. #ApresJava9#ApresJava8
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
11. #ApresJava9#ApresJava8
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
13. #ApresJava9#ApresJava8
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
14. #ApresJava9#ApresJava8
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
15. #ApresJava9#ApresJava8
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
16. #ApresJava9#ApresJava8
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
17. #ApresJava9#ApresJava8
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é
18. #ApresJava9#ApresJava8
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
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
21. #ApresJava9#ApresJava8
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
22. #ApresJava9#ApresJava8
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
23. #ApresJava9#ApresJava8
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>
24. #ApresJava9#ApresJava8
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
26. #ApresJava9#ApresJava8
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
27. #ApresJava9#ApresJava8
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
28. #ApresJava9#ApresJava8
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
29. #ApresJava9#ApresJava8
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
30. #ApresJava9#ApresJava8
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
31. #ApresJava9#ApresJava8
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
32. #ApresJava9#ApresJava8
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)
33. #ApresJava9#ApresJava8
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
34. #ApresJava9#ApresJava8
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
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é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
37. #ApresJava9#ApresJava8
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
38. #ApresJava9#ApresJava8
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
40. #ApresJava9#ApresJava8
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
42. #ApresJava9#ApresJava8
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
43. #ApresJava9#ApresJava8
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
44. #ApresJava9#ApresJava8
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
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
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)
48. #ApresJava9#ApresJava8
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
49. #ApresJava9#ApresJava8
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
50. #ApresJava9#ApresJava8
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
51. #ApresJava9#ApresJava8
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
52. #ApresJava9#ApresJava8
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
53. #ApresJava9#ApresJava8
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>
<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é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
56. #ApresJava9#ApresJava8
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
57. #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é
58. #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
59. #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()
| ^---------------^
60. #ApresJava9#ApresJava8
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
61. #ApresJava9#ApresJava8
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
62. #ApresJava9#ApresJava8
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
63. #ApresJava9#ApresJava8
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
65. #ApresJava9#ApresJava8
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