Как правильно читать из JarURLInputStream? (Джава)

Это невозможно. Вам нужно будет создать файловую систему zip

@ g00se Кажется, да, но почему вместо этого возвращается экземпляр InputStreamnull?

Нет никакой гарантии, какой поток Class::getResourceAsStream вернется. Единственное, что вы знаете, это то, что поток можно использовать для чтения ресурса, если вызывающий объект может найти этот ресурс и получить к нему доступ. Тот факт, что поток возвращается для «ресурсов каталога», вообще не является документированным поведением и, как известно, не во всех случаях ведет себя одинаково.

Обратите внимание, что способ доступа к ресурсам зависит от реализации ClassLoader. Для загрузчиков, поддерживающих модули, сам загрузчик обычно зависит от базовой реализации ModuleReader именованных модулей. Доступ к ресурсам также зависит от механизма URL, по крайней мере, при использовании getResource(String). Это означает, что это зависит от URLStreamHandler, связанного с URL, что может зависеть от настроенного URLStreamHandlerFactory. И тогда это зависит от реализации URLConnection, возвращаемой обработчиком.

Что касается разницы в поведении, которую вы наблюдаете, то при запуске вашего кода из NetBeans ваш код, скорее всего, запускается непосредственно из файловой системы (т. е. он не упаковывается сначала в файл JAR). Это означает, что вы получаете доступ к ресурсу через FileURLConnection (внутренний класс). И этот класс, очевидно, реализовал getInputStream() для возврата потока, который дает вам имена дочерних элементов каталога, когда файл является каталогом. Когда ваш код упакован в JAR, вы получаете JarURLConnection, который работает по-другому. Хотя опять же, по большей части это все детали реализации.

Если ваша цель — составить список ресурсов, чтобы вы могли выбирать из них для загрузки, то вы можете использовать один трюк — создать из них индекс текстового файла и загрузить его. Это не проблема, поскольку вы будете знать, какие ресурсы у вас есть, когда построите его. Поскольку ресурсы доступны только для чтения, они изменятся только в том случае, если вы создадите их заново с другими. Ох, ты всегда знаешь, что у тебя там

Вы не можете указать каталог ресурсов, потому что на самом деле это не каталог. См. stackoverflow.com/questions/77863392/….

С причинами, почему это не работает, у вас все в порядке, но я все равно считаю, что возврат нефункционального InputStream вместо null или Exception - это ошибка. Тем временем я нашел очень умное решение -> stackoverflow.com/a/32828953/5399598

В зависимости от того, какой инструмент вы использовали для создания файла jar, у вас будут записи нулевой длины для каталогов в файле. API ввода-вывода отражает именно это. Вы получите null, если такой записи нет, или пустой входной поток, когда присутствует запись нулевой длины. Я не считаю использование Compiler API для такой задачи «очень разумным». Это все равно, что построить ракету, чтобы долететь до следующего супермаркета. Далее отметим, что актуальность «загрузчика контекста» — живучий миф. Метод getContextClassLoader() потока просто вернет все, что было установлено через setContextClassLoader(…).

@Holger Спасибо за объяснение API ввода-вывода, который я не знал, где найти. Я создал JAR с помощью IDE NetBeans. Я думаю, они используют «обычный» jar-инструмент. Но какие альтернативы существуют? И какой инструмент вы предлагаете, если Compiler API не подходит?

Вы можете использовать API FileSystem, который позволяет выполнять такие операции, как Files.list(…). См., например, этот ответ.

@Holger Спасибо за вдохновение. Немного исчерпывающе из-за большого использования потоков и отсутствия рекурсивного сбора. Использование меньшего количества потоков делает код более компактным и, возможно, более быстрым, см.: stackoverflow.com/a/78751388/5399598

@CoSoCo Самое замечательное в использовании API FileSystem — это то, что вы можете выбирать, что делать с путями. Если вы хотите выполнить рекурсию, просто используйте walk вместо list. Я не понимаю вашей точки зрения насчет потоков, вы все еще используете метод, возвращающий поток и охотно собирающий поток в список перед его итерацией, это не быстрее, чем итерация потока в первую очередь.

@Holger Возможность walk я наблюдал. Спасибо за подсказку. Итерация потока в первую очередь становится утомительной, когда я хочу сделать больше, чем System.out.println(p);, например. функция типа Class.forName(), которая выдает исключения, которые я хочу обработать вне итерации потока. Также мне нужно определить дополнительный интерфейс и вызвать метод accept().

Другая проблема заключается в том, что существует более одного пути к классам (некоторые извлекают ресурсы из стандартных файлов, некоторые из файла JAR). Тогда Paths.get(MyClass.class.getResource("MyClass.class").toURI()‌​).getParent() недостаточно.

Дополнительный интерфейс в этом ответе предназначен для инкапсуляции действия, чтобы метод можно было повторно использовать для разных действий. Вот почему решение представлено как «наиболее общее решение». Это вообще не имеет ничего общего с Stream API. Если у вас есть только одна задача и вы не хотите повторно использовать метод, вы, конечно, можете опустить эту абстракцию. Тогда это уже не общее решение, но для вашей конкретной задачи оно, конечно, будет более кратким. Но как я мог предложить решение вашей конкретной задачи восемь лет назад? Вот почему в ответе используется абстракция.

@Holger Теперь я обновил свой ответ, используя Files.walk(). К сожалению, невозможно 1. избежать проверки Files.isDirectory() и 2. избежать перехода по ссылкам.

Не используйте Thread.currentThread().getContextClassLoader(). Если вы хотите посещать занятия в (под)пакетах пакета ResourceList.class, вам следует использовать ResourceList.class.getClassLoader(). Загрузчик классов контекста — это свойство, которому любой может присвоить произвольное значение, совершенно не связанное с пакетом(ами), который вы ищете. Кроме того, разделителем getResources должен быть '/', а не File.separatorChar.

Кстати, url -> { urls.add(url); } можно упростить до url -> urls.add(url) или даже urls::add. В качестве альтернативы walk вы можете использовать walkFileTree и расширить SimpleFileVisitor и переопределить visitFile, который вызывается только для файлов, не являющихся каталогами, поэтому тогда isDirectory не требуется.

@Holger Спасибо за подсказку. Я правильно понимаю, что после Paths.get(uri) я все еще использую File.separatorChar, как это могло быть в Windows '\'? Я изменю код соответственно.

@Holger Я подумывал использовать walkFileTree, но не нашел хорошего примера, как закодировать FileVisitor. У тебя есть один? Я не понимаю, какое действие поставить visitFile.

@Holger В javadoc walkFileTree я также прочитал: «Метод visitFile вызывается для всех файлов, включая каталоги, встречающихся в maxDepth ...». Так почему же вы думаете, что каталоги пропускаются?

Каталоги не пропускаются, для каталогов вызываются методы preVisitDirectory и postVisitDirectory. И в документации прямо сказано: «Если файл не является каталогом, то метод visitFile вызывается с атрибутами файла».

@Holger Итак, документация противоречива, см. некоторые отрывки позже (Надеюсь, эта специальная ссылка для цитирования текста сработает для вас, поскольку Firefox ее игнорирует.)

В моем понимании preVisit... и postVisit... не означают visit.... Так как vistitDirectory нет, то похоже, что под visitFile подразумеваются все файлы. А приведенная вами фраза описывает лишь один случай, но не исключает другие случаи, например. каталог.

«Если не идет дождь, я гуляю». это не значит, что я никогда не гуляю, когда идет дождь.

Предложение не противоречит, если не разрезать его так, как вы это сделали. В нем говорится: «Метод visitFile вызывается для всех файлов, включая каталоги, встречающихся в maxDepth», что является особым случаем. Если вы решите предоставить небольшое число для maxDepth, чтобы его можно было когда-либо достичь (в отличие от значения по умолчанию Integer.MAX_VALUE), тогда каталоги максимальной глубины, которые не будут пройдены, будут обрабатываться как обычные файлы. Я использую этот метод уже почти десятилетие, знаю, что он делает, не знаю, куда движутся ваши попытки обсудить формулировку.

@Holger Спасибо за исправление. Английский не мой родной язык, поэтому я неправильно истолковал это предложение. Итак, теперь я проверил walkFileTree и могу подтвердить, что это работает, как вы говорите. С walkFileTree код намного компактнее, чем с потоковым вариантом walk.