3

このクラスに出くわしjava.io.FileSystem、プロジェクトで現在必要なメソッドがたくさんあることに気づきました。ただし、クラスはパッケージプライベートであるため、リフレクションを使用して必要なメソッドにアクセスしています。

質問：

  1. このクラスがパッケージプライベートとしてマークされている特別な理由はありますか？
  2. リフレクションを介してアクセスする危険性はありますか？（パフォーマンスヒット以外、つまり。）
4

3 に答える 3

8

  1. SUN（および拡張によりOracle）は、このプラットフォーム依存クラスのメソッドが将来大幅に変更される可能性があり、したがって直接アクセスしてはならないため、このクラスはパッケージプライベートです。この抽象クラスのすべての実装はネイティブコードです。Javaプログラマーは、独自のプログラマーを作成できないようにする必要があります。

  2. リフレクションによって隠しクラスを使用する最大の危険性はパフォーマンスではありませんが、JDKの次のアップグレードで、そのメソッドまたはクラス全体でさえ、どんなにマイナーであっても消えてしまう可能性が非常に高くなります。非公開APIは、まあ、非公開です。それらを変更することは、メンテナンスリリースでも公正なゲームであるため、JDKの定期的な更新のように見えた後でプログラムが機能しなくなった場合は、自分の責任で済みます。

于 2012-06-02T11:50:27.037 に答える
6

このクラスがパッケージプライベートとしてマークされている特別な理由はありますか？

はい。java.io.FileSystemJavaAPIの一部ではありません。それがどのようにそしてどのように機能するかについての保証はありません。次のバージョンで削除または変更される可能性があります。実際、Oracle以外のすべてのJava実装では欠落している可能性があります。

java.io.Fileこのクラスは内部で使用されるため、その機能のほとんどを何らかの方法で公開する必要があります。

リフレクションを介してアクセスする危険性はありますか？（パフォーマンスヒット以外、つまり。）

あなたは避けSecurityManagerているので、それはうまくいきません。

于 2012-06-02T11:51:40.977 に答える
6

このクラスがパッケージプライベートとしてマークされている特別な理由はありますか？

全体として、Java SEクラスをパッケージプライベートとして宣言する目的は、それが使用すべきAPIではないことを通知することです。

一般的に、理由は次のとおりです。

  • Javaチームが将来のリリースで（内部）APIに重大 な変更を加えるのを容易にするため。

  • APIを一般的な使用に適さないものにする制限/制限を隠すため。例えば：

    • セキュリティへの影響、または通話が他の何かを「壊す」リスクがある可能性があります。
    • メソッドの動作が乱雑であるか、プラットフォームに依存しすぎてjavadocで説明できない場合があります。

この場合、設計者は両方の理由が当てはまると考えていたのではないかと思います。しかし、彼らの（想定される）元の考え方の「正しさ」について議論することは議論の余地があることに注意してください。（そしてトピック外：StackOverflowはディスカッションサイトではありません。）

現在、ファイルシステムへのアクセスと移植性に関するJavaチームの考え方は、時間の経過とともに進化してきました。Java 7では、古いAPIよりもはるかに優れたファイルシステム固有の動作の問題を処理するいくつかの新しいAPI（java.nio.file.Pathおよびなど）が導入されました。java.nio.file.FileSystemjava.io.File

ただし、これは、古いAPIを遡及的に変更または削除できる、または削除する必要があるという意味ではありません。もしそうするなら、それは既存のJavaアプリケーションの「何百万」を壊すでしょう。

リフレクションを介してアクセスする危険性はありますか？

上記の理由は、メソッドを反射的に使用する場合にも当てはまります。

于 2012-06-02T11:49:44.860 に答える