java.langパッケージクラスを拡張し、パッケージのメソッドまたはフィールド（パブリックまたは保護されていないメソッドまたはフィールド）にアクセスできない実験を行いました。Ok。
次に、拡張機能をソースルートの「java.lang」に入れて再試行すると、コンパイルされました。したがって、パッケージアクセス制限は表面的なものにすぎず（他のクラスと同じ場所に配置する必要があるため、ユーザーはjava.langをインポートすることで見つけることができます）、実際には弱点がないため、実際には公開されている可能性があります。ここでのアクセスレベルは？（保護されていると、少なくともそれが拡張機能のオーバーライドであることを保証します）。
パッケージの概念は、クラスメンバーのアクセシビリティに追加レベルの粒度を提供するためにJavaに存在します。Javaのクラス読み込みメカニズムには柔軟性があるため、このクラスCと同じパッケージで独自のクラスを宣言するときに、クラスCのパッケージレベルのメンバーと属性にアクセスすることを制限するものではありません。
一部の仕様では、OSGIなどのより制限的なアクセスポリシーが適用されます。OSGIには、Java言語自体にはない、バンドルの追加の概念が付属しています。バンドルは、単一のjarにパッケージ化されたクラスのセットです。マニフェストファイルで、エクスポートするクラスとパッケージ、他のバンドルがアクセスできるものを宣言します。エクスポートされないパッケージとクラスは、他のバンドルから厳密にアクセスできません。
さらに、クラスCがエクスポートされていても、別のバンドルからバンドルのクラスCのパッケージレベルのメソッドと属性にアクセスすることはできません。OSGIクラスローダーでは、別のバンドルによってすでに「所有」されているパッケージからクラスをロードすることはできません。
アクセシビリティとパッケージングに関するこれらの質問に興味がある場合は、Jigsawプロジェクトをご覧ください。このプロジェクトは、Javaのモジュール性を再設計することを目的としており、Java SE（Java SE 8）の次のリリースで提供される予定です。延期されました）。
コードをjava.langというパッケージに入れると、コードがそのパッケージに属していることを意味するため、元のjava.langで説明されている「パッケージ」メソッドに実際にアクセスできます。
これについて考えてみてください。プロジェクトには「パッケージ」アクセスレベルメソッドがあり、それらを単体テストしたいと考えています。これは、同じパッケージ内のクラスで行うことができます。つまり、まったく同じディレクトリ内にあるか、同じパッケージ名でsrcとtestの2つの別々のディレクトリを持つことができます。このようにして、単体テストはコードと同じパッケージで定義できますが、ディスク上の別の場所に配置されます。