Rapport Sur Les Tendances Java InfoQ—Décembre 2021

Cet article fournit un résumé de la façon dont l'équipe éditoriale d'InfoQ Java voit actuellement l'adoption de la technologie et les tendances émergentes dans l'écosystème Java.

Nous nous concentrons sur le langage Java, ainsi que sur les langages connexes tels que Kotlin et Scala, la machine virtuelle Java (JVM) et les frameworks et utilitaires basés sur Java.

Nous discutons des tendances de Java, telles que l'adoption de nouvelles versions de Java, ainsi que de l'évolution de frameworks tels que Jakarta EE, Quarkus, Micronaut, Helidon, MicroProfile et MicroStream.

Ce rapport a deux objectifs principaux :

• Aider les responsables techniques à prendre des décisions d'investissement technologique à moyen et long terme.
• Aider les développeurs individuels à choisir où investir leur temps et leurs ressources précieuses pour l'apprentissage et le développement des compétences.

Il s'agit de notre troisième rapport publié sur les tendances Java. Cependant, ce sujet a reçu une large couverture médiatique car nous suivons en interne les tendances Java et JVM depuis 2006.

Pour vous aider à naviguer dans les tendances actuelles et futures d'InfoQ et de QCon, nous utilisons le modèle mental « crossing the chasm » pour le succès technologique mis au point par Geoffrey Moore dans son livre du même nom. Nous essayons d'identifier des idées qui correspondent à ce que Moore a appelé l'early market, où "la cible est composée de passionnés de technologie et de visionnaires qui cherchent à devancer une opportunité ou un problème imminent".

Comme nous l'avons fait pour les rapports de 2020 et 2019, nous présentons le graphique de sujet interne pour 2021 :

Pour le contexte, voici notre graphique thématique interne pour 2020

Outre certaines nouvelles technologies identifiées dans l'espace Innovators, les changements notables incluent : la définition des versions de Spring (et de leurs projets associés), Jakarta EE et Scala dans différentes catégories. Nous avons opté pour cette approche afin d'éviter de généraliser ces technologies en une seule catégorie lorsque différents degrés de maturité et d'adoption existent.

Spring Framework 6 et Spring Boot 3, dont la sortie en GA est prévue fin 2022, subiront une refonte pour adopter la modularité et nécessiteront JDK 17+ et Jakarta EE 9. Une preview a récemment été mise à disposition avec la première release milestone de Spring Framework 6.

Lancé début 2021, Spring Native est un nouvel outil permettant de convertir des applications Spring Boot existantes, écrites en Java ou Kotlin, en images natives GraalVM et en est aux tout premiers stades de développement.

Scala 3, publié plus tôt cette année, a été remanié avec de nombreuses nouvelles fonctionnalités, une nouvelle syntaxe et le nouveau compilateur Dotty très attendu qui est en cours de développement depuis plusieurs années.

Plus tôt cette année, Microsoft a renforcé son engagement envers le langage de programmation Java en diffusant Microsoft Build d'OpenJDK, leur propre distribution downstream d'OpenJDK.

AdoptOpenJDK a rejoint la Fondation Eclipse et a été immédiatement renommé Adoptium. La transition vers Adoptium comprenait la création d'un groupe de travail Eclipse et une division d'AdoptOpenJDK en plusieurs sous-projets dans le cadre du projet de niveau supérieur Adoptium : Eclipse AQAvit, Eclipse Temurin et Eclipse Temurin Compliance.

Ce qui suit est un résumé légèrement modifié de la discussion correspondante sur divers sujets parmi plusieurs éditeurs de la section Java d'InfoQ et Java Champions :

• Michael Redlich, technicien de recherche senior chez ExxonMobil Research & Engineering et rédacteur en chef de la section Java chez InfoQ
• Ben Evans, ingénieur logiciel principal senior chez Red Hat, Java Champion et rédacteur pour la section Java chez InfoQ
• Erik Costlow, directeur des relations avec les développeurs chez Contrast Security et rédacteur pour la section Java chez InfoQ
• Johan Janssen, architecte logiciel chez Sanoma Learning et rédacteur pour la section Java chez InfoQ
• Karsten Silz, développeur Java Full-Stack senior et rédacteur pour la section Java chez InfoQ
• Monica Beckwith, ingénieur principal senior chez Microsoft et Java Champion
• Ana Maria Mihalceanu, Developer Advocate chez Red Hat et Java Champion
• Reza Rahman, responsable principal du programme Java sur Azure chez Microsoft
• Simon Ritter, directeur technique adjoint chez Azul et Java Champion

Nous pensons que cela fournit plus de contexte pour notre positionnement recommandé de certaines des technologies sur le graphique de sujet interne.

JDK 17

Monica Beckwith : Java est désormais plus respectueux des principes de la POO via la JEP 403 : Strongly Encapsulate JDK Internals. Calcul vectoriel via l'API Vector indépendante de la plate-forme. Les ajouts au langage, tels que les records, et les améliorations de la JVM, telles que le projet Valhalla, suppriment de nombreuses verbosités et embrassent davantage le concept d'immuabilité, offrant ainsi des opportunités d'optimisation des performances.

Ana Maria Mihalceanu : cette année a agréablement surpris les développeurs Java avec des versions Java LTS et non LTS. La version 17 de Java a confirmé que bon nombre des fonctionnalités en preview sont désormais disponibles de manière générale et à long terme. Cela a également ajouté un sentiment d'urgence pour certains projets qui s'exécutent toujours sur Java 8 de migrer vers une version plus récente. Java 17 est la LTS qui a réalisé le rêve de toujours d'avoir des NullPointerExceptions utiles.

Reza Rahman : comme toujours, toutes les parties de l'écosystème Java restent actives. Cela témoigne de la force fondamentale de Java. Je pense que Java SE 17 a été particulièrement bien reçu, en particulier des fonctionnalités telles que les records. Des environnements d'exécution comme WildFly, Payara et Open Liberty adoptent Java SE 17. Alors que certains développeurs ont adopté Java SE 11, Java SE 8 reste remarquablement présent. Il est possible que Java SE 17 change enfin cela.

Simon Ritter : la sortie du JDK 17 a été importante. Cela signifie que les développeurs disposent désormais d'une nouvelle version avec support à long terme (LTS) de toutes les distributions OpenJDK. Pour ceux qui ne souhaitent pas mettre à jour leur version Java tous les six mois pour rester aussi stable et sécurisé que possible, il s'agit d'une version importante.

J'aime la façon dont nous voyons plus de petites fonctionnalités syntaxiques ajoutées à la plate-forme plus rapidement que jamais auparavant. C'est grâce à la cadence de release de six mois, qui rend également les modules d'incubateur et les fonctionnalités en preview pratiques.

Il y a également des développements intéressants sur la façon dont la JVM peut fonctionner dans un environnement cloud, comme le nouveau projet dans OpenJDK appelé co-ordinated restore at checkpoint (CRaC). Les fonctionnalités, telles que les records, sont idéales pour développer du code nouveau.

Ben Evans : la sortie de Java 17 LTS et la possibilité de commencer enfin à déployer du code qui exploite les records et les types scellés, ainsi que le streaming JFR pour la surveillance de groupes de JVM. La voie vers la normalisation dans l'espace d'observabilité - en particulier OpenTelemetry. Les premiers signes d'un consensus émergent autour de ce que cela signifie pour Java d'être déployé de manière statique (« Static Java »). Je pense également que le projet Panama sera un sujet plus important que les gens ne le pensent.

Distributions downstream d'OpenJDK

Erik Costlow : il existe actuellement trop de distributions JDK non différenciées. Microsoft en a un, Eclipse a Adoptium avec Temurin, Oracle a le leur et une version OpenJDK, Azul, AWS Corretto, Red Hat, Liberica, SAP Machine, etc. Je vois une prolifération de ceux-ci, mais il est difficile de les garder en ordre. Le sondage de Snyk semble relativement conforme à ce que je vois en termes d'utilisation. Étant donné qu'ils sont tous compatibles, j'aimerais voir un randomiseur "Donnez moi un OpenJDK" sur le marché pour supprimer une décision pour les nouveaux développeurs Java juniors.
La marque Eclipse en particulier est déroutante : Adoptium est un groupe à l'intérieur d'Eclipse, qui est aussi un groupe. Temurin est la chose que vous utilisez et c'est OpenJDK. Imaginez que vous appreniez Java par vous-même et lisez cette phrase : « Eclipse Temurin est le nom de la distribution OpenJDK d'Adoptium. Moins de marques, c'est mieux.

Johan Janssen : Liberica, qui est de Bellsoft, propose en fait des produits assez intéressants qui les différencient des autres fournisseurs de JDK. Par exemple, un JDK complet qui contient toujours JavaFX. Je ne connais que ojdkbuild qui propose une version similaire. À côté de cela, ils ont plus de variantes du JDK et du JRE.

Azul prend en charge les versions non LTS avec des mises à jour mineures pendant une période plus longue. Certains fournisseurs proposent des images Docker, etc. Il y a donc quelques différences, mais il est difficile pour les utilisateurs finaux de les comparer et de prendre une bonne décision sur laquelle choisir.

Java EE/Jakarta EE

Reza Rahman : la transition de Java EE à Jakarta EE est l'un des transferts de technologie les plus importants et les plus importants dans notre écosystème. C'est enfin sur des bases solides avec Jakarta EE 9.x. Il est très bon de voir comment Jakarta EE 10 progresse maintenant vers une sortie au début de l'année prochaine. Il semble que de nombreux éléments du Guide de contribution de l'ambassadeur Jakarta EE soient matérialisant, comblant des lacunes de longue date. Je pense que c'est un grand soulagement pour les utilisateurs Java EE à long terme.

Je suis également très heureux de voir Jakarta EE 9.x prendre de l'ampleur. La plupart des environnements d'exécution ont adopté la transition d'espace de noms javax vers jakarta, y compris Tomcat et Jetty. Spring Framework 6 s'engage à adopter à la fois Java SE 17 et Jakarta EE 9. De même, MicroProfile 5 effectue la transition vers Jakarta EE. D'après le 2021 Jakarta EE Developer Survey, un nombre important de développeurs sont déjà passés à l'espace de noms jakarta ou envisagent de le faire.

Le profil de base Jakarta EE 10 ouvre la voie à la compatibilité totale de Quarkus et Helidon, l'API MicroProfile Config passe à la nouvelle spécification de configuration Jakarta et il en va de même avec la propagation de contexte MicroProfile. Il est possible que la même chose se produise avec le client REST MicroProfile et la propagation JWT.

Michael Redlich : avec la sortie de Jakarta EE 9, les fournisseurs d'outils peuvent prendre en charge le nouvel espace de noms du package jakarta, les équipes de développement peuvent tester la migration de leurs applications vers le nouvel espace de noms, et les fournisseurs d'exécution peuvent tester et fournir options et capacités qui prennent en charge la migration et la rétrocompatibilité avec Jakarta EE 8.

Jakarta EE 9 peut également être considéré comme une base pour l'innovation afin de générer de nouvelles fonctionnalités dans Jakarta EE 10 et au-delà.

GraalVM/Spring Native

Ana Maria Mihalceanu : la création d'un exécutable natif est un autre sujet souvent signalé comme « le plus recherché » alors que la course aux applications conteneurisées plus petites et plus rapides se poursuit.

Reza Rahman : il est également très bon de voir que Spring Native fait des progrès.

Erik Costlow : j'aime voir le rôle des applications natives prendre forme, mais déçu par l'absence d'un véritable cahier des charges ou d'un groupe de travail. Cela semble être une sorte de "vous obtenez tout ce que GraalVM fait" et il se comporte parfois différemment d'un JDK standard - similaire mais pas identique.

Johan Janssen : Spring Native est en concurrence avec tous les frameworks GraalVM et autres avec des temps de démarrage rapides et une faible utilisation de la mémoire.

Karsten Silz : une fois que Spring Boot prendra en charge la compilation native avec GraalVM, les programmes Java natifs rapides et petits deviendront courants. Cela rend Java plus compétitif pour les solutions serverless et peut l'aider dans le domaine des microservices. Je dis "peut" car à ce jour, je pense que le JIT de la JVM a toujours un meilleur débit/performance pour les processus de longue durée que GraalVM. Quoi qu'il en soit, cela fera beaucoup de bruit et rendra Java plus compétitif dans l'ensemble.

ARM64/Windows on ARM

Monica Beckwith : ARM64 est désormais du matériel de base. En conséquence, la présence de kits de développement Java et les environnements d'exécution Java optimisés pour le déploiement sur ARM64 ont gagné en popularité.

Karsten Silz : Java 16 prend en charge Windows sur ARM. Mais je pense que seul Java 17 avec ARM sur macOS ouvrira grand les portes. Je crois qu'environ un quart de tous les développeurs Java utilisent des Mac. Et d'ici la fin de 2022, ils ne pourront acheter que des Mac avec ARM. Je pense que cela poussera à la fois Windows et Linux sur ARM à s'améliorer également.

Jakarta EE et MicroProfile alignement == Cloud Native pour Java

Michael Redlich : les groupes de travail MicroProfile et Jakarta EE, deux initiatives complémentaires sous les auspices de la Fondation Eclipse, ont collaboré pour former un Cloud Native for Java (CN4J), une alliance pour définir Jakarta EE et le positionnement et l'alignement de MicroProfile, à la fois l'image de marque et la technique pour les technologies cloud-native.

Reza Rahman : c'est une agréable surprise de voir Quarkus faire des progrès bien mérités auprès des développeurs Java EE et Spring. Il est également très bon de voir l'alignement Jakarta EE et MicroProfile se produire enfin.

JavaFX/Gluon

Erik Costlow : je suis extrêmement impressionné par le travail accompli par Gluon pour faire fonctionner une seule base de code JavaFX partout. Le Web était la pièce manquante d'avant et, franchement, le client Java semble à nouveau cool.

Adoption de la modularité

Karsten Silz : je pense que JPMS essaie de résoudre trois problèmes : les problèmes de chargement des classes pour les serveurs d'applications ; une meilleure structuration du JDK et de toutes les applications Java ; et la réduction de l'empreinte JVM pour le déploiement/l'exécution.

Mais au moins, lorsque JPMS a finalement été lancé après plusieurs retards, il existait déjà des solutions suffisamment bonnes pour ces problèmes : OSGI pour le chargement des classes ; Tests de conception axée sur le domaine/architecture propre/Modulith/ArchUnit pour la structure du programme Java ; et compilation à l'avance pour une empreinte JVM réduite.

Comme nous pouvons avoir peu de points de données non fiables, ils montrent tous que l'utilisation de Java 8 et versions antérieures est supérieure ou égale à celle de Java 11 et versions ultérieures. Je pense que c'est en partie parce que les modules ont donné à Java 9+ la réputation d'être "difficile à mettre à niveau à partir de Java 8", comme le reconnaît Mark Reinhold . C'est une conséquence involontaire de JPMS. Et cela signifie qu'au moins la moitié de tous les développeurs Java ne peuvent pas utiliser les avancées Java des sept dernières années car ils sont bloqués sur Java 8.

Le coût d'opportunité de travailler sur des modules pendant probablement plus de 7 ans signifie que de nombreuses autres améliorations Java sont soit tombées à l'eau ou ne sont apparues que dans Java 10 et versions ultérieures. Le mot-clé var pour les variables, la nouvelle syntaxe de switch et les records Java réduisent beaucoup le code boilerplate pour lequel Java est tristement célèbre. Si ceux-ci étaient dans Java 9 au lieu de modules Java, je pense que Java serait dans une meilleure position maintenant car il proposerait une meilleure productivité des développeurs.

Qu'est-ce qui a changé depuis l'année dernière ?

Monica Beckwith : de nombreux architectes et développeurs ont apprivoisé les temps de pause du GC (garbage collection) en raison des améliorations apportées aux collecteurs existants. Beaucoup d'autres ont maîtrisé les latences de queue en passant à des GC adaptatifs à faible latence pour leurs charges de travail.

Ben Evans : Java 11 a essentiellement atteint la parité avec Java 8 en termes de part de marché. Les conteneurs ont percé et sont désormais le moyen de déploiement de la majorité des applications Java. Quarkus continue de mûrir et de gagner du terrain et de nouveaux fans.

Michael Redlich : quelques groupes de travail de la Fondation Eclipse ont été créés : MicroProfile, OSGi et Adoptium (anciennement AdoptOpenJDK). Le groupe de travail MicroProfile et le groupe de travail Jakarta EE ont collaboré à une initiative d'alliance Cloud Native for Java (CN4J).

Microsoft renforce son engagement envers Java en créant sa propre distribution downstream d'OpenJDK, Microsoft Build of OpenJDK et en rejoignant le Java Community Process.

Que dit la communauté Java ?

Monica Beckwith : Pattern matching avec les instructions switch, l'image native, cloud native-JVM et la JVM sur les accélérateurs, le projet Loom et Graal.

Ana Maria Mihalceanu : mise à jour. Parce que le langage Java a évolué, les fonctionnalités du framework ont ​​également prospéré. D'après mon expérience, écrire du code propre et sécurisé dépend rapidement des pratiques partagées par une équipe. De nos jours, il est possible de minimiser le temps passé à développer ou à corriger le code avec des tests continus et moins de configurations locales grâce à certaines fonctionnalités intégrées du framework.

Reza Rahman : Java SE 17 et Quarkus sont à l'honneur. Kubernetes reste très populaire. Il y a un enthousiasme précoce autour de Spring Native. Les membres de la communauté Java standard ouverte surveillent de près l'alignement Jakarta EE 10 et MicroProfile/Jakarta EE. Il se passe quelque chose de bien à peu près pour tout le monde dans l'écosystème.

Simon Ritter : pour presque tous les développeurs, du moins lorsqu'ils travaillent sur de nouveaux développements, il s'agit de savoir comment utiliser le cloud de la manière la plus efficace, en particulier via une architecture de microservices. L'utilisation de conteneurs et de technologies telles que Kubernetes et Spring Boot est très puissante lors de l'écriture de ces types d'applications. J'entends beaucoup de discussions sur la façon de les utiliser.

Ben Evans : Java 17, Loom, Quarkus.

Quoi de neuf et d'excitant auquel nous ne nous attendions pas ?

Monica Beckwith : j'avais anticipé la richesse de l'écosystème Java et les différentes variétés des fournisseurs JDK des offres Java Dev Kits. Néanmoins, la simple participation et l'accord sur la cadence de release accélérée ont été une bonne surprise.

Ana Maria Mihalceanu : ce que j'aime à propos de Java, c'est que chaque version ajuste à la fois le langage et l'expérience des développeurs. Des améliorations telles que le nouveau formateur de date pour la période du jour introduit dans les classes java.time.format.DateTimeFormatter et DateTimeFormatterBuilder, le pattern matching avec switch ou la méthode par défaut toList() dans l'interface java.util.stream.Stream aident les développeurs à écrire du code plus propre et plus facile à lire.

Simon Ritter : en regardant la plate-forme Java, il n'y avait rien à quoi nous ne nous attendions pas et c'est une bonne chose. Maintenant que les nouvelles fonctionnalités utilisent les JEP pour définir ce qu'elles sont censées faire, nous avons une feuille de route claire des éléments qui seront inclus dans Java dans quelques années. Cela signifie que les développeurs peuvent être assurés qu'il n'y aura pas de grands changements qui auront un impact sur la rétrocompatibilité, du moins pas sans avoir suffisamment de temps pour les évaluer et en discuter.

Ben Evans : un nouvel accent sur les technologies de démarrage à chaud/suspension et reprise/CRaC d'un certain nombre de fournisseurs, dont Azul et Red Hat.

Michael Redlich : l'émergence de MicroStream, une entreprise de persistance Java. Alors que leur histoire remonte à 2013, la société a été officiellement fondée en 2019. Depuis lors, ils ont ouvert MicroStream plus tôt cette année avec la sortie de MicroStream 5.0 et a collaboré pour intégrer MicroStream à Helidon et vient de sortir la version 6.0.

Karsten Silz : après des années de stagnation, VS Code fait bouger les choses dans l'espace des IDE Java. C'est quelque chose de nouveau : un IDE multiplateforme et multilingue, rapide, doté d'excellents plug-ins et apprécié de ses utilisateurs ! Si cela ressemble à "Eclipse IDE il y a 20 ans", vous avez raison !

VS Code a récemment renforcé ses capacités Java. Je m'attends à ce qu'il devienne le meilleur IDE Java gratuit. Je pense qu'Eclipse a reconnu cette menace et a créé un groupe de travail pour coordonner une défense. Je ne sais pas dans quelle mesure IntelliJ sera affecté.

Un effet secondaire intéressant de l'utilisation de VS Code pour le développement Java est que vous pouvez facilement développer avec des langages non JVM. Je ne pense pas que vous puissiez faire cela du tout dans Eclipse, ou seulement de manière limitée. Vous pouvez développer avec des langages non JVM en utilisant JetBrains "All Products Pack", mais vous devez ensuite lancer différents IDES qui ne partagent pas les paramètres, les plug-ins ou les raccourcis clavier.

La communauté Java

Ana Maria Mihalceanu : j'ai commencé mon parcours Java à l'université, en apprenant que Java prend en charge la programmation orientée objet avec des modèles de conception et les meilleures pratiques de codage. En tant que professionnel, je suis heureuse de voir qu'au fil du temps, le langage a également adopté d'autres paradigmes : fonctionnel, réactif offrant ainsi plus d'options de mise en œuvre sans perdre en lisibilité. Comment choisir entre chaque modèle ? Profilez occasionnellement votre application, repérez les goulots d'étranglement et améliorez votre logique de mise en œuvre.

Pourtant, aucune évolution n'est possible sans les gens. La communauté Java est vaste, dynamique et accueillante, présente à la fois physiquement et virtuellement dans un seul but : partager des connaissances, nous améliorer et réussir face à des problèmes.

Veuillez noter que les points de vue de nos contributeurs ne racontent qu'une partie de l'histoire. Différents acteurs de l'écosystème Java et des paramètres régionaux peuvent avoir des expériences différentes. Notre rapport pour 2021 doit être considéré comme un point de départ pour le débat, plutôt qu'une déclaration définitive, et une invitation à une discussion ouverte sur la direction que prend l'industrie.