重複の可能性:
Java: サブパッケージの可視性?
これは質問Java: Subpackage Visiblity?の続きです。. 質問する理由は、より広いコミュニティの注意を引くためです。
質問odp.proj と odp.proj.subpackage の 2 つのパッケージの間に関係はありますか?
誰かがここで答えようとしましたが、説明できませんでした。
重複の可能性:
Java: サブパッケージの可視性?
これは質問Java: Subpackage Visiblity?の続きです。. 質問する理由は、より広いコミュニティの注意を引くためです。
質問odp.proj と odp.proj.subpackage の 2 つのパッケージの間に関係はありますか?
誰かがここで答えようとしましたが、説明できませんでした。
いいえ、Java 言語の観点からはodp.proj
との間に関係はありません。odp.proj.subpackage
コードの場合、odp.proj.subpackage は odp.proj のサブディレクトリに存在し、一部のツールと IDE はそれらを UI にグループ化する可能性がありますが、言語アクセス制御または他の言語機能に関しては関係がありません。
Java にはサブパッケージの概念がないため、odp.proj.subpackage と odp.proj は、他の異なる名前のパッケージと同じように互いに異なります。
お探しの正確な機能は存在しません。
彼らは Java 1.7 でそれを行うことを検討しましたが、そのケースは休眠状態です。
実際に何が本当であるかについては、ディレクトリ構造、キーワードなどとodp.proj
の間に関係はまったくありません-そのステートメントはからクラスを取得しないことを除いてodp.proj.subpackage
protected
import odp.proj.*;
odp.proj.subpackage
公開したいものにアプローチする 1 つの方法は、公開したいものの API 仕様をリリースし、残りを文書化しないか、非公開のままにしておくことです。ProGuardなどを使用して、各リリースのプライベート クラスを難読化することもできます。
Java にはサブパッケージの概念がありません。
protected
組織を超えて、パッケージは同じクラスと同じパッケージへのアクセスを許可する "パッケージ" (空白) 修飾子を使用して、メソッド/フィールドのアクセシビリティを定義します。ただし、この同一パッケージ アクセスには、サブパッケージ クラスも含まれません。
通常、パッケージ名に「内部」という単語が含まれている場合、ユーザーはそれを直接使用しないでください。これは、それらのパッケージが将来のリリースで存在することが保証されていないためです。これは単なる命名規則ですが、それでも回避策として機能します。