Publié sur le blog d'Ed Burns.

Résumé exécutif

Le comité directeur de Jakarta a créé le projet Jakarta Platform dans le but d'intégrer les commentaires des développeurs dans le développement de EE 11. Cet article de blog passe en revue les performances du projet Platform et attribue une moyenne cumulative de 3,43 sur une échelle de 4 points pour atteindre cet objectif. but.

Introduction

Je suis honoré et honoré de me retrouver en mesure de contribuer à la réalisation de la prochaine itération de Jakarta EE. J'ai occupé de nombreux rôles dans J2EE/Java EE/Jakarta EE au fil des décennies : implémenteur, responsable des spécifications, défenseur, auteur, testeur, etc. Mon rôle actuel, cependant, est nouveau pour moi, co-coordinateur des versions.

Dans ce rôle, je co-dirige (avec Arjan Tijms) le projet Jakarta Platform, qui est chargé de fournir la spécification Jakarta EE terminée (et les spécifications des composants), le TCK correspondant, et au moins de ratifier une mise en œuvre compatible pour toutes les spécifications. Il est important de noter qu’il n’est pas nécessaire qu’il y ait une seule implémentation monolithique qui satisfasse tous les TCK des composants en même temps, mais il doit y avoir une seule implémentation monolithique qui satisfait aux TCK de la plateforme.

Dans l'esprit de transparence que j'ai eu la chance de démarrer il y a plus de deux décennies, cet article de blog examine dans quelle mesure le projet de plateforme de Jakarta a réussi au cours de l'EE 11 à atteindre l'un des objectifs fixés pour le projet de plateforme par le comité directeur : intégrer les commentaires des développeurs.

Sous-promettre et livrer trop

La mémoire institutionnelle est la manière dont les groupes d’humains apprennent de leurs erreurs et évitent de les répéter. Par cette définition, j’espère que nous pourrons tous convenir que la mémoire institutionnelle est importante et mérite d’être préservée. Parce qu’un logiciel est une connaissance exécutable, un projet de logiciel open source de très longue durée constitue un type particulier de mémoire institutionnelle. Un projet qui est un écosystème de longue date de projets open source de longue durée est à peu près le summum de la spécialisation. Avec toute cette particularité à l’esprit, que signifie intégrer les commentaires des développeurs ?

Il est beaucoup plus facile de faire preuve de réactivité aux commentaires des développeurs lorsque les coûts possibles d'une erreur sont contenus dans un seul projet. Compte tenu des coûts élevés possibles, le projet de plate-forme Jakarta EE 11 était intentionnellement modeste avec nos objectifs d'intégration des commentaires des développeurs. Il s'agit de notre mise en œuvre de la stratégie éprouvée de « sous-promesse et surlivraison ».

Avant Jakarta EE 11, nous avons mené une discussion communautaire ouverte sur les exigences de Jakarta EE 11 et les avons capturées dans ce document de discussion Jakarta EE 11. Passons en revue les commentaires de la communauté que nous avons reçus, qui étaient principalement dirigés par les développeurs, et voyons comment nous avons réussi dans EE11.

Sous-promesse

• Données de Jakarta

• Jakarta NoSQL

• Adoptez les nouvelles fonctionnalités et les dernières modifications de Java SE 11, 17, 21

• Fils virtuels

• Refactorisation TCK

• Centrée sur le CDI

  • CDI remplaçant les beans gérés
  • CDI remplaçant EJB

• Résoudre les piles HTTP redondantes : Servlet et REST

• Alignement MicroProfile et Jakarta

• Prise en charge CORS

• Configuration de Jakarta

• Facilitez la migration d'un fournisseur à un autre

Livraison mixte

Je vais regrouper la livraison en quatre catégories : surlivrée, livrée, quelque peu livrée, non livrée.

Surlivré

• Jakarta Persistence - configuration programmatique au lieu de persistence.xml et bien d'autres articles du blog Gavin King
• Jakarta Security - choisissez dynamiquement un mécanisme d'authentification security-311

Livré

• Données de Jakarta

  • Oui, cette nouvelle spécification est présente dans la plateforme.

• Adoptez les nouvelles fonctionnalités et les dernières modifications de Java SE 11, 17, 21.

  • Oui, de nombreuses spécifications profitent des nouvelles fonctionnalités linguistiques de la version 11 à 21.

• TCK Refactoring (nous le livrerons. Nous conservons la version pour cela).

  • La plate-forme Jakarta EE TCK est un composant logiciel essentiel pour offrir la proposition de valeur de stabilité des investissements informatiques à l'échelle des décennies. Le logiciel du TCK a accumulé une dette technique en raison du manque d'investissement dans la maintenance. À Jakarta EE 11, nous mettons le TCK à jour avec l’état de l’art des outils de test. Cet investissement permettra de meilleurs tests de compatibilité et réduira les obstacles à l'ajout de tests supplémentaires à mesure que la plateforme Jakarta EE évolue.

• Flexibilité de l'API, c'est-à-dire plus de JAR Umbrella.

  • Plus de questions du type « dois-je attendre Jakarta EE xx » pour avoir cette fonctionnalité ?
  • Les API de la plateforme Jakarta EE ne sont désormais qu'un ensemble d'API par défaut.
  • Les spécifications individuelles peuvent être exclues ou mises à niveau par les utilisateurs à leur guise,
  • De nouvelles spécifications peuvent également être ajoutées.
  • Cela rend la plate-forme Jakarta EE aussi flexible que Spring Boot, mais sans avoir le bagage d'implémentation dans votre application, le meilleur des deux mondes !

Un peu livré

• Fils virtuels

  • La spécification de concurrence a un attribut d'annotation rigoureusement spécifié qui nécessite que les implémentations tirent parti des threads virtuels s'ils sont disponibles dans le runtime. Si vous utilisez Java 21 ou une version ultérieure, vous obtenez des threads virtuels lorsque vous utilisez l'attribut d'annotation. Si vous courez sur 17, vous ne le faites pas.

• Centrée sur le CDI

  • CDI remplaçant les beans gérés.

    • Nous l'avons fait
      • supprimez l'annotation @ManagedBean.
      • Déplacez les parties « intégration » de CDI de la spécification CDI vers la spécification de plate-forme.
      • Jakarta Concurrency ajoute la planification à l'annotation @Asynchronous pour remplacer l'annotation @Scheduled sur la concurrence des EJB-271
      • Injecter des ressources de concurrence dans des beans CDI au lieu d'utiliser @Resource dans une concurrence EJB-348.
      • Suppression de la prise en charge des beans gérés dans Jakarta REST.
      • Qualificateurs pour les unités de persistance dans Persistence - permettent d'injecter un contexte de persistance d'une manière idiomatique CDI.

• Nouvelles fonctionnalités Java

  • enregistrements en tant qu'éléments intégrables et identifiants dans Jakarta Persistence.
  • enregistrements en langage d'expression.
  • enregistrements dans Validation (anciennement Bean Validation) validation-275.
  • API de flux dans Concurrency concurreny-368.

• Alignement MicroProfile et Jakarta

  • Nous l'avons fait
    • Créez la spécification du pont de sécurité Jakarta Security MicroProfile.

N'a pas livré

• Jakarta NoSQL

  • Cela n'a pas été voté au début du cycle de développement de l'EE 11. À mon avis, les raisons n'étaient pas techniques et peuvent donc être résolues pour l'EE 12.

• Résoudre les piles HTTP redondantes : Servlet et REST

  • C'est un très gros problème. À mon avis, il faudrait qu'un fournisseur majeur soutienne cette idée et consacre des ressources importantes pour y parvenir, probablement en faisant don de travail à des concurrents afin qu'ils puissent également faire de même.

• Prise en charge CORS

  • Celui-ci n'est même pas apparu sur mon radar.

• Configuration de Jakarta

  • Celui-ci semble être coincé dans une "configuration MicroProfile est assez bonne" et tombe donc entre les mailles du filet. Je pense que nous devrons convaincre le projet MicroProfile de permettre à cela de passer de MicroProfile à la spécification Jakarta EE Core Profile.

• Facilitez la migration d'un fournisseur à un autre

  • Celui-ci est contraire aux intérêts commerciaux de chaque fournisseur, donc je ne pense pas que celui-ci retienne beaucoup d'attention.

Résumé

Passons au quantitatif. Pour chaque élément de la liste Underpromise, je vous attribuerai une note alphabétique. A pour surlivré ou livré, B pour quelque peu livré, D pour non livré.

Avec cette liste, nous n'avons obtenu qu'un GPA de 2,54. Pas si génial. Si nous supprimons de la liste les demandes de commentaires des développeurs que je juge peu réalistes d'inclure (CORS, piles HTTP redondantes, configuration Jakarta, faciliter la migration d'un fournisseur à un autre), nous obtenons une meilleure note : 3,43. Pas mal, mais nous avons de la marge pour grandir.