Tại sao các gói và mô-đun là các khái niệm riêng biệt trong Java 9?

Java 9 sẽ có các mô đun ngoài các gói. Thông thường các ngôn ngữ có một hoặc khác. Và hầu hết các lập trình viên đều coi hai thuật ngữ là từ đồng nghĩa. Các mô-đun được xây dựng trên đầu của các gói, coi chúng là nguyên thủy. Mô hình tổng hợp gợi ý để điều trị nguyên thủy và vật liệu tổng hợp. Nếu không những điều xấu sẽ xảy ra. Ví dụ, nhìn vào dự án Valhalla, nơi họ cố gắng trang bị thêm siêu kiểu phổ biến cho các kiểu nguyên thủy (giá trị) và tham chiếu.

Là các mô-đun và gói đại diện cho các khái niệm riêng biệt về ngữ nghĩa? Có nghĩa là nó hợp lý để có cả hai cho bất kỳ ngôn ngữ (tách mối quan tâm). Hoặc Java phải có cả hai như một sự tôn vinh cho khả năng tương thích ngược?

Tại sao lại giới thiệu khái niệm mới thay vì tăng cường khái niệm hiện có?

JSR 376 : "Hệ thống mô-đun nền tảng Java" được triển khai trong Dự án Jigsaw .

Theo SOTMS

Một mô-đun là một bộ sưu tập mã và dữ liệu tự mô tả. Mã của nó được tổ chức dưới dạng một tập hợp các gói chứa các kiểu, tức là các lớp và giao diện Java; dữ liệu của nó bao gồm các tài nguyên và các loại thông tin tĩnh khác.

JLS cẩn thận tránh xác định gói là gì . Từ Wikipedia :

Gói Java là một kỹ thuật để tổ chức các lớp Java thành các không gian tên tương tự như các mô-đun của Modula, cung cấp lập trình mô-đun trong Java.

Tôi biết rằng trích dẫn Wikipedia là một thực tiễn xấu, nhưng nó phản ánh sự hiểu biết chung. Từ mục nhập vào lập trình mô-đun:

Gói thuật ngữ đôi khi được sử dụng thay vì mô-đun (như trong Dart, Go hoặc Java). Trong các triển khai khác, đây là một khái niệm khác biệt; trong Python một gói là một tập hợp các mô-đun, trong khi trong Java 9 sắp tới, việc giới thiệu khái niệm mô-đun mới (một tập hợp các gói có kiểm soát truy cập nâng cao) được lên kế hoạch.

Các khái niệm của một module khác với instantiation của khái niệm đó.

Java luôn có các mô-đun. Một phương thức là một mô-đun, một lớp cũng vậy và một gói. Một mô-đun là một đơn vị tổ chức trong đó các chi tiết nội bộ được ẩn đi và giao tiếp với các mô-đun khác thông qua các hợp đồng đã thỏa thuận. Ví dụ, một phương thức là một mô-đun vì nó có các phần bên trong ẩn (mã và biến cục bộ) và một hợp đồng (các tham số và kiểu trả về). Các mô-đun có thể được tạo thành từ các mô-đun cấp thấp hơn, ví dụ các lớp chứa các phương thức.

Cái còn thiếu trong lõi Java (trước 9) là một mô-đun có thể triển khai . Tất cả các loại mô-đun trên không phải là đơn vị có thể triển khai có thể được sao chép xung quanh. Java có một tạo phẩm có thể triển khai được gọi là tệp JAR, nhưng đây không phải là các mô-đun vì chúng không được đóng gói hoặc hợp đồng: tại các tệp JAR thời gian chạy biến mất, tất cả hợp nhất với nhau thành một "đường dẫn lớp".

OSGi đã giải quyết việc thiếu các mô-đun có thể triển khai vào năm 1998 với khái niệm "gói". Đây là các tệp JAR vật lý và chúng chứa các gói, nhưng OSGi định nghĩa siêu dữ liệu bổ sung cùng với hệ thống thời gian chạy để hỗ trợ đóng gói và hợp đồng ở mức đó.

Java 9 giải quyết việc thiếu các mô-đun có thể triển khai theo cách tương tự như OSGi. Có thể cho rằng điều này là hoàn toàn không cần thiết vì OSGi tồn tại và hoạt động, nhưng đó là một cuộc thảo luận hoàn toàn khác ...

Thật không may, Java 9 làm vấy bẩn vùng biển bằng cách đặt tên khái niệm mô-đun mới chỉ là một "mô-đun". Điều này không có nghĩa là các phương thức, lớp và gói ngừng là các mô-đun! Một "mô-đun" J9 chỉ là một khởi tạo khác của khái niệm mô-đun . Giống như các gói OSGi, các mô-đun J9 được tạo ra từ các gói và chúng là các tạo phẩm vật lý (thường là các tệp JAR một lần nữa) có thể được sao chép xung quanh. Hệ thống thời gian chạy hiểu và thống nhất chúng.

Tóm tắt: có các mô-đun và gói J9 là các khái niệm riêng biệt về mặt ngữ nghĩa. Rõ ràng Java phải giữ lại khái niệm gói hiện có để tương thích ngược. Lưu ý rằng từ "gói" được sử dụng hoàn toàn khác trong Java so với các ngôn ngữ khác hoặc trong các hệ thống quản lý gói như RPM. Các mô-đun J9 mới (và các gói OSGi) giống như các gói trong RPM hơn các gói Java từng có.

Hãy để tôi gặp nguy hiểm khi trả lời, mặc dù phần lớn trong số đó có thể là giả định / chẻ sợi tóc / tán tụng, v.v.

Họ là những điều tương tự? Vâng, có ^_và không

Từ bài viết JavaWorld này về "Tính mô đun trong Java 9" :

Gói như một giải pháp mô-đun

Các gói cố gắng thêm một mức độ trừu tượng cho bối cảnh lập trình Java. Họ cung cấp các phương tiện cho các không gian tên mã hóa và bối cảnh cấu hình độc đáo. Đáng buồn thay, mặc dù, các quy ước gói dễ dàng bị phá vỡ, thường dẫn đến một môi trường của các khớp nối thời gian biên dịch nguy hiểm.

Như @ user2418306 (OP) gợi ý, " các mô-đun là các gói được thực hiện đúng " . Các mô-đun và gói trong Java (như Java 9, rõ ràng) là (như OP yêu cầu) về mặt ngữ nghĩa giống nhau. Đó là, chúng là các bộ sưu tập mã byte JVM được biên dịch trước, với các siêu dữ liệu khác - về cơ bản , chúng là các thư viện .

Vâng, sự khác biệt là gì?

Tuy nhiên, sự khác biệt nằm ở siêu dữ liệu bên trong mỗi chúng. Các bảng packagekê khai Java , hoặc các bảng kê khai JAR, thường không được các nhà phát triển thư viện duy trì, họ cũng không cung cấp bất kỳ hợp đồng chắc chắn nào về những gì JAR / gói cung cấp. Như đã giải thích ở đây (bài viết JavaWorld một lần nữa) :

Các tệp JAR không đủ mô-đun?

Các tệp JAR và môi trường triển khai trong đó chúng hoạt động cải thiện đáng kể trên nhiều quy ước triển khai cũ. Nhưng các tệp JAR không có tính duy nhất nội tại, ngoài số phiên bản hiếm khi được sử dụng, được ẩn trong một bảng kê khai .jar. Tệp JAR và tệp kê khai tùy chọn không được sử dụng làm quy ước mô đun hóa trong môi trường thời gian chạy Java. Vì vậy, tên gói của các lớp trong tệp và sự tham gia của chúng vào đường dẫn lớp là các phần duy nhất của cấu trúc JAR cho vay mô đun hóa vào môi trường thời gian chạy.

Một lời ca ngợi về các ngôn ngữ / môi trường khác, v.v.

Một lĩnh vực khác được thảo luận trong bài viết đó là các hệ thống như Maven , nơi quản lý các phụ thuộc cho bạn như một phần của quá trình xây dựng. Từ trang này trên trang web Apache Maven :

Quản lý phụ thuộc:

Maven khuyến khích sử dụng kho lưu trữ trung tâm của JAR và các phụ thuộc khác. Maven đi kèm với một cơ chế mà khách hàng của dự án của bạn có thể sử dụng để tải xuống bất kỳ JAR nào cần thiết để xây dựng dự án của bạn từ kho lưu trữ JAR trung tâm giống như CPAN của Perl. Điều này cho phép người dùng Maven sử dụng lại các JAR trong các dự án và khuyến khích liên lạc giữa các dự án để đảm bảo rằng các vấn đề tương thích ngược được xử lý.

Bây giờ để nói về tương lai như thể tôi đã ở đó

Như trang đó đã đề cập, các ngôn ngữ khác (như Perl), có kho lưu trữ gói (như CPAN ). Đây là một xu hướng ngày càng tăng (tôi nói bởi vì tôi cảm thấy thích nó, không có bằng chứng rõ ràng nào), trong hơn ~ thập kỷ qua. Các công cụ như đá quý của Ruby , PyPi của Python và trình quản lý gói Node ( npm) được xây dựng dựa trên điều này để cung cấp một cách nhất quán để định cấu hình một môi trường (phát triển, xây dựng, kiểm tra hoặc thời gian chạy, v.v.) với các công cụ phù hợp (gói, mô-đun, đá quý, gizmo, vv). Một ý tưởng (tôi cảm thấy) đã được " mượn " từ các hệ thống phân phối Linux® như apt của Debian , RedHat'srpm, v.v. (Mặc dù, rõ ràng, đã phát triển ít nhất một thế hệ, và làm cho những điều này trở nên đẹp hơn.)

Java module , mặc dù họ không nhất thiết phải thêm bất cứ điều gì bạn không thể làm rồi, làm dụng cụ cho phụ thuộc / quản lý gói và tự động môi trường xây dựng tất cả NHIÊU dễ dàng hơn. Cho dù điều đó làm cho các mô-đun "tốt hơn", tôi từ chối nói. : P