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.IllegalAccessError: Class has been marked as nonpublic to untrusted code.
java.lang.NoClassDefFoundError.
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 |
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 |
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:
|
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. |
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); |