We answer a few frequently asked questions about JNI in the Java 2 SDK v1.2 (formerly known as JDK 1.2). The questions were assembled from your feedback to jni@java.sun.com. If you have any comments about this page, or would like some other question answered here, be sure to send us email by clicking on the link at the bottom of this page.
The terms shared library and dynamic linked library (DLL)
are used interchangeably in this document. This loose usage is intentional
because in the context of our discussion they serve the same purpose: if you
are Unix developer your native methods reside in a shared library, and on
Windows they reside in a DLL. Hence, any mention of jvm.dll from
the Windows release, can be substituted with libjvm.so from the
Solaris release, unless otherwise noted.
JNI_CreateJavaVM always returns -1!*
javai.dll?
makeJavaString not found" mean?
_g suffixed files?
jni.h doesn't compile with my C compiler!
jni_md.h!
src.jar in your distribution. If you unpack this file (jar
-xvf src.jar should do it), one of the resulting directories is
src/launcher. It contains the files that we used to build
java, javac, jar and other programs of
the "launcher" ilk in the J2SDK. At the time of this writing we do not
provide any makefiles or instructions on how to compile these files;
nevertheless the source is simple to understand. We will add instructions in
a future release.
JNI_CreateJavaVM always returns -1!jvm.dll
file. The location of jvm.dll is important, it has to be in the
directory <jre>/bin/classic. This jvm.dll
finds the location of other DLLs relative to its current location. So if you
move it, or Windows uses some other copy of jvm.dll, the JVM will
not be able to find java.dll, for instance.
The problem manifests itself for those using the invocation API who want
to keep their PATH simple, containing only
<jre>\bin. You need
<jre>\bin\classic;<jre>\bin in your
PATH. This does not work:
# Do not do this!
cd jre\bin
copy classic\jvm.dll .
Our motivation for doing this change is that when the Java HotSpot TM virtual machine ships, it can drop-in to an existing Java 2 Runtime Environment. However, there is an ease of issue this raises, and we are looking at addressing the issue in a future release. Note that on Windows you can use also use the registry key:
HKEY_LOCAL_MACHINE\Software\JavaSoft\JRE\RuntimeLib
to find the path to jvm.dll and load it with
LoadLibrary. We also suggest you take a look at our launcher
source code (see also previous question) to see how we currently solve this
problem.
javai.dll? jvm.dll takes the role of
javai.dll in JDK 1.1. The JNI invocation functions such as
JNI_CreateJavaVM, and old NMI methods such as
makeJavaString are now present in jvm.dll. We
understand that this an issue for customers with pre-existing shared libraries
and applications that are linked against javai.dll. One
workaround, if you have the object files, is to re-link the application. We
are working on a workaround for users who don't have access to the object
files (watch these pages).
The forthcoming HotSpot VM and the currently shipping Solaris
production VM do not support the old NMI. JNI, however, is
supported by all of them.
6. What does "symbol
The alternate form of this question is:
makeJavaString not found" mean?
I use a third party library (a JDBC driver, actually) that contains native
code. When running my application with this library, I get an
"UnsatisfiedLinkError: symbol makeJavaString not found." What gives?
The problem is that the native code in that third party library uses the old
NMI (see also previous question). Make sure you are running this on the
classic VM. You should also contact your library vendor for an upgrade.
7. What is the latest scoop on documentation?
The author of this page has also heard of, but not read, Essential JNI: Java
Native Interface, 1/e, from Prentice Hall.
8. (Solaris) Has support for native threads gotten any better?
Yes. As of JDK/JRE 1.1.3 you could download a Solaris
Native Threads Pack which was fully supported. In the Java 2 SDK, native
threads is integrated into the release. If you use the invocation API on
Solaris to embed the JVM into your application, we recommend the use of the
native threads VM (see also Q11 on linker issues on Solaris).
| $$ | Windows users
note: you can add debugging information to foobar.dll, but you
should link against MSVCRT.DLL, and not MSVCRTD.DLL.
|
A small subset of developers want to debug both the JVM and
and their native code. For such uses, debug information is not
available in the optimized JVM. If you must do this, and you rarely should
have to, we suggest that you download the Java 2 SDK through Sun Community Source
Licensing, and build it with debug symbols.
Please do not send us mail asking for a version the header files for some
compiler not listed above or some older version of the compilers listed above!
Chances are we do not have that compiler; if we did you wouldn't have had a
problem in the first place. We suggest that you consult your compiler
documentation. Two common problems are reported with Windows compilers are:
10.
The oldest C compilers we have had success with are gcc-2.7.2.3 on
Unix, Sun C Compiler v4.2, Microsoft Visual C++ 5.0, and Borland C++ 5.0.
Newer versions of these compilers work as well. If you are using a different
compiler or a older version of these compilers, you might need to modify our
header files.
jni.h doesn't compile with my C compiler!
__int64 in
jni_md.h. You should fix this by adding:
#ifdef FOOBAR_COMPILER
#define __int64 signed_64_bit_type
#endif
where signed_64_bit_type is the name of the signed 64 bit type
supported by your compiler.
11. (Solaris) What linker issues should I be aware of?
When embedding the JVM into an application, we recommend that you use the
native threads VM. Note that an application that uses Solaris native threads
must be linked -lthread -lc (consult the chapter "Compiling and
Debugging" in the Multithreaded Programming Guide in the Solaris Software Developer Collection).
In the Java 2 SDK and Runtime Environments, libjvm.so by
default tries to use native threads. This should not be confused with the
java command line program which defaults to green threads. [You
should easily infer that the java command overrides the default
behavior of libjvm.so].
Some error messages you might want to know more about:
-lthread, you are bound to see the following error message:
You must install a Solaris patch to run the native threads
version of the Java runtime. The green threads version will
work without this patch. Please check the native threads
release notes for more information.
If you are embedding the VM in a native application, please
make sure that the native application is linked with
libthread.so (-lthread)." Exiting.
If after linking your a.out with -lthread, you
continue to see the problem check if your libthread.so has a
symbol named __gettsp. You can check this by using the following
command:
$ nm /usr/lib/libthread.so | grep __gettsp
If you don't see that symbol you are missing the patches. Consult the SDK
release notes for further information on the patches.
libthread loaded into green threads
is produced if you (1) are running the green threads VM, (2) did a
System.loadLibrary("foo"), and (3) libfoo.so was
linked -lthread. Green threads and native threads don't mix
well and hence the check in the VM. You should use the native threads VM
instead.
jni_md.h! <jdk>\include\win32 or
<jdk>/include/solaris to the include path of your compiler.
Just <jdk>/include is not suffcient.
Comments? Email jni@java.sun.com.
Last modified: Tue Mar 23 14:02:03 PST 1999