Microsoft KB Archive/180713

= PRB: Getting "Unsatisfied Link Error" When Using J/Direct =

Article ID: 180713

Article Last Modified on 11/14/2005

-

APPLIES TO


 * Microsoft Software Development Kit for Java 2.02
 * Microsoft Software Development Kit for Java 3.1
 * Microsoft Software Development Kit for Java 2.01
 * Microsoft Software Development Kit for Java 2.02
 * Microsoft Software Development Kit for Java 3.0
 * Microsoft Java Virtual Machine
 * Microsoft Visual J++ 1.0 Standard Edition
 * Microsoft Visual J++ 1.1 Standard Edition

-



This article was previously published under Q180713



SYMPTOMS
The following error message is generated when trying to run a Java application or applet that uses J/Direct:

Error: Java.lang.unsatisified link error...



CAUSE
This error can occur if an old version of the Java Language Compiler (JVC) is used. Make sure you are using Jvc.exe version 4337 or later. Version 4337 is shipped with the Microsoft SDK 2.0 for Java. Since J/Direct requires the use of compile-time directives like @dll.import (to import native methods from a DLL) it requires the latest version of Jvc.exe, which can recognize these compile-time directives.

NOTE: Microsoft virtual machine build 2252 (or higher) is required for J/Direct.



RESOLUTION
After you have installed the SDK for Java 2.0 or later, if you are trying to build your Java applet or application that uses J/Direct from within the Developer Studio, then add the SDK-Java\Bin directory to the Visual J++ executable files path as follows:
 * 1) From the Tools menu, point to Options and click the Directories tab.
 * 2) Under the Platform menu, make sure "Java Virtual Machine" is selected.
 * 3) Under "Show directories for," choose "Executable files."
 * 4) Include the directory "C:\SDK-Java\Bin" and click the up arrow until it is the first directory listed in the list box.

Or you can use the following steps instead:
 * 1) Back up your current Visual J++'s copy of Jvc.exe. You can locate this file in C:\Program Files\DevStudio\SharedIDE\bin.
 * 2) Then copy the following files from your SDK-Java\Bin directory (C:\SDK-Java\Bin) to C:\Program Files\DevStudio\SharedIDE\bin:


 * 1) * Jvc.exe
 * 2) * Jps.dll
 * 3) * Msjvc.dll.



STATUS
This behavior is by design.



MORE INFORMATION
The following is a check-list that you can use to trouble-shoot this problem if you are still seeing this error after upgrading to the Jvc.exe version 4337 or later.  Make sure your DLL is visible on the system path. DLLs are searched for in the following locations (in order):

 The directory from which the application (typically jview) is loaded The current directory The Windows system directory The Windows directory</li> The directories listed in the PATH environment variable</li></ol> </li> The Microsoft virtual machine will not attempt to load the DLL until a method requiring it is actually called. Therefore, do not assume that the DLL load was successful simply because the Java class loaded successfully. Check the method qualifiers. Methods declared with the @dll.import directive must be native and static. They can have any level of access (public, private, and so on) supported by the Java language.</li> Make sure that your method name matches the DLL export name exactly, including capitalization. The DLL linking mechanism in Win32 is case-sensitive.</li>  If you still have trouble linking to a method, use a utility such as dumpbin /exports (shipped with Visual C++) to verify that the DLL exports the method by the name you are using. Some DLLs may require you to link to exports by ordinal (an integer) rather than a name. In such a case, use the entrypoint override on the method using the "#ordinal" syntax as in the following example: // This method is exported as ordinal #34. /** @dll.import("MyDll",entrypoint="#34") */ public static native void MySample; </li> Be aware that some so-called functions are actually C macros and the actual DLL export name may be quite different from the name of the macro.</li>  Having a single @dll.import directive within a class definition, before all the method declarations inside that class, may also result in an UnsatisfiedLinkError. So try specifying the @dll.import prior to the class definition to set a library name for all native methods declared in that class. For example: /** @dll.import("KERNEL32") */ class Test {        public static native int GetEnvironmentStrings; public static native int GetEnvironmentVariable(String name,                                                    StringBuffer value,                                                     int ccbValue); }                       </li></ol>

This is equivalent to specifying @dll.import for each method. Also using the @dll.import directive at the class level saves space in the .class file and eliminates redundant information.

<div class="references_section">