AppContext

Class Overview

The AppContext is a table referenced by ThreadGroup which stores application service instances. (If you are not writing an application service, or don't know what one is, please do not use this class.) The AppContext allows applet access to what would otherwise be potentially dangerous services, such as the ability to peek at EventQueues or change the look-and-feel of a Swing application.

Most application services use a singleton object to provide their services, either as a default (such as getSystemEventQueue or getDefaultToolkit) or as static methods with class data (System). The AppContext works with the former method by extending the concept of "default" to be ThreadGroup-specific. Application services lookup their singleton in the AppContext.

For example, here we have a Foo service, with its pre-AppContext code:

    public class Foo {
        private static Foo defaultFoo = new Foo();

        public static Foo getDefaultFoo() {
            return defaultFoo;
        }

    ... Foo service methods
    }

The problem with the above is that the Foo service is global in scope, so that applets and other untrusted code can execute methods on the single, shared Foo instance. The Foo service therefore either needs to block its use by untrusted code using a SecurityManager test, or restrict its capabilities so that it doesn't matter if untrusted code executes it.

Here's the Foo class written to use the AppContext:

    public class Foo {
        public static Foo getDefaultFoo() {
            Foo foo = (Foo)AppContext.getAppContext().get(Foo.class);
            if (foo == null) {
                foo = new Foo();
                getAppContext().put(Foo.class, foo);
            }
            return foo;
        }

    ... Foo service methods
    }

Since a separate AppContext can exist for each ThreadGroup, trusted and untrusted code have access to different Foo instances. This allows untrusted code access to "system-wide" services -- the service remains within the AppContext "sandbox". For example, say a malicious applet wants to peek all of the key events on the EventQueue to listen for passwords; if separate EventQueues are used for each ThreadGroup using AppContexts, the only key events that applet will be able to listen to are its own. A more reasonable applet request would be to change the Swing default look-and-feel; with that default stored in an AppContext, the applet's look-and-feel will change without disrupting other applets or potentially the browser itself.

Because the AppContext is a facility for safely extending application service support to applets, none of its methods may be blocked by a a SecurityManager check in a valid Java implementation. Applets may therefore safely invoke any of its methods without worry of being blocked. Note: If a SecurityManager is installed which derives from sun.awt.AWTSecurityManager, it may override the AWTSecurityManager.getAppContext() method to return the proper AppContext based on the execution context, in the case where the default ThreadGroup-based AppContext indexing would return the main "system" AppContext. For example, in an applet situation, if a system thread calls into an applet, rather than returning the main "system" AppContext (the one corresponding to the system thread), an installed AWTSecurityManager may return the applet's AppContext based on the execution context.

Summary

[Expand] Inherited Methods

From class java.lang.Object Object clone() Creates and returns a copy of this object. boolean equals(Object obj) Indicates whether some other object is "equal to" this one. void finalize() Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. final Class<?> getClass() Returns the runtime class of this Object. int hashCode() Returns a hash code value for the object. final void notify() Wakes up a single thread that is waiting on this object's monitor. final void notifyAll() Wakes up all threads that are waiting on this object's monitor. String toString() Returns a string representation of the object. final void wait() Causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object. final void wait(long timeout, int nanos) Causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object, or some other thread interrupts the current thread, or a certain amount of real time has elapsed. final void wait(long timeout) Causes the current thread to wait until either another thread invokes the notify() method or the notifyAll() method for this object, or a specified amount of time has elapsed.