Я предполагаю, что вы получаете UnsatisfiedLinkError
, потому что вы еще не сделали Runtime.loadLibrary
для ввода нативного кода для поддержки native
методов.Такие библиотеки должны находиться в локальной файловой системе и не зависят от загрузчика классов.Javadoc:
public void loadLibrary(String libname)
Загружает динамическую библиотеку с указанным именем библиотеки.Файл, содержащий собственный код, загружается из локальной файловой системы из места, где обычно получают библиотечные файлы. Детали этого процесса зависят от реализации .Преобразование из имени библиотеки в конкретное имя файла выполняется системным образом.
и, очевидно, Runtime.getRuntime()
не зависит от какого-либо конкретного загрузчика классов.
Если загрузка сетевого класса может вызвать сетевую загрузку нативного кода, это будет огромной уязвимостью удаленного выполнения кода , потому что нативный код не может быть ограничен SecurityManager
способом java-байт-кодаможет быть.
Если вы доверяете веб-сайту, производящему приложение, и извлекаете его по защищенному каналу (зашифрованному для предотвращения MITM и взлома), то вы можете извлечь библиотеки, выгрузить их в локальную файловую системупроверьте любые подписи или контрольные суммы, затем вызовите Runtime.loadLibrary
или System.loadLibrary
для загрузки собственных библиотек перед инициализацией класса.
Если вы не доверяете авторамвеб-сайт, производящий приложение, или этот веб-сайт, на котором размещается сторонний контент, поэтому не загружайте из него JAR-файлы, а гораздо меньше системных библиотек.
Даже если авторы веб-сайта заслуживают доверия, загружая системные библиотеки или другой собственный код, которыйВы не проверяли и не проверяли, может быть опасно.Процесс песочницы с помощью chroot
и перехват системных вызовов могут помочь в некоторой степени снизить этот риск, но будьте осторожны.