Frequently Asked Questions
Java TM 2 SDK v1.2 and JNI

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.

 


Questions

  1. Is there an updated version of the JNI spec?
  2. I hear the invocation API got simpler. Can I see some code?
  3. (Windows) JNI_CreateJavaVM always returns -1! *
  4. What happened to javai.dll?
  5. Are JDK 1.0 style native methods supported in Java 2?
  6. What does "symbol makeJavaString not found" mean?
  7. What is the latest scoop on documentation?
  8. (Solaris) Has support for native threads gotten any better?
  9. What about _g suffixed files?
  10. jni.h doesn't compile with my C compiler!
  11. (Solaris) What linker issues should I be aware of?
  12. Are native methods allowed in ClassLoader loaded classes?
  13. My compiler can't find jni_md.h!
  14. How can I get the native window pointer of an AWT Window?

Answers

1. Is there an updated version of the JNI spec?

JNI Enhancements in JDK 1.2

2. I hear the invocation API got simpler. Can I see some code?

src.jarjar -xvf src.jarsrc/launcherjavajavacjar

3. (Windows) JNI_CreateJavaVM always returns -1!

jvm.dlljvm.dll<jre>/bin/classicjvm.dlljvm.dlljava.dll

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
jvm.dllLoadLibrary

4. What happened to javai.dll?

jvm.dlljavai.dllJNI_CreateJavaVMmakeJavaStringjvm.dlljavai.dll

5. Are JDK 1.0 style native methods supported in Java 2?

Classic VM

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 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?

7. What is the latest scoop on documentation?

Essential JNI: Java Native Interface, 1/e

8. (Solaris) Has support for native threads gotten any better?

Solaris Native Threads Pack

Lest you ask, we have always used only native threads on the Win32 platforms.

9. What about _g suffixed files?

_gjava_g.exejavai_g.dlljdbjava_g

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.

10. jni.h doesn't compile with my C compiler!

oldest

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.

11. (Solaris) What linker issues should I be aware of?

-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 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.

12. Are native methods allowed in ClassLoader loaded classes?

13. My compiler can't find jni_md.h!

<jdk>\include\win32<jdk>/include/solaris<jdk>/include

14. How can I get the native window pointer of an AWT Window?


*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.


Last modified: Tue Mar 23 14:02:03 PST 1999

$$ Windows users note: you can add debugging information to foobar.dll, but you should link against MSVCRT.DLL, and not MSVCRTD.DLL.
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
JavaOne Banner
Java 8 banner (182)