>  기사  >  Java  >  Jakarta EE는 개발자의 요구에 얼마나 잘 대응했나요?

Jakarta EE는 개발자의 요구에 얼마나 잘 대응했나요?

Patricia Arquette
Patricia Arquette원래의
2024-09-27 06:11:03728검색

How well did Jakarta EE respond to the needs of developers?

Ed Burns 블로그에 교차 게시됨

요약

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

소개

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

이 역할에서 저는 (Arjan Tijms와 함께) 완성된 Jakarta 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 중심

    • Managed 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를 최신 상태로 유지하고 있습니다. 이러한 투자를 통해 더 나은 호환성 테스트가 가능해지고 Jakarta EE 플랫폼이 발전함에 따라 더 많은 테스트를 추가하는 데 대한 장벽이 낮아질 것입니다.
  • API 유연성, 즉 더 이상 Umbrella JAR이 필요하지 않습니다.

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

다소 전달됨

  • 가상 스레드

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

    • Managed Bean을 교체하는 CDI.

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

    • Jakarta Persistence에 삽입 가능 항목과 ID로 기록됩니다.
    • Expression Language로 기록합니다.
    • Validation(이전의 Bean Validation) 유효성 검사-275에 기록됩니다.
    • 동시성 concurreny-368의 흐름 API.
  • MicroProfile과 자카르타 정렬

    • 우리는 그랬습니다
      • Jakarta Security MicroProfile 보안 브리지 사양을 만듭니다.

배달되지 않음

  • 자카르타 NoSQL

    • EE 11 개발 주기 초기에는 투표를 통과하지 못했습니다. 제 생각에는 그 이유는 기술적인 것이 아니므로 EE 12에서는 해결될 수 있습니다.
  • 중복된 ​​HTTP 스택 해결: 서블릿 및 REST

    • 아주 큰 일이군요. 제 생각에는 이 아이디어를 뒷받침하는 주요 공급업체가 이를 실현하기 위해 상당한 자원을 투자하고 경쟁업체도 같은 일을 할 수 있도록 작업을 기부하는 것이 필요할 것입니다.
  • CORS 지원

    • 이건 내 레이더에도 들어오지 않았어.
  • 자카르타 구성

    • 이것은 "MicroProfile 구성이면 충분합니다"에 갇혀 있는 것 같아서 균열 사이에 있는 것 같습니다. MicroProfile에서 Jakarta EE Core Profile 사양으로 이동할 수 있도록 MicroProfile 프로젝트를 설득해야 할 것 같습니다.
  • 한 공급업체에서 다른 공급업체로 더 쉽게 마이그레이션할 수 있습니다

    • 이건 각 업체의 사업적 이해관계가 상반되는 부분이라 크게 주목을 받을 것 같지는 않습니다.

요약

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

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

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

위 내용은 Jakarta EE는 개발자의 요구에 얼마나 잘 대응했나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.