Après une petite absence en 2018 en raison de la trop forte demande, Sedona était de retour au DEVOXX France 2019, représentée par ses « techos » passionnés de nouvelles technologies. Dans ce blog nous vous ferons quelques résumés des différentes conférences qui nous semble apporter quelque chose dans les mois ou années à venir. Ce n’est évidemment pas exhaustif, mais cela peut donner envie à certains d’approfondir les sujets en fouillant sur le net, car beaucoup de conférence s’y trouve ainsi que des tutoriels et du code exemple.

Jeudi 18 Avril

Modern Java: Change is the Only Constant (Mark Reinhold)

Dans cette conférence, Mark Reinhold est revenu sur les grands changements qui ont été entamés ces deux dernières années sur la JDK.

Ces changements ont été motivés par la volonté d’accélérer le système de release des JDK pour rester compétitif avec  leurs concurrents (qui font des releases tous les 6 mois, là ou Java avait une version tous les 3-5 ans)

Ces changements sont donc :

• Un nouveau découpage des modules, avec une meilleure encapsulation
• La suppression de l’accès aux api interne de la JDK ( sun.* , *.internal.*)
• La suppression de certaines API obsolètes qui n’ont plus de raison d’être maintenant si ce n’est par soucis de rétro-compatibilité.

La rétro-compatibilité n’est donc plus assurée, mais ces changements rendent maintenant la JDK plus facile à maintenir et leur permettent de faire des livraisons tous les 6 mois.

Toujours dans le but d’accélérer la livraison des releases, java ne maintiendra que la version courante. Il y a néanmoins des version LTS (tous les 3 ans), qui elles, seront maintenues au moins jusqu’a la LTS suivante, voire même après.

La dernière LTS  en date et la JDK 11 ( septembre 2018), la prochaine sera la JDK 17 (septembre 2021)

Java laisse donc le choix :

• Se mettre à jour tous les 6 mois pour bénéficier de toutes les dernières nouveautés et correctifs ou bien attendre une LTS pour ne faire ses migrations que tous les X années

Pour finir, Mark Reinhold a présenté quelques nouveautés arrivant dans les prochaines version de java  et en particulier des 2 projets suivants :

Amber  :  Ce projet rajoute de nouveaux mots clé et de nouvelles syntaxe afin d’alléger un peu le code. On y retrouve beaucoup de concept déjà présent dans Kotlin par exemple.

• Le mot-clé var pendant la déclaration d’une variable pour éviter de répéter son type (déjà présent depuis la JDK 10)

Exemple :

• Nouvelle syntaxe pour le switch ( présent dans la JDK  12, en preview )
• Les Raw String avec l’opérateur «  » », permettant d’écrire des chaine de caractères sur plusieurs lignes
• Les record class : Il s’agit de l’équivalent des data class en kotlin : le mot clé record va énormément alléger la syntaxe des classes ne contenant que des données puisque toutes les méthodes basiques (constructeurs, getter, setter, toString,…) vont être automatiquement générées (pas de date prévu pour le moment)

Loom : ce projet va apporter les « Fibers ». Il s’agit de Thread allégés. Un Thread Java est associé a un Thread sur l’OS, alors que les Fibers ne le sont pas. Elle demande beaucoup moins de ressources et sont donc plus performantes.

lien youtube : https://www.youtube.com/watch?v=IvmoxgSatbg

De Java à un exécutable natif : GraalVM et Quarkus changent la donne (Emmanuel Bernard)

De nos jours le sujet des microservices, la scalabilité instantanée et les plates-formes à haute densité comme Kubernetes nécessitent des applications à faible empreinte mémoire et démarrage rapide. Dans ce domaine, Java n’était pas bien positionné car il favorise les temps de traitement aux détriment de la CPU et de la RAM.

A Kubernetes Native Java stack tailored for GraalVM & OpenJDK HotSpot, crafted from the best of breed Java libraries and standards

C’est justement sur ce point qu’entre en scène Quarkus, le framework « buzz word » du moment, une stack Java orientée microservices qui supporte entre autres les Microprofile, Hibernate, Vert.x, Netty, RESTEasy et d’autres sur GraalVM et HotSpot avec une faible empreinte mémoire et un démarrage rapide. Exactement ce qu’il faut pour profiter pleinement de nos architectures containérisées et ainsi offrir une expérience utilisateur optimale avec des temps de scalabilité défiant toute concurrence.

Pour commencer voici ce que dit wikipedia à propos d’un quark :

Un quark est une particule élémentaire et un constituant de la matière observable

Quarkus provient de cette définition dans le sens ou l’on veut obtenir quelque chose de minimal (par la taille, par l’utilisation de ressources, par le temps de démarrage etc…)

On peut voir Quarkus comme un framework de framework. En effet celui-ci ne nous apporte pas de nouveautés en terme de stack de développement mais réutilise des stacks moderne et nous facilite leur utilisation et aussi leur optimisation pour des environnement containérisés.

Approche Container first

• Support de Graal / SubstrateVM
  Possibilité pour application d’être compilée en une image native, elle démarrera beaucoup plus rapidement et pourra s’exécuter avec beaucoup moins de mémoire qu’une machine virtuelle standard.
• Traitement des métadonnées au moment de la construction
  Un maximum de traitement sera effectué à la construction, votre application contiendra que les classes réellement nécessaires au moment de l’exécution. Habituellement, les classes requises pour effectuer le déploiement initial de l’application traînent pendant toute la durée de vie de l’application, même si elles sont utilisées une seule fois. Avec Quarkus, elles ne sont même pas chargés dans la VM. Du coup, une utilisation moindre de la mémoire et un démarrage plus rapide, car tous les traitements de métadonnées ont déjà été effectués.
• Réduction de l’utilisation de la réflexion
  Quarkus permet d’éviter les réflexions au maximum, le temps de démarrage et l’utilisation de la mémoire en sont donc réduits.
• Native Image Pre Boot
  Lors de l’exécution dans une image native, Quarkus initialise le plus possible la structure au cours du processus de création d’image native. Cela signifie que l’image native résultante a déjà exécuté la majeure partie du code de démarrage et sérialisé le résultat dans l’exécutable, ce qui permet un démarrage encore plus rapide.

Pour plus de détails je vous conseille d’aller directement sur le site, vous y trouverez de quoi commencer, utilisation de framework, build d’image native, intégration dans k8s etc…

lien youtube : https://www.youtube.com/watch?v=JhAYfP99agc

Vendredi 19 Avril

Apache Kafka : Patterns / Anti-patterns (Florent Ramière)

Florent Ramière de la société Confluent faisait un retour d’expérience sur les patterns et anti-patterns lié à la mise en place de Kafka en production, en lien avec les erreurs le plus souvent rencontrées chez leurs clients.

Il s’agissait de recommandations pour Kafka en lien avec les problèmes que l’on retrouve classiquement pour tous les logiciels clusterisés. Les points principaux, à notre sens, étaient les suivants :

• Faire attention à la durabilité des données (notamment via les configurations acks et min.insync.replicas)
• Mettre en place une gestion des cas d’erreurs :
  • Kafka peut automatiquement retenter de pousser des messages en cas d’erreur (configuration retries, par défaut à 0 mais la valeur conseillée est plutôt infinite).
  • Cela expose évidemment à des problèmes de duplication de messages : activer la configuration enable.idempotence permet d’attribuer automatiquement un UUID à chaque message pour régler le problème
  • Cette idempotence ne s’applique qu’au producteur : c’est donc au développeur de faire attention à ce que ses consommateurs soient idempotents (et ne pas committer manuellement, à l’aide de commitSync() dans le cas de Kafka)
  • Gérer les exceptions via la mise en place d’une Dead Letter Queue pour conserver les messages ou d’un simple log, il n’existe pas de solution miracle et tout dépend des cas métiers.
• Lire la documentation fournie (RTFM !) et configurer son OS (au moins file descriptor et mmap)
• Faire attention au choix de la clé de partition et au nombre de partitions
• Enfin, ne pas faire appel à des services externes depuis des streams Kafka : la latence liée à ces appels s’applique à chaque fois !

En résumé, une conférence très bien animée avec de nombreux exemples qui peuvent prêter à rire, mais que l’on retrouve plus souvent qu’on ne le croit : une bonne piqûre de rappel !

lien youtube : https://www.youtube.com/watch?v=rp537D69CYw

Pour plus de conférences n’hésitez pas à aller jeter un oeil sur la chaine youtube du DEVOXX FR.