Java 9에서 패키지와 모듈이 별도의 개념 인 이유는 무엇입니까?

Java 9에는 패키지 외에도 모듈이 있습니다. 일반적으로 언어에는 둘 중 하나가 있습니다. 그리고 대부분의 프로그래머 는 두 용어를 동의어로 인식 합니다. 모듈은 패키지 위에 구축되어 기본 요소로 취급합니다. 복합 패턴은 프리미티브 및 복합 재료를 균일하게 처리 할 것을 제안합니다. 그렇지 않으면 나쁜 일이 일어날 것입니다. 예를 들어, Valhalla 프로젝트를보고 기본 (값) 및 참조 유형에 공통 수퍼 타입을 개조하려고합니다.

모듈과 패키지는 의미 상 분리 된 개념을 나타 냅니까? 모든 언어에 대해 두 가지를 모두 갖는 것이 합리적이라는 것을 의미합니다 (문제의 분리). 아니면 Java는 이전 버전과의 호환성에 대한 찬사를 가지고 있어야합니까?

기존 개념을 보강하는 대신 새로운 개념을 도입하는 이유는 무엇입니까?

JSR 376 : 프로젝트 내에서 구현 "자바 플랫폼 모듈 시스템" 지그 소 퍼즐 .

SOTMS 에 따르면

모듈은 명명 된 자체 설명 코드 및 데이터 모음입니다. 코드는 유형, 즉 Java 클래스 및 인터페이스를 포함하는 패키지 세트로 구성됩니다. 데이터에는 리소스 및 기타 종류의 정적 정보가 포함됩니다.

JLS는 패키지 정의를 신중하게 피 합니다 . 에서 위키 백과 :

Java 패키지는 Java 클래스를 Modula 모듈과 유사한 네임 스페이스로 구성하여 Java로 모듈 식 프로그래밍을 제공하는 기술입니다.

Wikipedia를 인용하는 것은 나쁜 습관이지만 일반적인 이해를 반영한다는 것을 알고 있습니다. 에서 입력 모듈 프로그래밍에 대한 :

패키지 라는 용어 는 모듈 대신에 사용됩니다 (Dart, Go 또는 Java에서와 같이). 다른 구현에서, 이것은 별개의 개념입니다. 파이썬에서 패키지는 모듈의 모음이며, 향후 Java 9에서는 새로운 모듈 개념 (향상된 액세스 제어 기능을 가진 패키지 모음)의 도입이 계획되어 있습니다.

모듈 의 개념 은 해당 개념의 인스턴스화와 다릅니다.

Java에는 항상 모듈이 있습니다. 메소드는 모듈이며 클래스도 패키지입니다. 모듈은 내부 세부 정보가 숨겨져 있고 계약에 따라 다른 모듈과 통신하는 조직 단위입니다. 예를 들어, 메서드에는 숨겨진 내부 (코드 및 로컬 변수)와 계약 (매개 변수 및 반환 형식)이 있으므로 모듈입니다. 모듈은 하위 레벨 모듈로 구성 될 수 있습니다 (예 : 클래스에 메소드 포함).

핵심 Java (9 이전)에서 누락 된 것은 배포 가능한 모듈입니다. 위의 모든 종류의 모듈은 복사 할 수있는 배치 가능한 장치가 아닙니다. Java에는 JAR 파일이라는 배치 가능한 아티팩트가 있지만 캡슐화 또는 계약이 없기 때문에 모듈이 아닙니다. 런타임시 JAR 파일이 모두 사라지고 단일 "classpath"로 병합됩니다.

OSGi 는 1998 년에 "번들"이라는 개념으로 배포 가능한 모듈의 부족을 해결했습니다. 이들은 실제 JAR 파일이며 패키지를 포함하지만 OSGi는 런타임 시스템과 함께 추가 메타 데이터를 정의하여 해당 레벨에서 캡슐화 및 계약을 지원합니다.

Java 9는 OSGi와 유사한 방식으로 배포 가능한 모듈이없는 문제를 해결합니다. 아마도 OSGi가 존재하고 작동하기 때문에 이것은 완전히 불필요하지만 완전히 다른 토론입니다 ...

불행히도 Java 9는 새로운 모듈 개념을 "모듈"이라고 명명함으로써 물을 혼동합니다. 이것은 메소드, 클래스 및 패키지가 모듈이되는 것을 멈추는 것을 의미하지는 않습니다! J9 "모듈"은 모듈 개념 의 또 다른 인스턴스입니다 . OSGi 번들과 마찬가지로 J9 모듈은 패키지로 구성되며 복사 할 수있는 물리적 아티팩트 (일반적으로 JAR 파일)입니다. 런타임 시스템은이를 이해하고 재조정합니다.

요약 : 예 J9 모듈과 패키지는 의미 상 분리 된 개념입니다. 분명히 Java는 이전 버전과의 호환성을 위해 기존 패키지 개념을 유지해야합니다. "package"라는 단어는 다른 언어 나 RPM과 같은 패키지 관리 시스템과는 Java에서 상당히 다르게 사용됩니다. 새로운 J9 모듈 (및 OSGi 번들)은 Java 패키지보다 RPM 패키지와 훨씬 유사합니다.

대부분 가정이나 머리카락 쪼개기 / 보충 등이있을 수 있지만 대답 할 때 위험에 처하게하겠습니다.

그들은 같은 것입니까? 음, 예 ^_와 아니오

에서 "자바 9 모듈화"에 대한이 JavaWorld 기사 :

모듈 식 솔루션으로 패키지

패키지는 Java 프로그래밍 환경에 추상화 레벨을 추가하려고합니다. 고유 한 코딩 네임 스페이스 및 구성 컨텍스트를위한 기능을 제공합니다. 그러나 안타깝게도 패키지 규칙이 우회되어 위험한 컴파일 타임 커플 링 환경으로 이어지는 경우가 많습니다.

@ user2418306 (OP)이 암시 한 것처럼 " 모듈은 올바르게 수행 된 패키지입니다 " . Java의 모듈과 패키지 (Java 9부터)는 의미 적 으로 OP와 마찬가지로 의미 상 동일합니다. 즉, 그들은 미리 컴파일 된 JVM 바이트 코드의 모음입니다 다른 메타 데이터와 함께 - 기본적으로 , 그들이 도서관 .

차이점은 무엇입니까?

그러나 차이점은 각각의 메타 데이터 에 있습니다. Java package매니페스트 또는 JAR 매니페스트는 종종 라이브러리 개발자가 유지 관리하지 않으며 JAR / 패키지가 제공하는 내용에 대한 확실한 계약을 제공하지도 않습니다. 여기에 설명 된 대로 (JavaWorld 기사 다시) :

JAR 파일이 모듈 식으로 충분하지 않습니까?

JAR 파일 및 이들이 작동하는 배치 환경은 사용 가능한 많은 레거시 배치 규칙에서 크게 개선됩니다. 그러나 JAR 파일은 .jar 매니페스트에 숨겨져 거의 사용되지 않는 버전 번호를 제외하고 고유 한 고유성을 갖지 않습니다. JAR 파일 및 선택적 매니페스트는 Java 런타임 환경에서 모듈화 규칙으로 사용되지 않습니다. 따라서 파일에있는 클래스의 패키지 이름과 클래스 경로에 대한 참여는 런타임 환경에 모듈성을 제공하는 JAR 구조의 유일한 부분입니다.

다른 언어 / 환경 등에 대한 불만

이 기사에서 논의 된 또 다른 영역 은 빌드 프로세스의 일부로 종속성을 관리하는 Maven 과 같은 시스템 입니다. 에서 아파치 메이븐 사이트의 페이지 :

의존성 관리 :

Maven은 JAR 및 기타 종속성의 중앙 저장소를 사용하도록 권장합니다. Maven은 프로젝트 클라이언트가 Perl의 CPAN과 같은 중앙 JAR 저장소에서 프로젝트를 빌드하는 데 필요한 JAR을 다운로드하는 데 사용할 수있는 메커니즘을 제공합니다. 이를 통해 Maven 사용자는 프로젝트 전체에서 JAR을 재사용하고 프로젝트 간 통신을 장려하여 이전 버전과의 호환성 문제를 해결할 수 있습니다.

마치 내가 있었던 것처럼 미래에 대해 이야기

으로 해당 페이지가 언급 (예 : Perl과 같은) 다른 언어 (같은 패키지 저장소가 CPAN을 ). 이것은 지난 수십 년 동안 점점 증가하는 추세입니다 (나는 어떤 증거도없이 느낌이 들기 때문에). 루비의 같은 도구 보석 , 파이썬의 PyPi 하고, 노드 패키지 관리자 ( npm) 이시 빌드가 오른쪽과 환경 (중 개발, 빌드, 테스트 또는 런타임 등) 구성의 일관성있는 방법으로 제공하는 물건 (패키지, 모듈 보석, 기즈모 등). 아이디어는 (I 느낌)했다 " 빌린 " 데비안의 같은 리눅스 (Linux®) 분배 시스템에서 APT , 레드햇의rpm등이 있습니다 (물론 적어도 한 세대를 진화 시켜서 이러한 것들을 모두 더 멋지게 만들었습니다.)

Java 모듈 은 이미 수행 할 수없는 것을 추가 할 필요는 없지만 종속성 / 패키지 관리 및 자동화 된 빌드 환경을위한 툴링을 훨씬 쉽게 만듭니다. 그것이 모듈을 "더 좋게"만들 었는지 여부에 대해서는 말하기를 거부합니다. :피