No results found

Your search did not match any results.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try “application” instead of “software.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions

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 & Answers

    Open all Close all
  • 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?
  • 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. My compiler can't find jni_md.h!
    <jdk>\include\win32<jdk>/include/solaris<jdk>/include
  • 13. How can I get the native window pointer of an AWT Window?

    $$

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