tij0195.html

学习java的经典书籍

that this code has no knowledge that the server was implemented in Java.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">When
you run this program and the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>CreateObject(&#160;)</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
function is called, the Windows Registry is searched for the specified ProgID.
Among the information related to the ProgID is the name of the Java class file,
so in response the Java Virtual Machine is started, and the Java object
instantiated inside the JVM. From then on, the JVM takes care of the
interaction between the client and server code.
</FONT><a name="_Toc408018838"></a><P></DIV>
<A NAME="Heading614"></A><H3 ALIGN=LEFT>
Developing
COM clients in Java
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Now
let&#8217;s jump to the other side and develop a COM client in Java. This
program will call services in a COM server that&#8217;s installed on your
system. The example is a client for the server we implemented in the previous
example. While the code will look familiar to a Java programmer, what happens
behind the scenes is quite unusual. This example uses a server that happens to
be written in Java but applies to any ActiveX Control, ActiveX Automation
server, or ActiveX component installed in your system for which you have a type
library.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">First,
the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Jactivex</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
tool is applied to the server&#8217;s type library. 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Jactivex</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
has a number of options and switches, but in its basic form it reads a type
library and generates Java source files, which it stores in your 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>windows/Java/trustlib</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
directory. In the example line below, it is applied to the type library that
was generated for out COM Automation server.
</FONT><P></DIV><DIV ALIGN=LEFT><TT><FONT FACE="Courier New" SIZE=3 COLOR="Black">jactivex
/javatlb JavaAdder.tlb
</FONT></TT><P></DIV><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If,
after 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Jactivex</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
has finished, you take a look at your 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>windows/Java/trustlib</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
directory, you&#8217;ll find a new subdirectory called 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>javaadder</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
that contains the source files for a new package. This is the Java equivalent
of the type library. These files use compiler directives specific to the
Microsoft compiler: the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>@com</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
directives. The reason 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>jactivex</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
generated more than one file is that COM uses more than one entity to describe
a COM server (and also because I did not fine-tune the use of MIDL files and
the Java/COM tools).
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
file named 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Adder.java</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
is the equivalent of a 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>coclass</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
directive in a MIDL file: it&#8217;s the declaration of a COM class. The other
files are the Java equivalent of the COM interfaces exposed by the server.
These interfaces, such as 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Adder_DispatchDefault.java</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
are dispatch interfaces, part of the mechanism of interaction between an
Automation controller and an Automation server. The Java/COM integration
feature also supports the implementation and use of dual interfaces. IDispatch
and dual interfaces are beyond the scope of this appendix.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Below,
you can see the client code. The first line just imports the package generated
by 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>jactivex</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
Then an instance of the COM Automation server is created and used, as if it was
an ordinary Java class. Notice the typecast on the line where the COM object is
instantiated. This is consistent with the COM object model. In COM, the
programmer never has a reference to the whole object; instead, the programmer
can only have references to one or more of the interfaces implemented in the
class.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Instantiating
a Java object of the Adder class tells COM to activate the server and to create
an instance of this COM object. But then we must specify which interface we
want to use, choosing among the ones implemented by the server. This is exactly
what the typecast does. The interface used here is the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>default
dispatch interface
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
the standard interface that an Automation controller uses to communicate with
an Automation server (for details, see 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>Inside
COM
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
ibid.). Notice how simple it is to activate the server and select a COM
interface:
</FONT><P></DIV>

<font color="#990000"><PRE><font color="#0000ff">import</font> javaadder.*;

<font color="#0000ff">public</font> <font color="#0000ff">class</font> JavaClient {
  <font color="#0000ff">public</font> <font color="#0000ff">static</font> <font color="#0000ff">void</font> main(String [] args) {
    Adder_DispatchDefault iAdder =
         (Adder_DispatchDefault) <font color="#0000ff">new</font> Adder();
    iAdder.setAddend(3);
    iAdder.sum();
    iAdder.sum();
    iAdder.sum();
    System.out.println(iAdder.getResult());
  }
}</PRE></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Now
you can compile and run the code.
</FONT><P></DIV>
<A NAME="Heading615"></A><H4 ALIGN=LEFT>
The
com.ms.com package
</H4>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
<A NAME="Index3117"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>com.ms.com</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
package defines a number of classes for COM development. It supports the use of
GUIDs &#8211; the 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Variant</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>SafeArray</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
Automation types &#8211; interfacing with ActiveX Controls at a deeper level
and handling COM exceptions.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">I
cannot cover all of these topics here, but I want to point out something about
COM exceptions. By convention, virtually all COM functions return an HRESULT
value that tells you if the function invocation succeeded or not and why. But
if you look at the Java method signature in our server and client code, there
no HRESULT. Instead, we use the function return value to get data back from
some functions. The virtual machine is translating Java-style function calls
into COM-style function calls, even for the return parameter. But what happens
inside the virtual machine if one of the functions you call in the server fails
at the COM level? In this case, the JVM sees that the HRESULT value indicates a
failure and generates a native Java exception of class 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>com.ms.com.ComFailException</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
In this way, you can handle COM errors using Java exception handling instead of
checking function return values.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">To
learn more about the classes in this package, please refer to the Microsoft
documentation.
</FONT><a name="_Toc408018839"></a><P></DIV>
<A NAME="Heading616"></A><H3 ALIGN=LEFT>
ActiveX/Beans
integration
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">An
interesting result of Java/COM integration is the <A NAME="Index3118"></A>ActiveX/Beans
integration, by which a Java Bean can be hosted by an ActiveX container such as
VB or any Microsoft Office product, and an ActiveX Control can be hosted by a
Beans container such as Sun&#8217;s BeanBox. The Microsoft JVM takes care of
the details. An ActiveX Control is just a COM server exposing predefined,
required interfaces. A Bean is just a Java class that is compliant with a
specific programming style. At the time this was written, however, the
integration was not perfect. For example, the virtual machine is not able to
map the JavaBeans event model to the COM event model. If you want to handle
events from a <A NAME="Index3119"></A>Bean
inside an ActiveX container, the Bean must intercept system events such as
mouse actions via low-level techniques, not the standard JavaBeans delegation
event model.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Apart
from this, the ActiveX/Beans integration is extremely interesting. The concept
and tools are exactly the same as discussed above, so please consult
Microsoft&#8217;s documentation for more details.
</FONT><a name="_Toc408018840"></a><P></DIV>
<A NAME="Heading617"></A><H3 ALIGN=LEFT>
A
note about native methods and applets
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Native
methods face the security issue. When your Java code calls a native method, you
pass control outside of the virtual machine &#8220;sandbox.&#8221; The native
method has complete access to the operating system. Of course, this is exactly
what you want if you write native methods, but it is not acceptable for
applets, at least not implicitly. You don&#8217;t want an applet, downloaded
from a remote Internet server, to be free to play with the file system and
other critical areas of your machine unless you allow it to do so. To prevent
this situation with J/Direct, RNI, and COM integration, only trusted Java code
has permission to make native method calls. Different conditions must be met
depending on the feature the applet is trying to use. For example, an applet
that uses J/Direct must be digitally signed to indicate full trust. At the time
of this writing, not all of these security mechanisms are implemented (in the
Microsoft SDK for Java, beta 2), so keep an eye on the documentation as new
versions become available.
</FONT><a name="_Toc408018841"></a><P></DIV>

<div align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0194.html">Prev</a> | <a href="tij0196.html">Next</a>
</div>
</body></html>