В чем разница между Class.getResource () и ClassLoader.getResource ()?

Чтобы ответить на вопрос, происходит ли кеширование.

Я исследовал этот момент дальше, запустив автономное приложение Java, которое непрерывно загружало файл с диска с помощью метода getResourceAsStream ClassLoader. Я смог отредактировать файл, и изменения сразу отразились, т.е. файл был перезагружен с диска без кеширования.

Однако: я работаю над проектом с несколькими модулями maven и веб-проектами, которые зависят друг от друга. Я использую IntelliJ в качестве своей IDE для компиляции и запуска веб-проектов.

Я заметил, что вышесказанное, похоже, больше не соответствует действительности, причина в том, что файл, который я загружал, теперь запекается в банку и развертывается в зависимом веб-проекте. Я заметил это только после попытки изменить файл в моей целевой папке, но безрезультатно. Это создавало впечатление, что происходит кеширование.

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 (строковый ресурс)

• ClassLoader.getResource (строковый ресурс)

Все эти ответы здесь, а также ответы в этом вопросе предполагают загрузку абсолютных URL-адресов, например "/ foo / bar. properties "одинаково обрабатывались 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!

Извините, у меня нет абсолютно удовлетворительного объяснения, но я предполагаю, что кот делает грязные трюки и свою черную магию с загрузчиками классов и вызывает разницу. Раньше я всегда использовал class.getResourceAsStream(String), и у меня не было никаких проблем.

PS: Я также разместил это здесь

Class.getResources получит ресурс загрузчиком классов, который загружает объект. В то время как ClassLoader.getResource будет извлекать ресурс, используя указанный загрузчик классов.

Начиная с Java 9 существует ловушка с ClassLoader#getResource при запуске по пути к модулю. Из-за этого я бы никогда не использовал ClassLoader#getResource в новом коде.

Если ваш код находится в названном модуле и вы используете ClassLoader#getResource, ваш код может не получить ресурс , даже если ресурс находится в том же модуле. Это очень неожиданное поведение.

Я сам испытал это и был очень удивлен этой разнице между Class#getResource и ClassLoader#getResource. Однако это полностью определенное поведение в соответствии с javadoc:

Кроме того, за исключением особого случая, когда имя ресурса заканчивается на .class, этот метод будет находить ресурсы только в пакетах с именованными модулями, когда пакет открывается безоговорочно (даже если вызывающий этот метод находится в тот же модуль, что и ресурс).

Javadoc (выделено мной)

Я пробовал читать из input1.txt, который находился внутри одного из моих пакетов вместе с классом, который пытался его прочитать.

Следующие работы:

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

System.out.println(fileName);

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

Самой важной частью было вызов getPath(), если вы хотите получить правильное имя пути в строковом формате. НЕ ИСПОЛЬЗУЙТЕ toString(), потому что это добавит некоторый дополнительный текст форматирования, который ПОЛНОСТЬЮ ЗАМЕТИТ имя файла (вы можете попробовать это и посмотреть распечатку).

2 часа потратил на отладку ... :(

Еще один более эффективный способ - просто использовать @Value.

@Value("classpath:sss.json")
private Resource resource;

и после этого вы можете просто получить файл таким образом

File file = resource.getFile();