The Sandbox

Consists of three parts (copied from  http://www.javaworld.com/javaworld/jw-05-1997/jw-05-security.htm .)

      The byte code verifier:

                    The Byte Code Verifier is the first prong of the Java security model. When a Java source program is compiled, it compiles down to platform-independent Java
                    byte code. Java byte code is "verified" before it can run. This verification scheme is meant to ensure that the byte code, which may or may not have been
                    created by a Java compiler, plays by the rules. After all, byte code could well have been created by a "hostile compiler" that assembled byte code designed to
                    crash the Java virtual machine. Verifying an applet's byte code is one way in which Java automatically checks untrusted outside code before it is allowed to
                    run. The Verifier checks byte code at a number of different levels. The simplest test makes sure that the format of a byte-code fragment is correct. On a less
                    basic level, a built-in theorem prover is applied to each code fragment. The theorem prover helps to make sure that byte code does not forge pointers, violate
                    access restrictions, or access objects using incorrect type information. The verification process, in concert with the security features built into the language
                    through the compiler, helps to establish a base set of security guarantees.

       The applet class loader:

                    The second prong of security defense is the Java Applet Class Loader. All Java objects belong to classes. The Applet Class Loader determines when and
                    how an applet can add classes to a running Java environment. Part of its job is to make sure that important parts of the Java run-time environment are not
                    replaced by code that an applet tries to install. In general, a running Java environment can have many Class Loaders active, each defining its own "name
                    space." Name spaces allow Java classes to be separated into distinct "kinds" according to where they originate. The Applet Class Loader, which is typically
                    supplied by the browser vendor, loads all applets and the classes they reference. When an applet loads across the network, the Applet Class Loader receives
                    the binary data and instantiates it as a new class.

         The security manager:

                    The third prong of the Java security model is the Java Security Manager. This part of the security model restricts the ways in which an applet can use visible
                    interfaces. Thus the Security Manager implements a good portion of the entire security model. The Security Manager is a single module that can perform
                    run-time checks on "dangerous" methods. Code in the Java library consults the Security Manager whenever a dangerous operation is about to be attempted.
                    The Security Manager is given a chance to veto the operation by generating a Security Exception (the bane of Java developers everywhere). Decisions made
                    by the Security Manager take into account which Class Loader loaded the requesting class. Built-in classes are given more privilege than classes that have
                    been loaded over the net.
 

Things you cannot do inside the sandbox

Alternatives to the sandbox
Microsoft's ActiveX uses signed codes.  These codes can do any anything, but are only run after checking the signature.  Further, these codes are i386 machine language

Advantages to the sandbox

Advantages to ActiveX