Microsoft SDK for Java

J/Direct Error Messages

There are several types of exceptions that might be thrown by the Microsoft virtual machine (Microsoft VM) when you are using Microsoft® J/Direct™.

For each of the following errors, possible causes and solutions are explained:

java.lang.SecurityException [class.method]: Only fully trusted classes can have native methods as members.

java.lang.IllegalAccessError: Class has been marked as nonpublic to untrusted code.

java.lang.SecurityException: J/Direct method has not been authorized for use on behalf of an untrusted caller.

java.lang.NoClassDefFoundError.

com.ms.security.SecurityExceptionEx: [host] J/direct method has not been authorized for use on behalf of an untrusted caller.

java.lang.SecurityException

Exception class java.lang.SecurityException
Message class.method: Only fully trusted classes can have native methods as members.
Possible Causes The native keyword has been used on a method that is a member of a class not loaded with full permissions (for example, an unsigned applet). This exception is only thrown if an attempt is made to invoke the native method.
Possible Solutions Digitally sign your applet requesting full permissions. For more information on signing applets, see Signing Cabinet Files with Java Permissions

java.lang.IllegalAccessError

Exception class java.lang.IllegalAccessError
Message The class has been marked as nonpublic to untrusted code.
Possible Causes An untrusted class has attempted to refer to a field or method of another class marked only for trusted use. Many of the system classes in the com.ms.com and com.ms.dll packages have been marked this way. A class can be marked as nonpublic to untrusted code using the @security directive as follows.

  /** @security(checkClassLinking=on) */

  public class ForTrustedUseOnly{

   ...

  }

Possible Solutions Digitally sign your applet requesting full permissions. For more information on signing applets, see Signing Cabinet Files with Java Permissions

java.lang.SecurityException

Exception class java.lang.SecurityException
Message The J/Direct method has not been authorized for use on behalf of an untrusted caller.
Possible Causes An untrusted class has invoked a trusted method that attempts to make a J/Direct call. Even if the class making the actual J/Direct call is trusted, the security manager will throw a SecurityException if any of the methods in the call stack belong to an untrusted class.
Possible Solutions Digitally sign your applet requesting full permissions. For more information on signing applets, see Signing Cabinet Files with Java Permissions.

You may also disable the security check by marking the class that attempts the J/Direct call with the @security directive as shown in the following example.

  /** @security(checkDllCalls=off) */
  public class SafeDllCalls{
   ...
  }

Note   Disabling this security check transfers responsibility for security from the Microsoft virtual machine to you. Remember that even with this security check disabled, you will still have to digitally sign the class for maximum trust. If you use the @security directive, ensure that the following statements are true:

  • All J/Direct methods are declared private.

  • Your class exposes only the functionality needed by the client.

  • Your class guards all access to these capabilities with appropriate security checks.

java.lang.NoClassDefFoundError

Exception Class java.lang.NoClassDefFoundError
Message None.
Possible Causes An untrusted class has attempted to load either a class marked with @dll.struct or a class generated using the jactivex tool. Although this is really a security violation (not a class loader error), a NoClassDefFoundError is thrown for backward compatibility purposes.
Possible Solutions Digitally sign your applet requesting full permissions. For more information on signing applets, see Signing Cabinet Files with Java Permissions.

com.ms.security.SecurityExceptionEx

Exception Class com.ms.security.SecurityExceptionEx
Message [Host] J/Direct method has not been authorized for use on behalf of an untrusted caller.
Possible Causes A J/Direct call was attempted from the init, start, stop, or destroy method of an applet. To make J/Direct calls during these methods, the applet must assert permissions even if the applet has been signed.
Possible Solutions Execute the following code to assert permissions.
  import com.ms.security.*;
    ...
  PolicyEngine.assertPermission(PermissionID.SYSTEM);

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