パッケージとモジュールがJava 9で別個の概念である理由

Java 9には、パッケージに加えてモジュールがあります。通常、言語にはどちらか一方があります。そして、ほとんどのプログラマーは 2つの用語を同義語として認識しています。モジュールはパッケージの上に構築され、それらをプリミティブとして扱います。複合パターンは、プリミティブと複合物を均一に処理することを提案します。そうしないと、悪いことが起こります。たとえば、プロジェクトValhallaを見てください。そこでは、プリミティブ（値）および参照型の共通スーパータイプを後付けしようとしています。

モジュールとパッケージは意味的に分離した概念を表していますか？それを意味することの両方を持つことが賢明である任意の言語（関心事の分離）。または、Javaは後方互換性への賛辞として両方を持たなければなりませんか？

既存の概念を補強するのではなく、なぜ新しい概念を導入するのですか？

JSR 376：プロジェクトJigsaw内に実装された「Javaプラットフォームモジュールシステム」。

SOTMSによると

モジュールは、コードとデータの名前付きの自己記述型コレクションです。そのコードは、Javaクラスとインターフェースなどのタイプを含むパッケージのセットとして編成されています。そのデータには、リソースおよびその他の種類の静的情報が含まれます。

JLSは、パッケージとは何かを定義することを慎重に避けます。ウィキペディアから：

Javaパッケージは、JavaクラスをModulaのモジュールに似た名前空間に編成するための手法で、Javaでのモジュール式プログラミングを提供します。

ウィキペディアを引用するのは悪い習慣であることは知っていますが、それは一般的な理解を反映しています。モジュラープログラミングのエントリから：

パッケージという用語は、モジュールの代わりに使用されることがあります（Dart、Go、またはJavaなど）。他の実装では、これは明確な概念です。Pythonではパッケージはモジュールのコレクションですが、今後のJava 9では新しいモジュールの概念（強化されたアクセス制御を備えたパッケージのコレクション）の導入が計画されています。

モジュールの概念は、その概念のインスタンス化とは異なります。

Javaには常にモジュールがあります。メソッドはモジュールであり、クラスでもあり、パッケージでもあります。モジュールは、内部の詳細が隠され、合意された契約を介して他のモジュールと通信する組織の単位です。たとえば、メソッドは、内部（コードとローカル変数）とコントラクト（パラメーターと戻り値の型）が隠されているため、モジュールです。モジュールは、下位レベルのモジュールから構成できます。たとえば、クラスにはメソッドが含まれます。

コアJava（9より前）に欠けているのは、デプロイ可能なモジュールです。上記の種類のモジュールはすべて、コピー可能な展開可能なユニットではありません。JavaにはJARファイルと呼ばれるデプロイ可能なアーティファクトがありますが、これらはカプセル化またはコントラクトがないためモジュールではありません。実行時にJARファイルが消え、すべてが単一の「クラスパス」にマージされます。

OSGiは、1998年に「バンドル」の概念でデプロイ可能なモジュールの不足に対処しました。これらは物理的にJARファイルであり、パッケージが含まれていますが、OSGiはランタイムシステムとともに追加のメタデータを定義して、そのレベルでカプセル化とコントラクトをサポートします。

Java 9は、OSGiと同様の方法でデプロイ可能なモジュールの不足に対処します。OSGiが存在し動作するため、これは間違いなく完全に不要でしたが、それはまったく異なる議論です...

残念ながら、Java 9は、新しいモジュールの概念を単なる「モジュール」と名付けて、水を汚しています。これは、メソッド、クラス、パッケージがモジュールでなくなることを意味しません！J9「モジュール」は、モジュール概念の単なる別のインスタンス化です。OSGiバンドルと同様に、J9モジュールはパッケージで構成されており、コピーできる物理的なアーティファクト（通常は再びJARファイル）です。ランタイムシステムはそれらを理解し、具体化します。

要約：はい、J9モジュールとパッケージは意味的に別個の概念です。明らかに、Javaは後方互換性のために既存のパッケージの概念を保持する必要があります。Javaでは、「パッケージ」という語の使用方法が、他の言語やRPMなどのパッケージ管理システムとはまったく異なることに注意してください。新しいJ9モジュール（およびOSGiバンドル）は、JavaパッケージよりもRPMのパッケージによく似ています。

その多くは仮定/分割髪/暴言などかもしれませんが、答えを危険にさらしてみましょう

それらは同じものですか？まあ、はい^_、いいえ

「Java 9のモジュール方式」に関するこのJavaWorldの記事から：

モジュラーソリューションとしてのパッケージ

パッケージは、Javaプログラミング環境に抽象化のレベルを追加しようとします。独自のコーディング名前空間と構成コンテキストの機能を提供します。ただし、残念ながら、パッケージの規則は簡単に回避され、コンパイル時の危険な結合の環境につながることがよくあります。

@ user2418306（OP）ほのめかし、「モジュールが正しく行わパッケージです」。Javaのモジュールとパッケージ（Java 9の時点では明らかに）は（OPが要求するように）意味的に同じです。つまり、これらはプリコンパイルされたJVMバイトコードのコレクションであり、他のメタデータとともに - 基本的にはライブラリです。

さて、違いは何ですか？

ただし、違いはそれぞれのメタデータにあります。Java packageマニフェスト、またはJARマニフェストは、ライブラリ開発者によって維持されることはあまりなく、JAR /パッケージが提供するものに関する確実な契約も提供しません。ここで説明したように（JavaWorldの記事をもう一度）：

JARファイルはモジュール化されていませんか？

JARファイルとそれらが動作するデプロイメント環境は、他の方法で利用可能な多くのレガシーデプロイメント規則を大幅に改善します。ただし、JARファイルには、まれにしか使用されないバージョン番号は別として、固有の固有性はありません。JARファイルとオプションのマニフェストは、Javaランタイム環境内のモジュール性規則として使用されません。したがって、ファイル内のクラスのパッケージ名とクラスパスへの参加は、ランタイム環境にモジュール性を与えるJAR構造の唯一の部分です。

他の言語/環境などに関する暴言

その記事で議論された別の分野は、ビルドプロセスの一部として依存関係を管理するMavenなどのシステムです。Apache Mavenサイトのこのページから：

依存関係管理：

Mavenは、JARおよびその他の依存関係の中央リポジトリの使用を推奨しています。Mavenには、プロジェクトのクライアントがPerlのCPANのように中央のJARリポジトリからプロジェクトのビルドに必要なJARをダウンロードするために使用できるメカニズムが付属しています。これにより、Mavenのユーザーはプロジェクト間でJARを再利用でき、プロジェクト間の通信を促進して、後方互換性の問題に対処できるようにします。

今、私がそこにいたかのように未来について話す

そのページで述べたように、他の言語（Perlなど）にはパッケージリポジトリ（CPANなど）があります。これは、過去数十年ほどにわたって増加傾向にあります（私は、私がそれを感じているので、何の重要な証拠もありません）。Rubyのgem、PythonのPyPi、Nodeパッケージマネージャー（npm）などのツールはこれに基づいて構築され、適切なもの（パッケージ、モジュール、宝石、ギズモなど）。アイデア（私が感じる）は「借用」などでした（明らかに、少なくとも1世代は進化しており、これらはすべてより良いものになりました。）」など、DebianのようLinux®の配信システムからのapt、RedHatのrpm

Javaは、モジュール、彼らは必ずしも依存関係/パッケージ管理および自動ビルド環境のためのメイクツールはすべて、あなたがまだできないことは何も追加しませんがMUCH容易になります。それがモジュールを「より良くする」かどうか、私は言いません。：P