Article ID: 172202 - Last Review: August 25, 2005 - Revision: 1.1 INFO: Implementing Java Automation Objects using AutoIDispatchThis article was previously published under Q172202 On This PageSUMMARY
Microsoft's VM for Java allows programmers to create two types of COM
objects with Java:
The second type is useful with "late binding" environments like Microsoft Visual Basic and the Microsoft scripting languages, VBScript and JScript. This article covers the creation and use of this type of COM object. MORE INFORMATION
In order to allow the use of Java objects in "late binding" environments
like Microsoft Visual Basic, VBScript, and JScript, the Microsoft VM for
Java implements IDispatch automatically for all Java objects. This feature
is called AutoIDispatch.
This means that Java programmers who need to use their Java objects only in these environments no longer need to create interface definition files (IDL/ODL). Also, tools like JAVATLB and JACTIVEX are no longer necessary since the Java object does not implement any custom COM interfaces that are defined in type libraries. When a Java object with AutoIDispatch is used as a COM object, all of its public methods and members are made available through the IDispatch interface. To implement a simple "late bound" automation object in Java using AutoIDispatch, you would do the following:
Sample 1: Using a Java object from Visual BasicA simple class could be defined as follows:From a command prompt that has javareg.exe in its path, type the following:
javareg.exe /register /class:Test /progid:My.Test
Using Visual Basic 4.0 or greater, create a simple project with code
similar to the following:
Sample 2: Using a Java object from ScriptingA simple applet class could be defined as follows:OTHER INFORMATIONIf for some reason, you need to turn off the AutoIDispatch feature for a specific class, you can do so by having your class implement the com.ms.com.NoAutoScripting interface. This interface does not contain any methods. It just tells the VM not to expose IDispatch for any of the instances of this class.AutoIDispatch has the limitation that only the public methods on your class can be invoked (via the IDispatch interface). Thus there is no need for clients to become aware of the interfaces implemented by the server. The limitation of AutoIDispatch is performance: Each method call (on a native client) requires two round trips to the server(GetIdsOfNames and Invoke). On a smart client (VB4) the results of GetIdsOfNames is cached so the two roundtrips only occur on the first call to a particular method. In addition there is slightly more overhead in calling/implementing Invoke vs. calling a vtable based COM method directly. In cross-machine situations these performance issues are reduced somewhat because of the latency caused by the process/net boundaries. Another limitation of AutoIDispatch is that the VM does not associate any Type Library information with the COM object. So when a client calls IDispatch::GetTypeInfo(), the Java COM object returns TYPE_E_ELEMENTNOTFOUND. Again, AutoIDispatch is useful only for "late bound" clients. Clients that require Type Library information cannot use AutoIDispatch based Java COM objects. REFERENCES
For the latest Knowledge Base articles and other support information on
Visual J++ and the SDK for Java, see the following page on the Microsoft
Technical Support site:
http://www.microsoft.com/mscorp/java/
(http://www.microsoft.com/mscorp/java/)
| Article Translations
|

Back to the top
