Ed Burns 블로그에 교차 게시됨

요약

자카르타 운영 위원회는 EE 11 개발에 개발자 피드백을 통합한다는 목표로 자카르타 플랫폼 프로젝트를 승인했습니다. 이 블로그 게시물은 플랫폼 프로젝트의 성과를 검토하고 이를 달성하는 데 4점 만점에 3.43의 GPA를 부여합니다. 목표.

소개

자카르타 EE의 다음 버전을 제공하는 데 도움을 줄 수 있는 위치에 있게 되어 겸손하고 영광입니다. 저는 지난 수십 년 동안 J2EE/Java EE/Jakarta EE에서 구현자, 사양 책임자, 옹호자, 작성자, 테스터 등 다양한 역할을 맡아왔습니다. 하지만 현재 나의 역할은 릴리스 공동 코디네이터라는 새로운 역할입니다.

이 역할에서 저는 (Arjan Tijms와 함께) 완성된 자카르타 EE 사양(및 구성 요소 사양), 해당 TCK를 제공하고 최소한 호환 가능한 구현을 비준하는 일을 담당하는 Jakarta 플랫폼 프로젝트를 공동으로 이끌고 있습니다. 사양의 모든 것. 중요한 것은 모든 구성요소 TCK를 동시에 충족하는 단일 단일 구현이 있을 필요는 없지만 플랫폼 TCK를 통과하는 단일 단일 구현이 있어야 한다는 것입니다.

20여 년 전에 시작할 수 있었던 행운의 정신으로 이 블로그 게시물은 자카르타 플랫폼 프로젝트가 운영 위원회에서 설정한 플랫폼 프로젝트 목표 중 하나를 달성하는 데 있어 EE 11 기간 동안 얼마나 잘 수행했는지 검토합니다. 개발자 피드백을 통합합니다.

과소 약속 및 초과 제공

제도적 기억은 인간 집단이 실수로부터 학습하고 반복을 피하는 방법입니다. 그러한 정의에 따르면, 제도적 기억은 중요하고 보존할 가치가 있다는 점에 우리 모두가 동의할 수 있기를 바랍니다. 소프트웨어는 실행 가능한 지식이기 때문에 매우 오랫동안 실행되는 오픈 소스 소프트웨어 프로젝트는 특별한 종류의 제도적 기억입니다. 오랫동안 실행되는 오픈 소스 프로젝트의 생태계인 프로젝트는 거의 특별함의 정점입니다. 이러한 특별함을 염두에 두고 개발자 피드백을 통합한다는 것은 무엇을 의미합니까?

실수로 인해 발생할 수 있는 비용이 단일 프로젝트 내에 포함되어 있으면 개발자 피드백에 대한 대응성을 보여주는 것이 훨씬 쉽습니다. 가능한 높은 비용을 고려하여 Jakarta EE 11 플랫폼 프로젝트는 개발자 피드백을 통합하려는 우리의 목표에 따라 의도적으로 겸손했습니다. 이는 "약속 약속 및 초과 제공"이라는 검증된 진정한 전략을 구현한 것입니다.

Jakarta EE 11을 앞두고 우리는 Jakarta EE 11의 요구 사항에 대한 공개 커뮤니티 토론을 실시했으며 이를 이 Jakarta EE 11 토론 문서에 담았습니다. 주로 개발자 중심이었던 커뮤니티 의견을 검토하고 EE11에서 어떻게 수행했는지 살펴보겠습니다.

과소 약속

• 자카르타 데이터

• 자카르타 NoSQL

• Java SE 11, 17, 21의 새로운 기능 및 주요 변경 사항 채택

• 가상 스레드

• TCK 리팩토링

• CDI 중심

  • 관리 Bean을 교체하는 CDI
  • EJB를 대체하는 CDI

• 중복 HTTP 스택 해결: 서블릿 및 REST

• MicroProfile 및 자카르타 정렬

• CORS 지원

• 자카르타 구성

• 한 공급업체에서 다른 공급업체로 더 쉽게 마이그레이션할 수 있습니다.

혼합 배송

배송을 초과 배송, 배송 완료, 다소 배송 완료, 배송 실패의 네 가지 버킷으로 그룹화하겠습니다.

초과 게재됨

• Jakarta Persistence - persistence.xml 대신 프로그래밍 방식 구성 및 더 많은 Gavin King 블로그 게시물
• 자카르타 보안 - 인증 메커니즘을 동적으로 선택 security-311

배달됨

• 자카르타 데이터

  • 예, 이 새로운 사양이 플랫폼에 있습니다.

• Java SE 11, 17, 21의 새로운 기능과 주요 변경 사항을 채택하세요.

  • 예, 11 - 21의 새로운 언어 기능을 활용하는 수많은 사양이 있습니다.

• TCK 리팩토링(우리는 이것을 제공할 것입니다. 우리는 이에 대한 릴리스를 보류하고 있습니다).

  • 자카르타 EE 플랫폼 TCK는 수십 년에 걸쳐 IT 투자 안정성의 가치 제안을 제공하는 데 필수적인 소프트웨어 구성 요소입니다. TCK의 소프트웨어는 유지관리 투자가 부족하여 기술적인 부채가 계속 쌓여왔습니다. Jakarta EE 11에서는 최첨단 테스트 도구를 사용하여 TCK를 최신 상태로 유지하고 있습니다. 이 투자를 통해 더 나은 호환성 테스트가 가능해지고 자카르타 EE 플랫폼이 발전함에 따라 더 많은 테스트를 추가하는 장벽이 낮아질 것입니다.

• API 유연성, 즉 더 이상 Umbrella JAR이 필요하지 않습니다.

  • 이 기능을 사용하려면 "Jakarta EE xx를 기다려야 하나요?"와 같은 질문이 더 이상 필요하지 않습니까?
  • Jakarta EE 플랫폼 API는 이제 기본 API 모음일 뿐입니다.
  • 사용자가 원하는 대로 개별 사양을 제외하거나 업그레이드할 수 있습니다.
  • 새로운 사양도 추가될 수 있습니다.
  • 이를 통해 Jakarta EE 플랫폼은 Spring Boot만큼 유연하면서도 애플리케이션에 구현 부담이 없어 두 가지 장점을 모두 누릴 수 있습니다.

다소 전달됨

• 가상 스레드

  • 동시성 사양에는 런타임에 사용 가능한 경우 가상 스레드를 활용하기 위한 구현이 필요한 주석 속성이 엄격하게 지정되어 있습니다. Java 21 이상에서 실행 중인 경우 주석 속성을 사용할 때 가상 스레드를 얻습니다. 17일에 출마한다면 그렇지 않습니다.

• CDI 중심

  • 관리 Bean을 교체하는 CDI.

    • 우리는 그랬어요
      • @ManagedBean 주석을 제거합니다.
      • CDI의 "통합" 부분을 CDI 사양에서 플랫폼 사양으로 이동합니다.
      • Jakarta Concurrency는 @Asynchronous 주석에 스케줄링을 추가하여 EJB 동시성-271의 @Scheduled 주석을 대체합니다.
      • EJB 동시성-348에서 @Resource를 사용하는 대신 CDI Bean에 동시성 리소스를 주입합니다.
      • 자카르타 REST에서 관리형 Bean 지원이 제거되었습니다.
      • 지속성의 지속성 단위 한정자 - CDI 관용적 방식으로 지속성 컨텍스트를 주입할 수 있습니다.

• 새로운 Java 기능

  • Jakarta Persistence에 삽입 가능 항목 및 ID로 기록됩니다.
  • 표현 언어로 기록합니다.
  • 검증(이전의 Bean 검증) 검증-275에 기록됩니다.
  • 동시성 concurreny-368의 흐름 API.

• MicroProfile 및 자카르타 정렬

  • 우리는 그랬어요
    • Jakarta Security MicroProfile 보안 브리지 사양을 생성합니다.

배달되지 않음

• 자카르타 NoSQL

  • 이는 EE 11 개발 주기가 시작될 때 투표를 통과하지 못했습니다. 제 생각에는 그 이유는 기술적인 것이 아니므로 EE 12에서 해결될 수 있습니다.

• 중복 HTTP 스택 해결: 서블릿 및 REST

  • 이것은 매우 큰 것입니다. 제 생각에는 이 아이디어를 뒷받침하는 주요 공급업체가 이를 실현하기 위해 상당한 자원을 헌신해야 하며, 경쟁업체도 같은 일을 할 수 있도록 작업을 기부해야 할 것입니다.

• CORS 지원

  • 이건 내 레이더에도 나타나지 않았습니다.

• 자카르타 구성

  • 이것은 "MicroProfile 구성이 충분합니다"에 갇혀 있는 것 같아서 균열 사이에 빠지고 있습니다. MicroProfile에서 Jakarta EE Core Profile 사양으로 이동할 수 있도록 MicroProfile 프로젝트를 설득해야 한다고 생각합니다.

• 한 공급업체에서 다른 공급업체로 더 쉽게 마이그레이션할 수 있습니다.

  • 이건 각 벤더의 사업적 이해관계에 어긋나는 부분이라 크게 주목을 받기는 어려울 것 같습니다.

요약

정량적으로 살펴보겠습니다. 미달 약속 목록의 각 항목에 대해 문자 등급을 부여하겠습니다. A는 초과배송 또는 배송됨, B는 다소 배송됨, D는 배송되지 않음

이 목록에서는 GPA가 2.54에 불과했습니다. 그다지 좋지는 않습니다. 목록에서 포함하기에 현실적이지 않다고 판단되는 개발자 피드백 요청(CORS, 중복 HTTP 스택, 자카르타 구성, 한 공급업체에서 다른 공급업체로 마이그레이션하기 쉽게 만들기)을 삭제하면 더 나은 등급인 3.43을 얻습니다. 나쁘지는 않지만 성장할 여지가 있습니다.