java/com Integration

COM (formerly known as OLE) represents Microsoft's "Component Object Model" (Component object models), which is the basis for all ActiveX technologies, including ActiveX controls, automation, and ActiveX documents. But COM also contains more stuff. It is a special specification that the component objects that it develops can be "interoperable" through the specialized features of the operating system. In practical applications, all the new software developed for WIN32 system has a certain relationship with COM-the operating system reveals some of its features through COM objects. Components developed by other vendors can also be built on a COM basis, and we can create and register our own COM components. In this or that form, if we want to write Win32 code, then we have to deal with COM. Here, we will simply restate the basic concepts of COM programming, and assume that the reader has mastered the concept of a COM server (any COM object that can serve COM customers) and a COM client (a COM object that can request services from a COM server). This section will make the narrative as simple as possible. The actual functionality of the tools is much more powerful, and we can use them in a more advanced way. But it also requires a deeper understanding of COM, which is beyond the scope of this appendix. If you are interested in this powerful, but different platform-related feature, you should study COM and Microsoft's documentation and read carefully about the Java/com integration section. For more information, you are recommended by Dale Rogerson, "Inside COM", which was published by Microsoft Press in 1997.
Because COM is the core of all new WIN32 applications, the ability to use (or reveal) COM services through Java code is particularly important. Java/com integration is undoubtedly the most interesting feature of the Microsoft Java compiler and virtual machines. Java and COM are so similar on their models that the integration is conceptually intuitive and technically seamless--for access to COM, there is little need to write any special code. Most technical details are controlled by compilers and/or virtual machines. The end result is that Java programmers can treat COM objects like the original Java object. and COM customers can use a Java-implemented COM server as they would with other COM servers. Here is a reminder that although I am using the generic term "COM", it is possible to implement an ActiveX Automation server completely with Java and use an ActiveX control in a Java program, depending on the extension.
One of the most striking similarities between Java and COM is the relationship between the COM interface and the Java "interface" keyword. This is close to perfect a kind of match, because:
COM objects reveal interfaces (and only interfaces)
The COM interface itself does not have an implementation; The COM object that exposes the interface is responsible for its implementation
A COM interface is a description of a set of functions related to a semantic; No data will be revealed.
COM classes combine COM interfaces together. Java classes can implement any number of Java interfaces.
COM has a Reference object model; It is never possible for a programmer to "own" an object, only to obtain a reference to one or more interfaces to an object. Java also has a reference object model--a reference to an object that can be "shaped" into a reference to one of its interfaces.
The "lifetime" of a COM object in memory depends on the number of customers who use the object, and if the number becomes 0, the object deletes itself from memory. In Java, the lifetime of an object is also determined by the number of customers. If you no longer have a reference to that object, the object waits for the garbage collector to process it.

This close correspondence between Java and COM not only makes it easy for Java programmers to access COM features, but also makes Java a valid language for writing COM code. COM is language-independent, but COM development actually takes the language of C + + and visual Basic. C + + is more powerful when it comes to COM development than Java, and can generate more efficient code, but it's hard to use. Visual Basic is much simpler than Java, but it is too far from the underlying operating system, and its object model does not implement a good correspondence (mapping) relationship with COM. Java is a good compromise between the two.
Next, let's discuss some of the key issues of COM development. When writing java/com customers and servers, these issues need to be clarified first.