Microsoft SDK for Java

J/Direct Troubleshooting Tips

The following topics describe problems that you might encounter when using Microsoft® J/Direct™. For each situation, possible solutions are provided.

UnsatisfiedLinkError When Calling a Method

Getting SecurityException When Calling a DLL Method or Using an @dll.struct Class

StringBuffers Truncated on Return From DLL Function

Mysterious Syntax Errors Within @dll Directives

Compiler Cannot Find Basic System Packages Like java.lang

Compiler Cannot Find the com.ms.dll Package

Syntax Errors When Using J/Direct with Inner Classes

@dll Directives Do Not Work on Applets (or Only Works Within the Microsoft Visual J++ Environment)

Using J/Direct Makes Class Unusable

J/Direct Throws a ParameterCountMismatchError After Calling a Native Function

J/Direct Does Not Unload a DLL

UnsatisfiedLinkError When Calling a Method

The Microsoft VM 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.

  // This method is exported as ordinal #34.
  /** @dll.import("MyDll",entrypoint="#34") */
  public static native void MySample();

Getting SecurityException When Calling a DLL Method or Using an @dll.struct Class

DLL calling and the use of @dll.struct classes is restricted to Java applications and signed Java applets. For more information about signing applets, see Signing Cabinet Files with Java Permissions.

StringBuffers Truncated on Return From DLL Function

Ensure that the StringBuffer's capacity is sufficient to contain the String you need before invoking the DLL function. Specify the capacity in the StringBuffer's constructor and use the StringBuffer.ensureCapacity method to guarantee a minimum capacity prior to the DLL call.

Mysterious Syntax Errors Within @dll Directives

Extra white space within @dll.import and @dll.struct directives can cause syntax errors. Avoid using white space inside @dll constructs.

Compiler Cannot Find Basic System Packages Like java.lang

The compiler shipped with the Microsoft SDK for Java looks for system packages in the Classes.zip file. This conflicts with the new Java Package Management scheme used by the Microsoft VM. This scheme stores system packages as .zip files with obfuscated names under the %Windir%\Java\Packages directory. Unfortunately, the Java Language Compiler has not yet been updated to recognize this new scheme. To compile Java programs against the new VM, you must create an old-style .zip file and ensure that it is included in the class path.

The SDK installation program normally does this for you. If, however, you installed the SDK by some other method or if your configuration has been corrupted since the installation, you may need to re-create Classes.zip. The easiest way to do this is to type the following at the command prompt.

clspack -auto

This creates a single Classes.zip in your %WINDIR%\Java\Classes directory, which contains all classes stored in the Java Package Manager. The Microsoft compiler for Java looks for classes in this location by default, so there's no need to set your CLASSPATH environment variable.

Compiler Cannot Find the com.ms.dll Package

An older version of Classes.zip is being used. Try renaming all older versions of Classes.zip on your hard disk and follow the instructions under Compiler Cannot Find Basic System Packages Like java.lang for creating a new Classes.zip file.

Syntax Errors When Using J/Direct with Inner Classes

The version of the Java compiler that ships with the SDK for Java does not correctly handle @dll directives on inner classes or classes that contain inner class declarations.

@dll Directives Do Not Work on Applets (or Only Works Within the Microsoft Visual J++ Environment)

Because the use of J/Direct can compromise security, its use is restricted to Java applications and signed Java applets. For more information about signing applets, see Signing Cabinet Files with Java Permissions.

Using J/Direct Makes Class Unusable

Any use of J/Direct within a class marks that class as unsafe and unusable by untrusted code, even if the J/Direct methods are not actually invoked.

J/Direct Throws a ParameterCountMismatchError After Calling a Native Function

The ParameterCountMismatchError exception alerts you when the called function consumed more or fewer numbers of parameters than were passed by J/Direct. This error normally indicates that the parameters in the Java method declaration do not match the number of parameters expected by the DLL function.

If the function consumed no arguments, it is assumed to be using the __cdecl calling convention. An exception is not thrown, even if the Java method declares a non-zero number of arguments.

CAUTION   Do not attempt to catch and deal with the ParameterCountMismatchError exception. This exception was designed to assist developers in catching bugs during the development stage. For performance reasons, parameter count checking is performed only when the application is running under a Java debugger. It is also important to note that J/Direct performs this check after the function call has been completed. Because this exception indicates that one or more invalid parameters might have been passed to the function call, it cannot be guaranteed that the process can recover.

J/Direct Does Not Unload a DLL

J/Direct unloads a DLL when the Microsoft VM discards the Java class that imported the DLL. For a Java application running under jview, this does not occur until the process exits. For a trusted Java applet, this happens at some undetermined time after the browser has left the page containing the applet. The Microsoft VM attempts to keep Java classes loaded for several pages afterward to optimize applet refresh time in case the page is revisited.

If you need explicit control over the loading and unloading of DLLs, call the Windows loader explicitly and use the call entrypoint to invoke functions dynamically. For more information on how to do this, see Dynamically Loading and Invoking DLLs.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.