Jakarta EE / MicroProfile Perspectives Pour 2021

Certes, 2020 sera une étape importante dans l'histoire pour plusieurs raisons. Au sein de la communauté Java, en particulier, en plus de la popularisation de Quarkus, il y a eu beaucoup de travail et d'efforts au sein de la Fondation Eclipse sur Jakarta EE, ainsi que sur MicroProfile. Apprenez à connaître ces nouvelles et grandes réalisations de l'année dernière, en plus des projections et des attentes pour l'année à venir.

Il est toujours bon de parler de la grande importance de la Fondation Eclipse. Outre l' EDI, qui est l'un des outils les plus utilisés dans le monde Java, la Fondation Eclipse est un espace d'innovation, de collaboration et, bien entendu, un processus qui garantit que toute cette propriété intellectuelle sera liée à l'open source au sein du processus, depuis la création du projet jusqu'à la sortie d'une nouvelle version de projets existants. 

Jakarta EE /MicroProfile

Rétrospective en regardant rapidement cette année pour les deux plates-formes, nous pouvons commencer par des événements en ligne liés à Jakarta : Jakarta One a eu un total de cinq éditions dans plusieurs langues telles que le portugais, l'anglais, le japonais et l'espagnol. 

Quand nous parlons de lancements, dans le monde de Jakarta EE, nous avons sa neuvième version avec son plus grand impact avec le big bang par lequel tous les packages qui étaient autrefois "javax" deviennent "jakarta". Dans le monde MicroProfile, la version 4.0 a été lancée avec la création d'un groupe de travail, et donc, un processus de spécification. Ce lancement de MicroProfile permet une entraide entre les deux projets. Avant la version 4.0 de MicroProfile, lui seul pouvait utiliser les API Jakarta EE, comme c'est déjà le cas, par exemple, avec CDI, JAX-RS, etc. Cependant, il sera désormais possible pour une contribution mutuelle induisant que les API de Jakarta pourront également utiliser MicroProfile. 

En ce moment, il y a une grande discussion pour définir comment cette contribution mutuelle se produira. Il existe plusieurs idéaux initiaux, et c'est l'occasion de rejoindre la liste de diffusion pour donner votre avis.

Les prochaines étapes

Pour éviter des impacts majeurs en une seule version, Jakarta EE 9 est toujours compatible avec Java 8, et avec cette version faite, l'étape suivante consiste à lancer une nouvelle version, compatible avec Java 11. 

Du côté de MicroProfile, il y a déjà une discussion sur la possibilité d'avoir une version compatible avec Jakarta EE 9, ainsi que sur le fonctionnement de cette intégration.

L'autre point est le lancement de Cloud Native for the Java (CN4J) Alliance, sur lequel repose une intégration des deux plates-formes. Bien que nous n'ayons pas obtenu de définition écrite de ce qu'est le terme «cloud natif», nous savons que l'avenir du développement et de l'architecture sera lié au modèle de traitement dans le cloud.

Les perspectives, mais d'abord l'histoire

Comme le dirait Confucius: «Si vous voulez prédire l'avenir, étudiez le passé», il est donc important de revenir un peu sur l'histoire et les événements de Jakarta EE ces dernières années. 

En 2016, jusque-là, Java EE a reçu plusieurs plaintes de la communauté en raison du faible rythme de livraisons et de la participation à la plateforme, principalement liées aux spécifications dont Oracle était responsable. C'est à cette époque que Reza Rahman a conduit la création d'un groupe d'intérêt à cette technologie, à l'époque, formé en tant que Java EE Guardians, aujourd'hui ce groupe s'appelle jakartaee-ambassadors.

Cette même année, les conférences Devoxx UK et DevNation ont entamé la discussion sur un nouveau projet, dont l'objectif serait d'aider Java EE jusque-là. En 2016, Java a officiellement annoncé Microprofile Eclipse. Les membres initiaux étaient les mêmes que ceux du groupe du comité exécutif du JCP, c'est-à-dire IBM, Red Hat, Payara, Tomitribe, LJC et SouJava.

L'objectif initial était d'aider le processus d'innovation qui fait tant défaut à Java EE, c'est pourquoi les premières étapes ont été franchies :

• La livraison
• Une interaction rapide et innovante
• La maturité
• Le modèle, via le retour de JSR à Java EE, comme ils l'ont essayé avec l'API de configuration dans JSR 382

Cependant, l'année suivante, en 2017, cette histoire devient plus intéressante, lorsqu'Oracle décide de faire don du code et de toute la propriété intellectuelle à la Fondation Eclipse quelques mois après avoir fait don de la base de code NetBeans à la Fondation Apache.

Voyons maintenant les perspectives d'avenir

Étant donné le contexte historique, le premier point dont nous devons discuter est l'organisation. Dans le passé, Java EE et MicroProfile avaient un sentiment de séparation, cependant, actuellement, les deux projets font partie de la même organisation, la Fondation Eclipse. L'Alliance Cloud Native for Java (CN4J) a l'intention de les réunir d'une manière ou d'une autre.

Un autre point important est les nouvelles spécifications qui ont tendance à entrer dans la famille Jakarta EE cette année. Il s'agira de:

• Jakarta MVC : une spécification au sein de Jakarta EE, anciennement JSR 371
• Jakarta NoSQL : la première spécification née au sein de Jakarta EE. Elle vise à faciliter l'intégration entre le monde Java et NoSQL

Le choix pour les  frameworks : réflexion vs sans réflexion

L'un des sujets qui suscite certainement beaucoup de discussions dans le monde des frameworks concerne la lecture des métadonnées au sein d'une classe Java, que ce soit les options ou l'impact de chacun. Mais qu'est ce que ça veut dire ? Pour le développeur final, il a tendance à ne pas avoir beaucoup de changements par rapport à l'API ou aux annotations qu'il utilise, cependant, pour l'architecture des frameworks, cela a tendance à nécessiter de nombreux changements. En général, les frameworks fonctionnent avec l'utilisation de la réflexion dans le monde Java, cependant, cela pose un gros problème. La réflexion a tendance à dégrader le démarrage et à augmenter la consommation de mémoire.

Une autre option serait d'amener tout ce processus de génération de métadonnées au moment de la compilation, c'est-à-dire que lors de l'exécution des informations, les métadonnées seraient déjà traitées et n'auraient pas besoin d'utiliser des ressources de réflexion, grâce à certains composants tels que le Java Annotation Processor, par exemple, dans les cas qui nécessitent un temps de démarrage rapide comme avec serverless. Un autre avantage est la possibilité d'utiliser le code en mode natif.

Basé sur plusieurs réussites de différents frameworks, Java prend en charge le code natif avec GraalVM, tels que Quarkus, Helidon, Micronaut et Spring. Il existe également plusieurs initiatives de spécifications pour explorer également ce type de ressources telles que le CDI Lite.

Certes, il existe plusieurs mythes autour de l'Ahead of Time, car chaque choix comporte des compromis. C'est pourquoi Steve Millidge a écrit un article brillant sur le sujet, en général, il aborde plusieurs points qui sont critiqués concernant la réflexion et amènent Ahead of Time pour le  démarrage à froid en serverless. 

Modularisation vs Profiles

En 2011, dans la version 6 de Java EE, il y a eu le lancement du premier profil dans Java EE, qui était WebProfile. Comme son nom l'indique, il s'agit d'un profil axé sur la réduction de la consommation de disque, c'est-à-dire que WebProfile aurait huit spécifications par rapport à Java EE complet, qui contenait toutes les spécifications, avec un total de vingt-quatre.

Et il y a une proposition de créer un autre profil, LiteProfile, qui serait plus léger que le profil Web. 

D'autre part, il existe une autre option, les modalisations. Le grand avantage de cette approche est le choix précis possible des dépendances pour une application particulière. Ce modèle avec modules est une solution qui a été utilisée avec succès dans certains frameworks Java tels que Quarks, Spring, Helidon, entre autres plates-formes du monde Java. Un autre avantage est que le nombre de combinaisons entre les spécifications étant important, il est nécessaire d'avoir un grand nombre de profils pour proposer toutes les combinaisons. Avec les modules, cela se produirait tout naturellement.

L'année des services

L'utilisation et l'adoption du cloud sont imminentes et inévitables, cependant, pour accélérer ce processus, il existe un type de service qui vise à réduire la complexité, augmenter l'abstraction, ce qui réduit par conséquent le risque d'utiliser le modèle de cloud computing. Dans le livre 97 choses que tout ingénieur devrait savoir sur le cloud,  Dan Moore explique l'importance et la facilité d'utilisation des services gérés ainsi que des infrastructures que ce type de service octroie, surtout le savoir-faire pour gérer et maintenir les logiciels. Avec cela, des activités importantes telles que la mise à jour de la base de données, la version Java, la sauvegarde, la gestion de l'accès aux applications et à la base de données pour la sécurité, etc. seront transférées à ce type de service, ce qui permet à l'équipe de développeurs de se concentrer sur la livraison de fonctionnalités métiers. 

En se développant à proximité de MicroProfile et Jakarta EE, il existe des services de gestion cloud qui prennent en charge les deux plates-formes:

• Payara Cloud: c'est un moyen simple de gérer le serveur d'applications dans le cloud
• Platform.sh: Un PaaS qui vise à gérer l'application ainsi que les services dont l'application a besoin comme une base de données. L'approche PaaS se concentre sur l'infrastructure en tant que code où l'équipe met toutes les dépendances dans des fichiers de configuration et l'ensemble de la configuration sera en charge de PaaS en utilisant fortement le concept de GitOps. 

Ce sont quelques exemples qui fonctionnent avec MicroProfile et Jakarta EE et sont également des services gérés dans le cloud, même si cette installation cloud n'est pas directement liée au processus, elle contribue certainement à la popularité de l'environnement Java dans le cloud. On pense que cette année, cette popularité aura tendance à croître beaucoup plus.

Conclusion

En regardant le passé et le présent, à la fois de MicroProfile et Jakarta EE, il est possible de percevoir une grande perspective pour l'avenir. La transparence et la collaboration sont deux des fondements  de la Fondation Eclipse. Parmi les points en discussion pour cette année, les points forts seront certainement la migration vers Java 11, l'union et le réglage des deux projets, la définition de savoir si les projets auront plus de modules ou s'ils seront plus ciblés, en plus de bien d'autres choses ! La meilleure partie est que tout le monde dans la communauté Java peut participer et créer l'avenir au lieu de simplement le regarder. 

A propos de l'auteur

Otávio Santana est un ingénieur logiciel avec une vaste expérience dans le développement open source, avec plusieurs contributions à JBoss Weld, Hibernate, Apache Commons et à d'autres projets. Axé sur le développement multilingue et les applications haute performance, Otávio a travaillé sur de grands projets dans les domaines de la finance, du gouvernement, des médias sociaux et du commerce électronique. Membre du comité exécutif du JCP et de plusieurs groupes d'experts JSR, il est également un champion Java et a reçu le JCP Outstanding Award et le Duke's Choice Award.