JEP 320: Remove the Java EE and CORBA Modules

개요

java SE Platform 및 JDK에서 Java EE 및 CORBA 모듈을 제거합니다. 이 모듈은 Java SE 9 에서는 향후 릴리스에서 제거하겠다고 선언 된 데 대해 더 이상 사용되지 않습니다.

이유

Java SE 6 에는 Java 개발자의 편의를 위해 완전한 웹 서비스 스택이 포함되어 있습니다.
이 스택은 원래 Java EE 플랫폼 용으로 개발 된 기술로 JAX-WS (XML 기반 웹 서비스 용 Java API), JAXB (XML 바인딩 용 Java 아키텍처), JAF (JavaBeans Activation Framework) 및 Common Annotations . 포함 시점에 Java SE의 버전은 Java EE의 버전과 동일했지만 Java SE는 Java EE 보안 모델과 관련된 공통 주석의 패키지를 삭제했습니다.
그러나 시간이 지남에 따라 Java EE의 버전이 발전하면서 Java SE의 버전이 어려워졌습니다.

이 기술은 Java SE와 관련이없는 기능을 얻었습니다. 예를 들어 Common Annotations는 Java EE 컨테이너에서 Java EE 6의 데이터 소스와 관련된 패키지를 추가했습니다. 따라서 정기적으로 Java EE 버전을 스냅 샷하고 하위 집합 화해야했습니다. 이는 JDK 엔지니어에게는 시간이 많이 걸렸으며 개발자에게는 혼란을 야기했습니다.
이 기술은 java.net의 업스트림 프로젝트와 나중에 GitHub 에서 유지 관리되었습니다 . 이로 인해 OpenJDK 저장소의 Java SE 버전과 업스트림 저장소의 Java EE 버전을 동기화해야하기 때문에 유지 관리에 문제가있었습니다.
개발자가 업스트림 프로젝트에서 독립형 버전의 기술을 확보하고 승인 된 표준 오버라이드 메커니즘을 통해 배포 할 수있었습니다 . 이 오랜 메커니즘을 통해 독립 실행 형 버전에서 Java SE 버전을 안전하게 재정의 할 수있었습니다. 안타깝게도 실제로는 널리 사용되지 않았으며 개발자는 대신 독립 실행 형 버전을 JDK의 부트 스트랩 클래스 경로에 추가하거나 클래스 경로에 배치하고 결과로 분할 패키지가 생성되기를 기대하는 등의 임시 메커니즘을 사용했습니다. 문제를 일으키지 않습니다.

독립 실행 형 버전의 Java EE 기술은 Maven Central과 같은 타사 사이트에서 쉽게 사용할 수 있으므로 Java SE Platform이나 JDK에 포함시킬 필요가 없습니다.

Ken Cavanaugh의 독보적 인 리더십 아래에서 Java SE 는 OMG CORBA API, ORB 구현, CosNaming 구현, 컴파일러 및 IDL 및 IIOP에 대한 지원을 제공 하여 CORBA 를 포용idlj 했습니다. rmic컴파일러. 그러나 시간이 지남에 따라 CORBA에 대한 지원은 문제가되었습니다.

CORBA는 Java Community Process 외부에서 진화하는 “승인 된 표준”이기 때문에 JDK에서 CORBA를 유지 관리하고 JDK의 CORBA 구현을 안전하게 무시하는 기능에 웹 서비스와 비슷한 주석이 적용됩니다. JDK의 ORB를 Java EE 응용 프로그램 서버의 ORB와 동기화 할 실제적인 전망은 없습니다.
Java에서 CORBA를 사용하여 최신 응용 프로그램을 개발하는 데는 큰 관심이 없습니다. 또한 Java EE 8은 CORBA, RMI-IIOP 및 JavaIDL을 “제안 된 선택 사항”으로 나열하여 향후 이러한 기술에 대한 필수 지원이 중단 될 수 있음을 나타냅니다.

CORBA 지원을 유지 관리하는 비용이 그 이점보다 크므로 Java SE Platform이나 JDK가이를 포함하는 경우는 없습니다.

마지막으로 Java SE에는 Java SE 1.3부터 JTA (Java Transaction API)의 하위 집합과 Java SE 5.0부터 확장 트랜잭션을위한 J2EE 활동 서비스 (J2EE Activity Service) 의 하위 집합이 포함되어 있습니다.

JTA는 서로 다른 역할을하고 다른 치료를받을 자격이있는 두 가지 패키지로 구성됩니다.

javax.transaction.xa패키지는 JDBC에서 XA 트랜잭션을 지원합니다. 이 “ XA 패키지 “는 java.sqlJava SE 9 의 모듈에서 JDBC와 함께 배치됩니다 . java.sql모듈은 업그레이드 할 수 없으므로 독립 실행 형 버전의 JTA가 XA 패키지의 Java SE 버전을 무시할 수는 없지만 XA 패키지는 수년간 안정적이었으며 Java SE 버전은 Java EE 버전과 동일하므로 일반적으로 응용 프로그램에서 허용됩니다. 유지 보수를 용이하게하기 위해 Java SE의 XA 패키지는 향후 업그레이드 할 수없는 다른 모듈로 옮길 수도 있지만 아키텍처 측면에서 볼 때 장기간 JDBC와 함께 Java SE에 남아있을 것이며 더 이상 관심을 가질 필요가 없습니다
이 javax.transaction패키지는 일반적인 트랜잭션 관리 API를 정의합니다. 이 패키지의 Java EE 버전은 항상 Java SE의 범위를 벗어 났으며 Java SE와 관련이없는 방식으로 발전했습니다. 예를 들어 JTA는 CDI와 관련된 Java EE 7의 유형을 추가했습니다 . javax.transactionJava SE에 의해 정의 된 서브 세트는 CORBA 트랜잭션 서비스와의 상호 운용을 지원합니다. 이 “ CORBA interop 패키지 “ java.transaction는 Java SE 9 의 자체 모듈에 있습니다. 그러나 Java SE 버전은 일반적으로 CORBA 트랜잭션 서비스를 사용하는 응용 프로그램에서 허용되지 않으므로 일반적으로 Java SE 버전으로 대체합니다

J2EE Activity Service는 일반적인 미들웨어 API를 정의합니다. 2006 년부터 업데이트되지 않았으며 Java EE 플랫폼의 일부가 아닙니다. Java SE에는 javax.activityCORBA 트랜잭션 서비스와의 상호 운용을 위해 패키지 중 하나의 하위 집합이 포함되어 있기 때문에이 JEP와 관련이 있습니다. 이 “ 활동 패키지 “ java.corba는 Java SE 9 의 모듈에 있습니다.

Java SE Platform 또는 JDK에서 CORBA를 지원하지 않으면 JTA의 CORBA interop 패키지 또는 J2EE Activity Service의 활동 패키지를 포함 할 수 없습니다.

내용

Java SE 9에서 Java EE 및 CORBA 기술이 포함 된 Java SE 모듈 은 제거 용 으로 주석 처리되어 다음 릴리스에서 제거하려고합니다.

java.xml.ws(JAX-WS, 관련 기술 SAAJ 및 웹 서비스 메타 데이터 )
java.xml.bind (JAXB)
java.activation (JAF)
java.xml.ws.annotation (Common Annotations)
java.corba (CORBA)
java.transaction (JTA)

Java SE 9의 모듈도 제거 됩니다.

java.se.ee (Aggregator module for the six modules above)
jdk.xml.ws (Tools for JAX-WS)
jdk.xml.bind (Tools for JAXB)

제거를위한 모듈을 비난하면 컴파일 시간 경고가 발생하기 때문에 JDK 9는 개발자가 다음 릴리스에서이 모듈을 실제로 제거 할 수 있도록 준비하기 위해보다 강력한 단계를 밟았 습니다. 클래스 경로의 코드를 컴파일 할 때 모듈이 JDK 9에서 해결되지 않았습니다. 또는 실행하십시오 . 따라서 JDK 9의 개발자는 JDK 8과 마찬가지로 클래스 경로에 Java EE 및 CORBA 기술의 독립 실행 형 버전을 배포 할 수 있습니다. JDK 9의 개발자 –add-modules는 명령 줄 의 플래그를 사용 하여 JDK 런타임의 모듈을 확인할 수 있습니다

이 JEP는 위에 나열된 9 개의 모듈을 제거합니다.

그들의 소스 코드는 OpenJDK 저장소에서 삭제 될 것이다.
해당 클래스는 JDK 런타임 이미지에 존재하지 않습니다.
해당 도구는 더 이상 사용할 수 없습니다.
- wsgen및 wsimport(에서 jdk.xml.ws)
- schemagen및 xjc(에서 jdk.xml.bind)
- idlj, orbd, servertool, 및 tnamesrv(발 java.corba)
JNDI CosNaming공급자 (에서 java.corba)는 더 이상 사용할 수 없습니다.
–add-modulesJDK 9에서 와 같이 명령 행 플래그를 사용 가능하게 설정할 수 없습니다.

rmic컴파일러는 제거 업데이트됩니다 -idl및 -iiop옵션을. 결과적으로 rmicIDL 또는 IIOP 스텁과 타이 클래스를 더 이상 생성 할 수 없습니다.

JDK 문서 와 사람이 페이지는 이러한 모듈 및 도구에 대한 참조를 제거하고 표시하기 위해 업데이트됩니다 rmic변경.

삭제 되었을때의 문제

Java EE 모듈

Java EE 모듈을 제거하는 위험은 Java EE API 및 도구 용 JDK에서 “기본적으로”지원되는 경우 응용 프로그램이 컴파일되거나 실행되지 않는다는 것입니다. 이 응용 프로그램은 JDK 6, 7 또는 8에서 JDK 9 또는 이후 릴리스로 마이그레이션 할 때 바이너리 및 소스 비 호환성을 경험합니다. 일반적으로 이러한 응용 프로그램은 두 가지 범주 중 하나로 분류됩니다.

Java EE 애플리케이션 서버 외부에서 웹 서비스 및 XML을 조작하는 독립형 프로그램.
웹 서비스 또는 XML에 연결되지 않지만 범용 기능을 위해 Java EE API의 개별 클래스에 의존하는 응용 프로그램. 예를 들어, 일부 애플리케이션은 XML 바인딩이 아닌 JAXB를 기반으로하며, 클래스가 제공하는 Base64 지원을 사용합니다 javax.xml.bind.DatatypeConverter. (역사적으로,이 클래스는 클래스보다 더 나은 선택 sun.misc.Base64{Encoder,Decoder}이었지만 java.util.Base64Java SE 8에서 소개 된 클래스가 더 나았습니다. ) 또 다른 예로, 일부 응용 프로그램은 JAX-WS와 같은 위치에 @Generated있는 유형 인 주석에 의존합니다 javax.annotation.GeneratedJDK 9에서는 ( javax.annotation.processing.Generated Java SE 9에 도입 된 유형에 의존하는 대신 응용 프로그램을 선택할 수 있습니다 .)

자바 EE 모듈을 제거하는 또 다른 위험은 명령 줄 플래그를 사용하는 경우 이미 JDK 9 일에, JDK 6, 7, 8에서 이주 된 응용 프로그램이 시작되지 것입니다 –add-modules java.se.ee, –add-modules java.xml.bind등

이 제안은 최신 JDK에서 응용 프로그램을 컴파일하거나 실행하려는 개발자가 Java EE 기술의 대체 버전을 찾아 배포 할 수 있다고 가정합니다. JAX-WS와 JAXB의 RI (Reference Implementation)는 JDK 9의 모듈 java.xml.ws및 java.xml.bind모듈을 완전히 대체하기 때문에 좋은 출발점입니다 . RI는 Maven 아티팩트로 사용할 수 있습니다 (클래스 경로에 배포해야 함)

com.sun.xml.ws : jaxws-ri (JAX-WS, SAAJ 및 웹 서비스 메타 데이터)
com.sun.xml.bind : jaxb-ri (JAXB)

Java EE 기술의 API 만 포함하는 Maven 아티팩트도 있습니다.

javax.xml.ws : jaxws-api (JAX-WS, javax.xml.soap : SAAJ에서는 javax.xml.soap-api , Web Services Metadata에서는 javax.xml : webservices-api )
javax.xml.bind : jaxb-api (JAXB)
javax.activation : javax.activation-api (JAF)
javax.annotation : javax.annotation-api (Common Annotations)

이 JEP가 구현 된 후에는 JDK 8 및 9와 마찬가지로이 API JAR 파일을 클래스 경로에 배치 할 수 있습니다. 또한 모듈 경로에 배치하여 모듈 응용 프로그램 이 requires지시문을 통해 의존 할 수있게 합니다.

JAX-WS, JAXB와 SAAJ의 API JAR 파일이라는 명시 적 모듈입니다 java.xml.ws, java.xml.bind하고 java.xml.soap.
웹 서비스 메타 데이터 용 API JAR 파일은 호출되는 자동 모듈 webservices.api입니다. JAR 매니페스트가 Automatic-Module-Name특성 으로 업데이트되지 않았으므로이 이름은 JAR 파일 이름에서 파생됩니다.
JAF 및 공통 주석에 대한 API JAR 파일이라는 자동 모듈입니다 java.activation와 java.annotation. (이러한 이름은 Automatic-Module-NameJAR 매니페스트 의 속성에 의해 지정됩니다.)

JDK 9에서는 설명에 언급 된 모든 모듈 ( java.se.ee어 그리 게이터 제외 )이 업그레이드 가능 합니다. 즉, JDK 9의 개발자 –add-modules java.xml.bind는 JDK 런타임 이미지의 Java EE 모듈을 사용하거나 업그레이드 모듈 경로 에 API JAR 파일을 배포하여 무시할 수 있습니다 . 모듈 경로가 아닌 업그레이드 모듈 경로 의 개입에 유의하십시오 . JDK 9의 모듈 경로에 API JAR 파일을 배포해도 아무런 영향을 미치지 않습니다.–add-modules java.xml.bindJDK 런타임 이미지의 Java EE 모듈은 모듈 경로에서 동일한 이름을 가진 모듈보다 선호되기 때문에 Java EE 등이 사용됩니다. 이 JEP가 구현 된 후에는 Java EE 모듈이 JDK 런타임 이미지에 나타나지 않으므로 개발자는 모듈 경로에 API JAR 파일을 배포 할 수 있습니다.

CORBA 및 JTA 모듈

java.corba모듈 제거의 위험 은 다음과 같습니다.

「보증 된」CORBA API 의 부분 집합 만이 포함되어 있어 JDK가 나머지를 제공하는 경우, CORBA 구현은 컴파일 또는 실행되지 않습니다 .
RMI-IIOP를 사용하는 응용 프로그램 및 CORBA 구현은 컴파일되거나 실행되지 않습니다. RMI-IIOP 패키지 ( javax.rmi및 javax.rmi.CORBA)는 java.corba모듈에있어 CORBA 구현과 관련 지을 수 있기 (위해) 때문에, Java SE에서는 RMI-IIOP가 일절 지원되지 않게 java.corba됩니다.
javax.activity패키지 를 사용하는 응용 프로그램 및 CORBA 구현은 컴파일되거나 실행되지 않습니다. 이 패키지는 java.corba모듈에있어 CORBA 구현과 관련 지을 수 있으므로 일단 java.corba제거 되면 Java SE에서는 지원되지 않습니다 .

타사가 CORBA API, ORB 구현, CosNaming 공급자 등의 유지 관리를 대신하지 않는 한 독립 실행 형 버전의 CORBA는 존재하지 않습니다. Java SE 플랫폼이 CORBA의 독립적 구현을 보증하므로 타사 유지 관리가 가능합니다. 반대로, RMI-IIOP 용 API는 Java SE 내에서만 정의되어 구현됩니다. 전용 JSR을 유지 관리하기 시작하거나 Eclipse Foundation에서 API의 관리를 대신하지 않으면 RMI-IIOP의 독립형 버전이 제공되지 않습니다. JCP에서 Eclipse Foundation으로 Java EE의 책임주의 전환에는 CORBA 및 RMI-IIOP의 GlassFish 구현이 포함됩니다 . 마지막으로, 독립 실행 형 버전의 J2EE Activity Service는 없습니다.

독립 실행 형 JTA 버전은 Maven 아티팩트 javax.transaction : javax.transaction-api 로 사용할 수 있습니다 . 2017 년 11 월 현재이 JAR 파일은 XA 패키지와 CORBA interop 패키지로 구성된 JTA 1.2를 나타냅니다. 2018 년 초 JTA 1.3은 CORBA interop 패키지로만 정의 될 것입니다. 그에 따라 JAR 파일이 업데이트됩니다. JTA 1.2 및 JTA 1.3 용 JAR 파일은 다음과 같이 배포 할 수 있습니다.

JTA 1.2 용 JAR 파일은 클래스 경로에 배치 될 수 있습니다. (JAR 파일의 XA 패키지는 java.sql모듈 의 XA 패키지를 위해 무시됩니다 .JAR 파일 의 CORBA interop 패키지는 java.transaction모듈 의 패키지보다 우선 사용됩니다.이 패키지는 기본적으로 JDK 9에서 확인되지 않습니다. 경우에 것을 –add-modules java.se.ee또는 –add-modules java.transactionJDK (9)에 사용되는 다음 JAR 파일의 CORBA의 상호 운용성 패키지는에서 패키지에 찬성 무시됩니다 java.transaction모듈.)
JTA 1.2 용 JAR 파일은 모듈 경로에 배포 할 수 없습니다. (이는 XA 패키지가 포함 된 자동 모듈로 취급되지만이 패키지는 java.sql모듈 의 XA 패키지와 충돌 합니다.)
JTA 1.3 용 JAR 파일은 클래스 경로에 배치 될 수 있습니다. JAR 파일의 CORBA interop 패키지는 java.transaction모듈 의 패키지보다 우선 사용됩니다.이 패키지는, JDK 9에서는 디폴트로 해결되지 않습니다.
JTA 1.3 용 JAR 파일은 모듈 경로에 배포되어 호출되는 자동 모듈로 사용될 수 있습니다 java.transaction.