Summary

As we've seen, under certain conditions a tool such as jCOM can come in pretty handy. Although perhaps not detente, it does make it possible for Microsoft and Java applications to live in peaceful coexistence. Let's face it: A huge investment has been laid out in each of these technologies. On either side, you'll find an ample supply of people passionate in their convictions about the inherent merits of a particular solution—a solution eagerly embraced by an all-too-firm commitment on the part of the advocates of each. Given the status quo, a closer merging of these heterogeneous paradigms doesn't seem likely anytime soon.

It is in this context that jCOM starts to make sense. Again, the most intriguing aspect here being transparency. Underlying object architectures can be effectively isolated, and thus completely hidden from view. This makes our life so much easier as programmers. The mundane chore (not to mention the training costs) of staying versed in the myriad of trivial syntactical permutations between languages can all but be eliminated. For Java programmers, the mantra of a pure Java, write-once-run-anywhere solution can be adhered to; COM developers can keep pumping out those COM components and IS managers can leverage benefits found in both worlds.

So, if you're looking for a stable yet seamless mechanism of communication between your Java and Microsoft objects, keep jCOM in mind—it might well turn out to be the method of choice.