자바 EE 대 J2EE 대 자카르타 EE

1. 소개

Java EE에 대해 들어 보셨습니까? Java 2EE, J2EE 또는 이제 Jakarta EE는 어떻습니까? 사실, 이것들은 모두 같은 것에 대해 서로 다른 이름입니다 : Java SE를 확장하는 일련의 엔터프라이즈 사양입니다.

이 짧은 기사에서는 Java EE의 진화에 대해 설명합니다.

2. 역사

Java의 첫 번째 버전에서 Java 엔터프라이즈 확장은 단순히 핵심 JDK의 일부였습니다.

그런 다음 1999 년 Java 2의 일부로 이러한 확장이 표준 바이너리에서 분리되었고 J2EE 또는 Java 2 Platform Enterprise Edition이 탄생했습니다. 2006 년까지 그 이름을 유지할 것입니다.

2006 년 Java 5의 경우 J2EE는 Java EE 또는 Java Platform Enterprise Edition으로 이름이 변경되었습니다. 그 이름은 중대한 일이 일어났던 2017 년 9 월까지 계속 될 것 입니다.

2017 년 9 월 Oracle은 Eclipse Foundation에 Java EE에 대한 권한을 제공하기로 결정했습니다 (이 언어는 여전히 Oracle 소유 임) .

3. 전환 중

사실 Eclipse Foundation은 법적으로 Java EE의 이름을 변경 해야 했습니다. 이는 오라클이 "Java"브랜드에 대한 권리를 가지고 있기 때문입니다.

그래서 새로운 이름을 선택하기 위해 커뮤니티는 투표를 통해 Jakarta EE를 선택했습니다. 어떤면에서는 여전히 J EE입니다.

* 새 이름 발표

그러나 이것은 여전히 ​​진화하는 이야기이며 먼지는 완전히 정착되지 않았습니다.

예를 들어 오라클은 소스 코드를 오픈 소스했지만 모든 문서를 오픈 소스하지는 않았습니다. 예를 들어 JMS 및 EJB와 관련된 오픈 소스 문서를 까다롭게 만드는 법적 문제로 인해이 문제에 대한 많은 논의가 있습니다.

새로운 Eclipse Foundation 문서가 원본을 참조 할 수 있는지 여부는 아직 명확하지 않습니다.

또한 흥미롭게도 Eclipse Foundation은 javax 네임 스페이스를 사용하여 새 Java 패키지를 만들 수 없지만 기존 클래스 아래에 새 클래스와 하위 클래스를 만들 수 있습니다.

전환은 또한 Jakarta EE에 사양을 추가하는 새로운 프로세스를 의미합니다. 더 잘 이해하기 위해 Oracle에서 프로세스가 어땠는지, Eclipse Foundation에서 어떻게 변경되었는지 살펴 보겠습니다.

4. 미래

역사적으로 기능을 "EE"로 만들려면 사양, 참조 구현 및 테스트의 세 가지가 필요했습니다 . 이 세 가지는 지역 사회의 모든 사람이 제공 할 수 있으며 집행위원회는 언제 언어에 추가 할 준비가되었는지 결정할 것입니다.

과거 프로세스를 더 잘 이해하기 위해 JSR, Glassfish 및 TCK가 무엇이며 새로운 EE 기능을 구현하는 방법을 자세히 살펴 보겠습니다 .

우리는 또한 미래에 무엇을 기대할 수 있을지 엿볼 것입니다.

4.1. JCP와 지금, EFSP

과거에는 새로운 EE 기능이 탄생 한 프로세스를 JCP (Java Community Process)라고했습니다.

Java SE는 오늘날에도 여전히 JCP를 사용합니다. 그러나 EE가 소유권을 Oracle에서 Eclipse Foundation으로 변경했기 때문에이를위한 새롭고 별도의 프로세스가 있습니다. Eclipse Foundation Specification Process (EFSP)이며 Eclipse Development Process의 확장입니다.

그러나 대부분 "투명성, 개방성, 공유 부담 및 공급 업체 중립성"과 관련하여 몇 가지 중요한 차이점이 있습니다. 예를 들어, EFSP 조직자는 공급 업체 중립적 인 협업 작업 그룹, 셀프 서비스 인증 프로세스, 능력주의로 운영하고 관리하는 조직을 구상합니다.

4.2. JSR

JCP에서 EE에 기능을 추가하는 첫 번째 단계는 JSR 또는 Java 사양 요청을 만드는 것이 었습니다. JSR은 EE 기능 의 인터페이스 와 약간 비슷했습니다 . JCP 집행위원회는 완성 된 JSR을 검토하고 승인 한 다음 JSR 기여자들이 코드를 작성하여 커뮤니티에서 사용할 수 있도록했습니다.

이에 대한 좋은 예가 2011 년에 처음 제안되었고 2012 년에 JCP에 의해 승인되었으며 2013 년에 최종적으로 출시 된 JSR-339 또는 JAX-RS입니다.

그리고 사양을 논의하는 동안 커뮤니티가 항상 무게를 잴 수 있었지만, 시간은 JSR 310, java.time 및 Joda Time 의 경우와 같이 구현 우선 접근 방식 이보다 널리 수용되는 기능과 API를 만드는 경향이 있음을 보여주었습니다. .

따라서 EFSP는이 코드 우선 관점을 명시된 목표에 반영합니다. "EFSP는 먼저 실습 실험 및 코딩을 기반으로하여 사양에 문서화 할 가치가 있음을 증명할 수 있습니다."

4.3. Glassfish

그런 다음 JCP의 일부로 JSR에는 참조 구현이 필요했습니다. 이것은 인터페이스 를 구현하는 클래스 와 약간 비슷합니다 . 참조 구현은 호환 가능한 라이브러리의 개발자 또는 자체 사양 구현을 작성하려는 기타 조직에 도움이됩니다.

Java EE 기능의 경우 JCP는 참조 구현에 Glassfish를 사용했습니다.

Glassfish에 대한 이러한 중앙 집중화는 구현 자의 검색 프로세스를 단순화하는 반면, 중앙 집중화에는 더 많은 거버넌스가 필요했고 한 공급 업체를 다른 공급 업체보다 선호하는 경향이있었습니다.

따라서 EFSP에는 참조 구현이 필요하지 않고 호환 가능한 구현 만 필요합니다. 간단히 말해서,이 미묘한 변화는 Glassfish와 같은 중앙 아키텍처 내부의 구현이 재단에서 실수로 선호하지 않도록합니다.

4.4. TCK

마지막으로 JCP는 기술 호환성 키트 (TCK)를 통해 EE 기능을 테스트해야했습니다.

TCK는 특정 EE JSR을 검증하기위한 테스트 모음이었습니다. 간단히 말해서, Java EE를 준수하려면 애플리케이션 서버가 모든 JSR을 구현하고 지정된 TCK에서 모든 테스트를 통과해야합니다.

여기에 많은 변화가 없습니다. 오라클은 TCK와 EE JSR을 오픈 소스했습니다. 물론 향후 모든 문서와 TCK는 오픈 소스가 될 것입니다.

5. 결론

Java EE는 그 기간 동안 확실히 많이 발전했습니다. 계속해서 변화하고 개선되는 것을 보게되어 기쁩니다.

앞으로 많은 과제가 있으므로 원활한 전환을 희망합시다.