Error Messages

There are several types of exceptions that might be thrown by the Microsoft Win32 VM for Java 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 [class.method]: Only fully trusted classes can have native methods as members.

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 that is not loaded with full permissions (for example, an unsigned applet). This exception is thrown only 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 the article on Signing a Cabinet File with Java Permissions Using Signcode.

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

Exception Class	java.lang.IllegalAccessError
Message	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 that has been marked for trusted use only. 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 in the following way: /** @security(checkClassLinking=on) */ public class ForTrustedUseOnly{ ... }
Possible Solutions	Digitally sign your applet requesting full permissions. For more information on signing applets, see the article on Signing a Cabinet File with Java Permissions Using Signcode.

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

Exception Class	java.lang.SecurityException
Message	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 the article on Signing a Cabinet File with Java Permissions Using Signcode. Or, you could 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 VM for Java 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, you should 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 backwards compatibility purposes.
Possible Solutions	Digitally sign your applet requesting full permissions. For more information on signing applets, see the article on Signing a Cabinet File with Java Permissions Using Signcode.

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

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);