Previous
Introduction
Next
| Using Java and COM Together |
Previous |
Introduction |
Next |
Most existing COM objects are not threadsafe. That is, clients are required to make all calls to that object from a single thread. In addition, this thread is required to process Window messages on a regular basis so that other threads can marshal calls to objects on that thread and that system message broadcasts do not get blocked. A thread that processes Window messages regularly is said to have a message pump.
Furthermore, some COM objects are not even apartment-aware. These objects are not only restricted to a single thread, but are restricted to a specific thread known as the main apartment thread (the first thread that calls CoInitialize becomes the main apartment thread for the process.)
The Java Support in Internet Explorer hides most of these details from the Java programmer as described in the following sections.
When a Java class representing a COM object is instantiated using "new", the Internet Explorer's Java support obtains the COM object's threading model from the registry.
If the threading model is "Both" or "Free", the object is assumed to be thread-safe and is instantiated on the calling thread. Any method call on this object will translate directly to a method call on the underlying COM object on the calling thread.
If the threading model is "Single", the Internet Explorer's Java support automatically marshals to the process main apartment thread to create the object. Furthermore, Internet Explorer's Java support marshals all method calls on this object back to the main apartment thread. This represents additional overhead but this is what's required for non-thread-safe objects.
If the threading model is "Apartment", Internet Explorer's Java support marshals the creation and calls in similar fashion. The choice of thread is determined as follows. If the creating thread is considered "apartment-hostable", the object is created on that thread. Otherwise, the object is created on a special apartment thread created automatically by the Internet Explorer's Java support (all objects created in this fashion share one special apartment thread: the Internet Explorer's Java support does not create a new thread for every object.)
Java proxies for COM objects are also created whenever a Java method is passed an object from COM, or whenever Java receives an object from a COM method via a return value. In this case, there is no registry entry that provides the threading model of the object. Internet Explorer's Java support must be told explicitly whether the interface can be assumed to be thread-safe, or if it must marshal all calls to the thread on which the interface was received.
JavaTLB adopts a conservative policy and marks all interface parameters as requiring marshaling.
Even if the interface parameter is marked as requiring marshaling, Internet Explorer's Java support may produce a non-marshaling proxy in two cases:
The Internet Explorer's Java support can only create a marshaling proxy on a thread that is apartment-hostable (if a call is made to a Java proxy which is itself hosted on an apartment thread, proxies for the parameters to that call are made on that apartment thread; hence, this requirement is satisfied automatically). If the thread is not apartment-hostable, the proxy creation will fail with a ClassCastException.
