The system classes ClassLoader, SecurityManager, and FileInputStream have constructors that check if they are called from an applet, and throw a SecurityException if so. Unfortunately, while the Java language prohibits the following code, the bytecode verifier readily accepted its bytecode equivalent:

CL() {
try { super(); }
catch (Exception e) {}
}

}

This allowed an hostile applet to create its own system classes such as ClassLoader and SecurityManager, and gave it the ability to defeat Java's type system. Since the hostile applet could inherit those system classes, it was allowed to get and set the value of any non-static variable, and call any protected methods and native methods. For instance, creating a ClassLoader allows an applet to modify the class hierarchy, as it can read and write variables normally only visible to the runtime system.

Netscape Navigator 3.0 and Microsoft Internet Explorer fix the superclass constructor issue and take other measures to prevent applets from instantiating ClassLoaders.