In AWT, every component is bound to its platform specific peer at some point before it can be displayed or can receive events. Utilizing this mechanism, it is easy to bind your own peer-system to the entire AWT/Swing application. The class responsible for the creation of the peers in AWT model is java.awt.Toolkit. The Toolkit class is an actually abstract class and it is the Sun's implementation of the Toolkit packed in jdk that is actually doing to work of creating the platform specific (Windows or Motif) peers. The instantiation of the specific toolkit implementation is done in the static Toolkit.getDefaultToolkit() method. Fortunately, Sun provides a way to override the actually Toolkit implementation that is instantiated and used by the JVM. This is done by setting the system property awt.toolkit. The property can either be set by specifying "-Dawt.toolkit=<mytoolkit>" at the java command line or set in dynamically using System.setProperty("awt.toolkit", "mytoolkit") in your code. While it might not be Sun's original intension, the mechanism allows the developers to plug in own implementation of the Toolkit and thus implement their own peer system. Awtbridge exploits the same mechanism to introduce the possibility of enabling the AWT/Swing application development to other platforms.
It should be clear from section 2 that the peer system of AWT is created and managed by a specific Toolkit implementation. In awtbridge, the BridgeToolkit class is an abstract implementation of java.awt.Toolkit that provides some default peer implementation (BridgePeers) to the awt/swing application. Instead of managing the peer system directly, the toolkit delegates the peer system management to BridgeContext, for the reason explained below.
Since awtbridge is designed to allow awt/swing to be running in a client-server environment (where hundreds of applications could run concurrently on the server in single JVM), it is necessary to have a mechanism to contain particular instance of an application within the a specific context. For this, BridgeContext is used. The toolkit delegates the peer management entirely to an instance of BridgeContext with is associated with one application session.
The awtbridge further decomposes the operation of an (AWT/Swing) application to two distinctive aspects: the presentation (rendering) and interaction (input). By decoupling the presentation and interaction model it become possible to reuse particular interaction implementation with different compatible presentation implementations. (html presentation + form input, xml + form input, XUL + form input etc). This is done by making the BridgePeers to delegate the input and rendering to InputDelegate and RenderDelegate. The InputDelegate and RenderDelegate are assigned at the runtime by the BridgeRenderContext and BridgeInputContext respectively. BridgeInputContext and BridgeRenderContext are encapsulated by the BridgeContext to form a complete toolkit context (with both render and input).