Frequently Asked Questions

JNI Enhancements in JDK 1.2

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

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?

• The section on JNI in the The Java Tutorial is a good starting point.
• Watch out for the forthcoming Essential JNI: Java Native Interface, 1/e .

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.dll and 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:

• Your compiler might not like __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.

   

• The macros JNIEXPORT and JNIIMPORT might need fixing to use the syntax for linkage directives supported by your compiler.

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:

• If your application embedding the native threads VM is not linked against -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.

   

• The error message

  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.

$$

Windows users note: you can add debugging information to foobar.dll, but you should link against MSVCRT.DLL, and not MSVCRTD.DLL.