16

プロジェクトのコアはJigsawJava モジュール システムであるため、特定のモジュール内の特定のプログラム要素 (クラス、メソッド、およびフィールド) へのアクセスを制限できると便利です。

モジュール内に、このモジュールに対して本質的に公開されているが、このモジュールの外部からはアクセスできない要素がいくつかある場合に役立ちます。

つまり、「package-local」の次のレベルのアクセスについて話しているのです。これは「module-local」と名付けることができます。

しかし、ジグソー ルールと初期の仕様を簡単に調べただけでは、そのような機能を見つけるのに役立ちませんでした。より具体的には、このModifier仕様には新しい要素は含まれていません。

将来のJava 9でそれを行う可能性は他にありますか?

4

2 に答える 2

8

簡潔な答え

モジュール内に、このモジュールに対して本質的に公開されているが、このモジュールの外部からはアクセスできない要素がいくつかある場合に役立ちます。

それは不可能です。(モジュールシステムのみの手段で - 回避策があります。)

長い答え

説明は、アクセシビリティという用語の中にあります。

Java コンパイラと仮想マシンは、最初のモジュールが 2 番目のモジュールから読み取り可能であり (上記で定義した意味で)、最初のモジュールがそのパッケージをエクスポートする場合にのみ、1 つのモジュールのパッケージ内のパブリック型が他のモジュールのコードからアクセス可能であると見なします。 . [...]

この方法でアクセスできないモジュールの境界を越えて参照される型は、プライベート メソッドまたはフィールドが使用できないのと同じ方法で使用できません。それを使用しようとすると、コンパイラによってエラーが報告されるか、IllegalAccessErrorによってスローされます。 Java 仮想マシン、またはIllegalAccessExceptionリフレクティブ ランタイム API によってスローされる 。[...]

モジュールの境界を越えて参照されるメソッドまたはフィールドは、この意味でそれを囲む型がアクセス可能であり、メンバー自体の宣言でもアクセスが許可されている場合にアクセス可能です。

パッケージを正確にどのように、誰にエクスポートできるかについてはさまざまな方法がありますが、コンパイラ/JVM がタイプにアクセス可能であると判断すると、追加のメカニズムは適用されません。そのメンバーは、Jigsaw の前と同じようにアクセスできます。

これは、アクセシブルな型のメンバーをモジュール内で可視にする方法がないことを意味します (これには が必要ですpublic)。

回避策

将来のJava 9でそれを行う可能性は他にありますか?

はい。:)

Globalエクスポートされたパッケージには、世界にエクスポートするメソッドを定義するパブリック インターフェイスを含めることができます。次に、インターフェイスまたはクラスLocalを拡張し、必要なGlobalすべてのメンバーを追加します。重要なのは、エクスポートされたパッケージに入れてLocalはならないということです!

モジュールの API がGlobal-s のみを返し、それらをメソッド引数として受け入れない場合は、問題ありません。内部で常に - を使用し、場合によっては - にキャストすることを確認してくださいLocal。

-sも受け入れる場合Global、これらは API が返すインスタンスのみであることを明確に文書化する必要があります (つまり、ユーザーは独自の実装を作成することはできません)。これは法外に聞こえるかもしれませんが、元の要求についてよく考えてみると、同じ特性を持っているはずです。

于 2016-08-11T16:37:38.843 に答える