Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
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. 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 Enhancements in JDK 1.2
jar -xvf src.jar
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:
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.
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?
Solaris Native Threads Pack
Lest you ask, we have always used only native threads on the Win32 platforms.
Developers writing native methods liked the
_g files because they could have their build environment produce two shared libraries
foobar_g.dll, where the latter would contain debug information. This is still possible with the Java 2 SDK; you should setup your native library builds so debug information is available in the file named
foobar.dll $$ . That way you will still be able to debug your native methods.
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:
jni_md.h. You should fix this by adding:
#ifdef FOOBAR_COMPILER #define __int64 signed_64_bit_type #endif
signed_64_bit_typeis the name of the signed 64 bit type supported by your compiler.
-lthread -lcMultithreaded Programming GuideSolaris 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
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
-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:
If you don't see that symbol you are missing the patches. Consult the SDK release notes for further information on the patches.
$ nm /usr/lib/libthread.so | grep __gettsp
libthread loaded into green threads
System.loadLibrary("foo"), and (3)
-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.
Windows users note: you can add debugging information to
foobar.dll, but you should link against
MSVCRT.DLL, and not