Как узнать, использует ли мое Java-приложение «нативный код»?

Question

На недавнем вопросе я получил комментарии, спрашивающие, использую ли я "родной код" в своем приложении.Теперь я знаю, что существует некоторый способ вызова кода в традиционных бинарных библиотеках (DLL, SO) из приложения Java с использованием , называемого «JNI» .Я прочитал эту запись в Википедии, но никогда не использовал ее.

Я использую несколько библиотек, некоторые из которых могут использовать или не использовать нативный код.Как я узнаю, если они делают?Мне не нужно было устанавливать какие-либо SO (работающие в Linux), но я думаю, это не значит, что библиотеки не используют их?Должен ли я просматривать всю документацию (которая сильно различается по качеству между библиотеками) или я могу провести некоторый анализ JAR-файлов?

Answer 1

Обычно использование библиотек, для которых требуется JNI, требует дополнительной настройки (например, размещение файлов .dll или .so в нужных местах или установка свойства системы java.library.path).

Если вы ничего не сделали, то есть вероятность, что вы нигде не используете JNI. Это также довольно вероятно, поскольку только JNI требуют только очень специализированные библиотеки.

Однако есть также JNA , который является оболочкой для JNI, которая упрощает его использование и которая иногда делает ненужной какую-либо явную настройку. Если он используется одной из ваших библиотек, то его сложнее обнаружить.

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

Answer 2

Вероятно, самый простой способ сделать это - использовать jmap или pmap, чтобы показать, какие файлы .so (совместно используемый объект) отображаются в вашем Java-процессе.Если в каталоге / lib, / usr / lib или в каталоге Java lib есть что-то кроме содержимого, это подозревается в JNI.Вы также можете просмотреть запись / proc для процесса Java в / proc / / maps.Смотрите следующие справочные страницы:

• http://linux.die.net/man/1/jmap-java-1.6.0-openjdk
• http://linux.die.net/man/1/pmap
• http://linux.die.net/man/5/proc

Answer 3

Если java-библиотека (jar) использует собственную библиотеку ( dll в Windows или , поэтому в Linux), есть вероятность, что это общесистемная и хорошо известная библиотека (например, как glibc на Linux) или пользовательский. В последнем случае обычно упаковать его в банку, так что вы можете просто открыть его с помощью декомпрессора ZIP (то есть 7zip в Windows подойдет) и просмотреть файлы. Вы должны увидеть файлы dll , если они предназначены для Windows, файлы и , если они предназначены для платформы Unix, или даже оба. Файлы собственной библиотеки обычно остаются на корневом уровне фляги.

Если jar-файл использует пользовательские библиотеки, но он упакован вместе с приложением, то обычные библиотеки обычно оставляют во внешней папке с другими файлами приложения (в этом случае нет единого мнения). В этом случае вам следует искать модуль запуска приложений (файл bat / sh ) или файл конфигурации, если файл lanucher является двоичным ( ini / conf file) и выясните конфигурацию JVM (на которую указывает java.library.path).

Answer 4

Чтобы придираться, каждое отдельное Java-приложение использует JNI как минимум косвенно. Например, класс System содержит несколько native методов, которые отображаются на собственный JRE (как видно из его исходного кода).

Действительно ли трудно определить, использует ли ваша программа / библиотеки (прямо или косвенно) какие-либо другие нативные функции, кроме тех, которые содержатся в стандартной JRE. .dll s / .so s могут быть упакованы в .jar, чтобы извлекаться только при необходимости, поэтому отсутствие необходимости установки собственных библиотек не гарантирует, что они не будут использовать , Обычно это следует указывать в документации библиотеки, потому что поставщик, вероятно, не будет предоставлять двоичные файлы для каждой мыслимой системы, на которой работает Java. Но, чтобы быть уверенным, я думаю, что единственный способ - это просмотреть исходный код для методов native.