Class.getResource（）とClassLoader.getResource（）の違いは何ですか？

私は違いが間にあるのだろうかClass.getResource()とClassLoader.getResource()？

編集：特にキャッシュがファイル/ディレクトリレベルで行われているかどうかを知りたいです。「クラスのバージョンではディレクトリのリストがキャッシュされますか？」のように

私の知る限り、以下は本質的に同じことをするはずですが、そうではありません：

getClass().getResource() 
getClass().getClassLoader().getResource()

WEB-INF/classes/そのディレクトリの既存のファイルから新しいファイルを作成するレポート生成コードをいじるときに、これを発見しました。Classのメソッドを使用すると、を使用してデプロイメント時に存在していたファイルを見つけることができましたがgetClass().getResource()、新しく作成されたファイルをフェッチしようとすると、nullオブジェクトを受け取りました。ディレクトリを参照すると、新しいファイルがそこにあることがはっきりとわかります。ファイル名の先頭には、「/ myFile.txt」のようにスラッシュが付いています。

一方、のClassLoaderバージョンでgetResource()は、生成されたファイルが見つかりました。この経験から、ディレクトリリストのキャッシュが行われているようです。私は正しいですか、そうであれば、これはどこに文書化されていますか？

上のAPIドキュメントからClass.getResource()

指定された名前のリソースを検索します。特定のクラスに関連付けられているリソースを検索するためのルールは、クラスの定義クラスローダーによって実装されます。このメソッドは、このオブジェクトのクラスローダーに委譲します。このオブジェクトがブートストラップクラスローダーによってロードされた場合、メソッドはClassLoader.getSystemResource（java.lang.String）に委譲します。

私には、これは「Class.getResourceが実際に独自のクラスローダーのgetResource（）を呼び出している」と読みます。これはと同じgetClass().getClassLoader().getResource()です。しかし、明らかにそうではありません。誰かが私にこの問題についていくつかの照明を提供してくれませんか？

キャッシングが行われているかどうかの質問に答えます。

getResourceAsStream ClassLoaderメソッドを使用してディスクからファイルを継続的にロードするスタンドアロンJavaアプリケーションを実行して、この点をさらに調査しました。ファイルを編集することができ、変更はすぐに反映されました。つまり、ファイルはキャッシュされずにディスクからリロードされました。

ただし、 私はいくつかのmavenモジュールと相互に依存関係のあるWebプロジェクトでプロジェクトに取り組んでいます。IDEとしてIntelliJを使用して、Webプロジェクトをコンパイルおよび実行しています。

上記が当てはまらなくなったようです。理由は、ロードされていたファイルがjarにベイクされ、依存するWebプロジェクトにデプロイされているためです。私がこれに気付いたのは、ターゲットフォルダー内のファイルを変更しようとしたが、役に立たなかったためです。これにより、キャッシュが行われているように見えました。

Class.getResourceクラスのパッケージに関連して扱われる「相対」リソース名をとることができます。または、先頭にスラッシュを使用して「絶対」リソース名を指定できます。クラスローダーのリソースパスは常に絶対パスと見なされます。

したがって、以下は基本的に同等です。

foo.bar.Baz.class.getResource("xyz.txt");
foo.bar.Baz.class.getClassLoader().getResource("foo/bar/xyz.txt");

これらも同様です（ただし、上記とは異なります）。

foo.bar.Baz.class.getResource("/data/xyz.txt");
foo.bar.Baz.class.getClassLoader().getResource("data/xyz.txt");

最初の呼び出しは.classファイルに関連して検索し、後者はクラスパスルートに関連して検索します。

そのような問題をデバッグするには、次のURLを出力します。

System.out.println( getClass().getResource(getClass().getSimpleName() + ".class") );

スペックで調べなければなりませんでした：

• Class.getResource（String resource）

• ClassLoader.getResource（String resource）

クラスのgetResource（）-ドキュメントは違いを述べています：

このメソッドは、リソース名にこれらの変更を加えた後、呼び出しをクラスローダーに委譲します。リソース名が「/」で始まる場合、変更されません。それ以外の場合は、「。」に変換した後、パッケージ名がリソース名の前に付加されます。「/」に。このオブジェクトがブートストラップローダーによってロードされた場合、呼び出しはClassLoader.getSystemResourceに委譲されます。

ここにあるこれらすべての回答、およびこの質問の回答は、「/ foo / bar.properties」のような絶対URLのロードがclass.getResourceAsStream(String)およびによって同じように処理されたことを示唆していますclass.getClassLoader().getResourceAsStream(String)。これは、少なくとも私のTomcat構成/バージョン（現在は7.0.40）には当てはまりません。

MyClass.class.getResourceAsStream("/foo/bar.properties"); // works!  
MyClass.class.getClassLoader().getResourceAsStream("/foo/bar.properties"); // does NOT work!

申し訳ありませんが、満足できる説明はまったくありませんが、Tomcatがクラスローダーを使って汚いトリックと彼の黒魔術を行い、違いを引き起こしていると思います。昔はいつも使っclass.getResourceAsStream(String)ていて、問題はありませんでした。

PS：これもここに投稿しました

Class.getResourcesオブジェクトをロードするクラスローダーによってリソースを取得します。一方では、ClassLoader.getResource指定されたクラスローダを使用してリソースを取得します。

私のパッケージの中にあるinput1.txtから、それを読み込もうとしたクラスと一緒に読み込もうとしました。

次の作品：

String fileName = FileTransferClient.class.getResource("input1.txt").getPath();

System.out.println(fileName);

BufferedReader bufferedTextIn = new BufferedReader(new FileReader(fileName));

最も重要な部分はgetPath()、String形式の正しいパス名が必要な場合に呼び出すことでした。使用しtoString()ないでください。これにより、fileNameが完全に失われる追加の書式設定テキストが追加されます（試してみると、印刷結果を確認できます）。

これをデバッグするのに2時間を費やした... :(