논쟁을 위해 Java 8 (및 이전 버전)에 이미 모듈 (jars) 및 모듈 시스템 (클래스 경로)의 “형식” 이 있다고 가정 해 보겠습니다 . 그러나 이것들에는 잘 알려진 문제가 있습니다.

문제를 조사하여 Jigsaw의 동기를 설명 할 수 있습니다. (다음은 확실히 솔루션을 제공하는 OSGi, JBoss 모듈 등을 사용하지 않는다고 가정합니다.)

문제 1 : 공개가 너무 공개적입니다

다음 클래스를 고려하십시오 (둘 다 공용이라고 가정).

com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl

Foo.com에서, 우리는 우리의 팀이 사용하도록 결정할 수 있습니다 UserDao사용하지UserDaoImpl 직접 있습니다. 그러나 클래스 경로에 적용 할 수있는 방법은 없습니다.

Jigsaw에서 모듈에는 module-info.java다른 모듈에 공개 된 내용을 명시 적으로 지정할 수 있는 파일이 포함되어 있습니다 . 즉, 대중에는 뉘앙스가 있습니다. 예를 들면 :

// com.acme.foo.db.api.UserDao is accessible, but
// com.acme.foo.db.impl.UserDaoImpl is not 
module com.acme.foo.db {
    exports com.acme.foo.db.api;
}

문제 2 : 반성이 자유 롭다

# 1의 클래스를 감안할 때 누군가 Java 8에서 여전히이 작업을 수행 할 수 있습니다.

Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();

즉, 리플렉션은 강력하고 필수적이지만 선택하지 않으면 바람직하지 않은 방식으로 모듈의 내부에 도달하는 데 사용될 수 있습니다. Mark Reinhold는 다소 놀라운 예가 있습니다. (SO 포스트는 여기에 있습니다 .)

Jigsaw에서 강력한 캡슐화 는 리플렉션을 포함하여 클래스에 대한 액세스를 거부하는 기능을 제공합니다. (이는 JDK 9에 대한 수정 된 기술 사양을 기다리는 동안 명령 줄 설정에 따라 달라질 수 있습니다.) JDK 자체에 Jigsaw가 사용되기 때문에 Oracle은 이것이 Java 팀이 플랫폼 내부를 더 빠르게 혁신 할 수 있도록 할 것이라고 주장합니다.

문제 3 : 클래스 경로가 아키텍처 관계를 지 웁니다.

팀은 일반적으로 항아리 간의 관계에 대한 정신 모델을 가지고 있습니다. 예를 들어, foo-app.jar사용할 수 foo-services.jar있는 용도 foo-db.jar. 의 클래스는 foo-app.jar“서비스 계층”을 우회하여 foo-db.jar직접 사용해서는 안된다고 주장 할 수 있습니다. 그러나 클래스 경로를 통해이를 강제하는 방법은 없습니다. Mark Reinhold는 여기에서 이것을 언급 합니다 .

이에 비해 Jigsaw는 모듈에 대해 명시적이고 신뢰할 수있는 접근성 모델을 제공합니다.

문제 4 : 모 놀리 식 런타임

자바 런타임은 모 놀리 식 rt.jar. 내 컴퓨터에서는 20k 클래스로 60MB 이상입니다! 마이크로 서비스, IoT 장치 등의 시대에 Corba, Swing, XML 및 기타 라이브러리를 사용하지 않는 경우 디스크에 두는 것은 바람직하지 않습니다.

Jigsaw는 JDK 자체 를 여러 모듈로 나눕니다 . 예를 들어 java.sql 에는 익숙한 SQL 클래스가 포함되어 있습니다. 여기에는 몇 가지 이점이 있지만 새로운 것이 jlink도구입니다. 앱이 완전히 모듈화되었다고 가정하고 지정된 모듈 (및 해당 종속성) 만 포함하도록 잘린 배포 가능한 런타임 이미지 를 jlink생성합니다 . 오라클 은 JDK 모듈이 사전에 네이티브 코드로 컴파일 되는 미래를 구상하고 있습니다 . 비록 선택 사항이며, AOT 컴파일 실험, 그들은 오라클이 향하고 곳의 주요 징후이다.jlink

문제 5 : 버전 관리

예 :이 클래스 패스는 우리가 여러 같은 항아리의 버전을 사용하는 것을 허용하지 않는다는 것을 잘 알려져있다 bar-lib-1.1.jar및 bar-lib-2.2.jar.

Jigsaw는이 문제를 해결하지 않습니다. Mark Reinhold는 여기 에 근거를 설명합니다 . 요점은 Maven, Gradle 및 기타 도구가 종속성 관리를위한 대규모 생태계를 나타내며 다른 솔루션이 유익하기보다는 더 해롭다는 것입니다.

다른 솔루션 (예 : OSGi)은 실제로이 문제를 해결합니다 (4 번을 제외한 다른 솔루션).

결론

이것은 특정 문제에 의해 동기가 부여 된 Jigsaw의 핵심 포인트입니다.

Jigsaw, OSGi, JBoss 모듈 등 간의 논쟁을 설명하는 것은 다른 Stack Exchange 사이트에 속하는 별도의 토론입니다. 여기에 설명 된 것보다 솔루션간에 더 많은 차이점이 있습니다. 또한 JSR 376에 대한 공개 검토 재검토 투표 를 승인하기에 충분한 합의가있었습니다 .