[정보] Java EE vs J2EE vs Jakarta 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월까지 계속 유지되었습니다 .
3. 전환중
실제로 Eclipse Foundation은 법적으로 Java EE의 이름을 바꿔야 했습니다 . 이는 Oracle이 "Java" 브랜드에 대한 권리를 갖고 있기 때문입니다.
그래서 새 이름을 선택하기 위해 커뮤니티는 투표를 통해 Jakarta EE를 선택했습니다. 어떤 면에서는 여전히 JEE입니다.
하지만 이것은 여전히 진화하는 이야기이고, 진행 중입니다.
예를 들어 Oracle은 소스 코드를 오픈 소스로 제공했지만 모든 문서를 오픈 소스로 제공하지는 않았습니다. 예를 들어 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으로 변경했기 때문에 이를 위한 새롭고 별도의 프로세스가 있습니다. 이는 EFSP(Eclipse Foundation Specification Process)이며 Eclipse 개발 프로세스의 확장입니다 .
그러나 대부분 "투명성, 개방성, 공유 부담과 공급업체 중립성"과 관련하여 몇 가지 중요한 차이점이 있습니다 .
예를 들어 EFSP 조직자는 공급업체 중립적인 협업 작업 그룹, 셀프 서비스 인증 프로세스, 능력주의로 운영 및 관리되는 조직을 구상합니다.
4.2. JSR
JCP에서 EE에 기능을 추가하는 첫 번째 단계는 JSR 또는 Java 사양 요청을 생성하는 것이었습니다. JSR은 EE 기능의 인터페이스와 약간 비슷했습니다 . JCP 집행 위원회는 완성된 JSR을 검토하고 승인한 후 JSR 기여자가 이를 코딩하여 커뮤니티에 제공합니다.
이에 대한 좋은 예는 JSR-339 ( JAX-RS) 입니다. JAX- RS는 원래 2011년에 제안되어 2012년 JCP의 승인을 받고 2013년에 최종 출시되었습니다.
사양이 논의되는 동안 커뮤니티는 항상 의견을 나눌 수 있었지만 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에 대한 모든 테스트를 통과해야 합니다. 여기에는 큰 변화가 없습니다. Oracle은 TCK와 EE JSR을 오픈 소스로 제공했습니다. 물론 향후 모든 문서와 TCK는 오픈 소스가 될 것입니다.
5. 결론
Java EE는 확실히 그 기간 동안 많이 발전했습니다. 계속해서 변화하고 발전하는 모습이 보기 좋습니다.\
앞으로 많은 과제가 남아 있으니 원활한 전환(Transition)을 바라겠습니다.