(转载)Swing中的AppContext使用

来自http://www.javafaq.nu/java-bookpage-13-5.html

2.5    AppContext service

class sun.awt.AppContext [platform specific]

 

Warning: AppContext is not meant to be used by any developer, as it is not part of the Java 2 core API. We are discussing it here only to facilitate a more thorough understanding of how Swing service classes work behind the scenes.

 

AppContext is an application/applet (we'll say "app" for short) service table that is unique to each Java session (applet or application). For applets, a separate AppContext exists for each SecurityContext which corresponds to an applet's codebase. For instance, if we have two applets on the same page, each using code from a different directory, both of those applets would have distinct SecurityContexts associated with them. If, however, they each were loaded from the same codebase, they would necessarily share a SecurityContext. Java applications do not have SecurityContexts. Rather, they run in namespaces which are distinguished by ClassLoaders. We will not go into the details of SecurityContexts or ClassLoaders here, but it suffices to say that they can be used by SecurityManagers to indicate security domains, and the AppContext class is designed to take advantage of this by only allowing one instance of itself to exist per security domain. In this way, applets from different codebases cannot access each other's AppContext. So why is this significant? We're getting there...

 

A shared instance is an instance of a class that is normally retreivable using a static method defined in that class. Each AppContext maintains a Hashtable of shared instances available to the associated security domain, and each instances is referred to as a service. When a service is requested for the first time it registers its shared instance with the associated AppContext. This consists of creating a new instance of itself and adding it to the AppContext key/value mapping.

 

One reason these shared instances are registered with an AppContext instead of being implemented as normal static instances, directly retreivable by the service class, is for security purposes. Services registered with an AppContext can only be accessed by trusted apps, whereas classes directly providing static instances of themselves allow these instances to be used on a global basis (requiring us to implement our own security mechanism if we want to limit access to them). Another reason for this is robustness. The less applets interact with each other in undocumented ways, the more robust they can be.

 

For example, suppose an app tries to access all of the key events on the system EventQueue (where all events get queued for processing in the event-dispatching thread) to try and steal passwords. By using distinct EventQueues in each AppContext, the only key events that the app would have access to are its own. (There is in fact only one EventQueue per AppContext.)

 

So how do we access our AppContext to add, remove, and retrieve services? AppContext is not meant to be accessed by developers. But we can if we really need to, and this would guarantee that our code would never be certified as 100% pure, because AppContext is not part of the core API. Nevertheless, here's what is involved: The static AppContext.getAppContext() method determines the correct AppContext to use depending on whether we are running an applet or application. We can then use the returned AppletContext's put(), get(), and remove() methods to manage shared instances. In order to do this we would need to implement our own methods such as the following:

 

    private static Object appContextGet(Object key) {

 

      return sun.awt.AppContext.getAppContext().get(key);

 

    }

 

    private static void appContextPut(Object key, Object value) {

 

      sun.awt.AppContext.getAppContext().put(key, value);

 

    }

 

    private static void appContextRemove(Object key) {

 

      sun.awt.AppContext.getAppContext().remove(key);

 

    }

 

In Swing, this functionality is implemented as three SwingUtilities static methods (refer to SwingUtilities.java source code):

 

    static void appContextPut(Object key, Object value)

 

    static void appContextRemove(Object key, Object value)

 

    static Object appContextGet(Object key)

 

However, we cannot access these because they are package private. These are the methods used by Swing's service classes. Some of the Swing service classes that register shared instances with AppContext include: EventQueue, TimerQueue, ToolTipManager, RepaintManager, FocusManager and UIManager.LAFState (all of which we will discuss at some point in this book). Interestingly, SwingUtilities secretly provides an invisible Frame instance registered with AppContext to act as the parent to all JDialogs and JWindows with null owners.