7

On a recent question, I got comments asking whether I was using "native code" in my application. Now, I know that there is some way to call code in traditional binary libraries (DLLs, SOs) from inside a Java application using a thing called "JNI". I have read that Wikipedia entry but I never used this.

I am using a number of libraries, some of which may or may not use native code. How do I find out if they do? I did not have to install any SOs (running on Linux), but I guess that doesn't mean the libraries are not using any? Do I have to browse through all the documentation (which varies greatly in quality between libraries) or can I do some analysis on the JARs?

Community
  • 1
  • 1
Hanno Fietz
  • 30,799
  • 47
  • 148
  • 234
  • Many functions which use the OS, like IO, threading all use native methods somewhere. Its not possible to write a useful program which never uses a native call (whether you know it or not) – Peter Lawrey Sep 14 '11 at 08:46
  • you can obtain list of the loaded libraries in linux w/ something like: `cat /proc/processId/maps | grep ".so"` on Windows Process Explorer can show the loaded DLLs and last, you can install a SecurityManager (in java) to track any library being loaded, the method is called `checkLink` and the permission name starts with "loadLibrary" – bestsss Nov 01 '11 at 04:00

4 Answers4

4

Usually using libraries that require JNI requires some additional setup (like putting .dll or .so files in the right places or setting the java.library.path System property).

If you did nothing of that, then chances are that you're not using JNI anywhere. This is also somewhat likely, as only quite specialized libraries require JNI.

However there's also JNA, which is a wrapper around JNI which simplifies its usage and which sometimes makes it unnecessary to do any explicit setup. If that's used by one of your libraries, then it's harder to detect.

If you get a crash dump, then checking that for any non-standard libraries can give a hint if a user-loaded native library is to blame.

Hanno Fietz
  • 30,799
  • 47
  • 148
  • 234
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • I might be using "quite specialized libraries". For instance, there's one that does Modbus over TCP and before we patched it, it had serial driver related stuff in it... – Hanno Fietz Sep 14 '11 at 08:34
  • Yes, that could certainly qualify for such a library. And thanks for the fix ;-) – Joachim Sauer Sep 14 '11 at 08:36
  • Yikes. A wrapper around an apparently dangerous technology which doesn't make it less dangerous, just harder to analyze and easier to employ. Sounds creepy to me. – Hanno Fietz Sep 14 '11 at 20:30
1

To nitpick, every single Java application uses JNI indirectly at least. For example, System class contains several native methods, which map to the native JRE (as can be seen from its source code).

Whether your program/libraries use (directly or indirectly) some other native functions than those contained in the standard JRE, is indeed hard to detect. The .dlls / .sos may be packed into the .jar, to be extracted only when needed, so not having to install native libraries doesn't guarantee that it doesn't use any. It should usually be stated in the library documentation, though, because the vendor probably won't provide binaries for every imaginable system that Java runs on. But to be sure, I think the only way is to scan through the source code for native methods.

Joonas Pulakka
  • 36,252
  • 29
  • 106
  • 169
1

If a java library (jar) uses a native library (dll on Windows or so on Linux) the chances are that it is a system wide and well known library (such as glibc on Linux) or a custom one. In the last case it is common to pack it within the jar, so you can just open it up with a ZIP decompressor (i.e. 7zip on Windows will do fine) and browse the files. You should see dll files if it is targeted to Windows, so files if targeted to a Unix platform, or even both. The native library files usually are left at the root level of the jar.

If the jar uses custom libraries but it is packed along with an application it is common to leave the native libraries in an external folder with other application files (in this case there is no consensus). In this case you should look for the application launcher (a bat / sh file) or the configuration file if the lanucher is binary (an ini / conf file) and find out the JVM configuration (where java.library.path points to).

Fernando Miguélez
  • 11,196
  • 6
  • 36
  • 54
1

Probably the easiest way of doing this is using jmap or pmap to show which .so (shared object) files are mapped into your Java process. If there's anything other than stuff that's in /lib, /usr/lib or the Java lib directory it's a JNI suspect. You can also look at the /proc entry for the Java process under /proc/<pid>/maps. See the following manpages:

Alan Burlison
  • 1,022
  • 1
  • 9
  • 16