Wie gut hat Jakarta EE auf die Bedürfnisse der Entwickler reagiert?

Crossposted auf Ed Burns Blog.

Zusammenfassung

Das Jakarta-Lenkungskomitee hat das Jakarta-Plattformprojekt mit dem Ziel ins Leben gerufen, das Feedback der Entwickler in die Entwicklung von EE 11 einzubeziehen. In diesem Blogbeitrag wird die Leistung des Plattformprojekts bewertet und ein GPA von 3,43 auf einer 4-Punkte-Skala für die Erreichung dieses Ziels vergeben Ziel.

Einführung

Ich fühle mich geehrt und fühle mich geehrt, in der Lage zu sein, bei der Umsetzung der nächsten Version von Jakarta EE mitzuhelfen. Ich habe im Laufe der Jahrzehnte viele Rollen in J2EE/Java EE/Jakarta EE inne: Implementierer, Spezifikationsleiter, Befürworter, Autor, Tester und mehr. Meine aktuelle Rolle ist jedoch eine neue für mich: Release-Koordinator.

In dieser Rolle leite ich (zusammen mit Arjan Tijms) das Jakarta Platform-Projekt, das für die Bereitstellung der fertigen Jakarta EE-Spezifikation (und Komponentenspezifikationen), des entsprechenden TCK und zumindest für die Ratifizierung der kompatiblen Implementierung verantwortlich ist alle Spezifikationen. Wichtig ist, dass es nicht eine einzige monolithische Implementierung geben muss, die alle Komponenten-TCKs gleichzeitig erfüllt, sondern dass es eine einzige monolithische Implementierung geben muss, die den Plattform-TCK erfüllt.

Im Geiste der Transparenz, die ich vor über zwei Jahrzehnten starten durfte, untersucht dieser Blogbeitrag, wie gut das Jakarta-Plattform-Projekt während der EE 11 eines der vom Lenkungsausschuss für das Plattform-Projekt festgelegten Ziele erreicht hat: Entwickler-Feedback einbeziehen.

Zu wenig versprechen und zu viel liefern

Institutionelles Gedächtnis ist die Art und Weise, wie Gruppen von Menschen aus Fehlern lernen und vermeiden, sie zu wiederholen. Ich hoffe, dass wir uns alle darauf einigen können, dass das institutionelle Gedächtnis wichtig und bewahrenswert ist. Da es sich bei Software um ausführbares Wissen handelt, ist ein sehr lang laufendes Open-Source-Softwareprojekt eine besondere Art institutionellen Gedächtnisses. Ein Projekt, das ein langjähriges Ökosystem aus langjährigen Open-Source-Projekten darstellt, ist so ziemlich der Gipfel des Besonderen. Was bedeutet es angesichts all dieser Besonderheiten, Entwickler-Feedback einzubeziehen?

Es ist viel einfacher, auf Entwickler-Feedback zu reagieren, wenn die möglichen Kosten eines Fehlers in einem einzigen Projekt enthalten sind. Angesichts der möglichen hohen Kosten war das Jakarta EE 11-Plattformprojekt mit unseren Zielen zur Einbeziehung des Entwickler-Feedbacks bewusst zurückhaltend. Dies ist unsere Umsetzung der bewährten Strategie „Underpromise and Overdeliver“.

Im Vorfeld von Jakarta EE 11 haben wir eine offene Community-Diskussion über die Anforderungen für Jakarta EE 11 geführt und diese in diesem Diskussionsdokument zu Jakarta EE 11 festgehalten. Sehen wir uns die Community-Beiträge an, die wir erhalten haben und die hauptsächlich von Entwicklern stammten, und schauen wir uns an, wie wir in EE11 abgeschnitten haben.

Unterversprechen

• Jakarta-Daten

• Jakarta NoSQL

• Übernehmen Sie Java SE 11, 17, 21 neue Funktionen und Breaking Changes

• Virtuelle Threads

• TCK-Refactoring

• CDI-zentriert

  • CDI ersetzt Managed Beans
  • CDI ersetzt EJB

• Redundante HTTP-Stacks auflösen: Servlet und REST

• MicroProfile und Jakarta Alignment

• CORS-Unterstützung

• Jakarta-Konfiguration

• Erleichtern Sie die Migration von einem Anbieter zum anderen

Gemischte Lieferung

Ich werde die Lieferung in vier Kategorien gruppieren: überliefert, geliefert, einigermaßen geliefert, nicht geliefert.

Überliefert

• Jakarta Persistence – Programmatische Konfiguration statt persistence.xml und vieles mehr Gavin King Blogbeitrag
• Jakarta Security – Wählen Sie dynamisch einen Authentifizierungsmechanismus security-311

Geliefert

• Jakarta-Daten

  • Ja, diese neue Spezifikation ist in der Plattform vorhanden.

• Übernehmen Sie die neuen Funktionen und Breaking Changes von Java SE 11, 17, 21.

  • Ja, es gibt zahlreiche Spezifikationen, die die neuen Sprachfunktionen von 11 bis 21 nutzen.

• TCK Refactoring (wir werden dies liefern. Wir halten die Freigabe dafür zurück).

  • Die Jakarta EE Platform TCK ist eine wichtige Softwarekomponente für die Bereitstellung des Wertversprechens der IT-Investitionsstabilität im Maßstab von Jahrzehnten. Aufgrund fehlender Wartungsinvestitionen sind bei der Software des TCK technische Schulden entstanden. Mit Jakarta EE 11 bringen wir das TCK auf den neuesten Stand der Testtools. Diese Investition wird bessere Kompatibilitätstests ermöglichen und die Hürde für das Hinzufügen weiterer Tests im Zuge der Weiterentwicklung der Jakarta EE-Plattform verringern.

• API-Flexibilität, d. h. keine Umbrella-JARs mehr.

  • Keine Fragen mehr wie „Muss ich auf Jakarta EE xx warten“, um diese Funktion zu nutzen?
  • Jakarta EE Platform APIs sind jetzt nur noch eine Sammlung von Standard-APIs.
  • Einzelne Spezifikationen können von den Benutzern nach Belieben ausgeschlossen oder aktualisiert werden,
  • Es können auch neue Spezifikationen hinzugefügt werden.
  • Dadurch ist die Jakarta EE-Plattform so flexibel wie Spring Boot, aber ohne den Implementierungsaufwand in Ihrer Anwendung, das Beste aus beiden Welten!

Etwas geliefert

• Virtuelle Threads

  • Die Parallelitätsspezifikation hat ein Annotationsattribut streng spezifiziert, das erfordert, dass Implementierungen virtuelle Threads nutzen, sofern diese in der Laufzeit verfügbar sind. Wenn Sie Java 21 oder höher verwenden, erhalten Sie virtuelle Threads, wenn Sie das Annotation-Attribut verwenden. Wenn Sie mit 17 laufen, tun Sie das nicht.

• CDI-zentriert

  • CDI ersetzt Managed Beans.

    • Das haben wir
      • Entfernen Sie die @ManagedBean-Annotation.
      • Verschieben Sie die „Integrations“-Teile von CDI von der CDI-Spezifikation in die Plattformspezifikation.
      • Jakarta Concurrency fügt der @Asynchronous-Annotation Zeitplanung hinzu, um die @Scheduled-Annotation für EJBs concurrency-271 zu ersetzen
      • Parallelitätsressourcen in CDI-Beans einfügen, anstatt @Resource in einer EJB-Parallelität-348 zu verwenden.
      • Unterstützung für verwaltete Beans in Jakarta REST entfernt.
      • Qualifizierer für Persistenzeinheiten in Persistenz – ermöglichen das Einfügen von Persistenzkontext auf CDI-idiomatische Weise.

• Neue Java-Funktionen

  • Datensätze als Embeddables und IDs in Jakarta Persistence.
  • Aufzeichnungen in Expression Language.
  • Datensätze in Validation (früher Bean Validation) validation-275.
  • Flow-API in Concurrency concurreny-368.

• MicroProfile und Jakarta Alignment

  • Das haben wir
    • Erstellen Sie die Jakarta Security MicroProfile Security Bridge-Spezifikation.

Nicht geliefert

• Jakarta NoSQL

  • Dies hat die Abstimmung zu Beginn des EE 11-Entwicklungszyklus nicht bestanden. Meiner Meinung nach waren die Gründe nicht technischer Natur und können daher für EE 12 gelöst werden.

• Redundante HTTP-Stacks auflösen: Servlet und REST

  • Das ist eine sehr große Sache. Meiner Meinung nach bräuchte es einen großen Anbieter, der hinter dieser Idee steht und erhebliche Ressourcen aufwendet, um sie umzusetzen, wahrscheinlich indem er Arbeit an Wettbewerber spendet, damit diese das Gleiche tun könnten.

• CORS-Unterstützung

  • Dieser ist mir noch nicht einmal auf dem Radar.

• Jakarta-Konfiguration

  • Dieses Problem scheint in einer „MicroProfile-Konfiguration ist gut genug“ festzustecken und fällt daher durchs Raster. Ich denke, wir müssten das MicroProfile-Projekt davon überzeugen, den Übergang von MicroProfile zur Jakarta EE Core Profile-Spezifikation zu ermöglichen.

• Erleichtern Sie die Migration von einem Anbieter zum anderen

  • Dies steht im Widerspruch zu den Geschäftsinteressen der einzelnen Anbieter, daher glaube ich nicht, dass diesem Thema große Aufmerksamkeit geschenkt wird.

Zusammenfassung

Lassen Sie uns quantitativ vorgehen. Für jeden Punkt in der Liste Underpromise gebe ich uns eine Buchstabennote. A für zu viel geliefert oder geliefert, B für teilweise geliefert, D für nicht geliefert.

Feedback to incorporate	Grade
Jakarta Data	A
Jakarta NoSQL	D
Adopt Java SE 11, 17, 21 new features and Breaking Changes	A
Virtual Threads	A
TCK Refactoring	A
CDI Centric	A
Resolve redundant HTTP stacks: Servlet and REST	D
MicroProfile and Jakarta Alignment	B
CORS support	D
Jakarta Config	D
Make it easier to migrate from one vendor to another	D

Mit dieser Liste haben wir nur einen Notendurchschnitt von 2,54 erreicht. Nicht so toll. Wenn wir die Entwickler-Feedback-Anfragen aus der Liste streichen, deren Aufnahme meiner Meinung nach nicht realistisch ist (CORS, Redundante HTTP-Stacks, Jakarta Config, Vereinfachung der Migration von einem Anbieter zu einem anderen), erhalten wir eine bessere Note: 3,43. Nicht schlecht, aber wir haben Raum zum Wachsen.

Das obige ist der detaillierte Inhalt vonWie gut hat Jakarta EE auf die Bedürfnisse der Entwickler reagiert?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!