我维护一个使用Jacob或Java-COM Bridge的旧版Java应用程序，以通过MS VBA和MS Word的COM接口(interface)进行调用。我一直在看Sun的com4j，它看起来很有希望。
对我来说看起来不错的原因是，它使用vtable绑定(bind)方法而不是IDispatch。假设我们操纵的所有COM对象都存在vtable接口(interface)，则使用它们代替IDispatch看起来更干净。早在COM和CORBA都采用热二进制接口(interface)技术的时代，我似乎还记得通过vtable进行早期绑定(bind)要比通过IDispatch进行后期绑定(bind)具有更好的性能。
有没有人从Jacob迁移到com4j？如果是这样，有哪些陷阱和经验教训？
最佳答案
在针对简单的COM对象进行集成时，我同时使用了Jacob和Com4j。我之所以选择Com4j，主要是因为Jacob泄漏了太多内存。与Jacob相比，我认为Com4j设置完成后会更加直截了当。如果我没记错的话，Jacob在进行实际的COM调用之前需要进行更多的设置和键入操作。在Com4j中，您将只使用提供的工厂。
Com4j一直为我们工作正常，但在途中遇到了一些麻烦。首先，生成的接口(interface)未正确生成，我们需要手动对其进行调整。我记得的主要问题是我们无法使@ReturnValue批注正常工作。另外，我们需要手动更正@VTID枚举。
我们面临的另一项主要事情是，我们不能将Holder(out params)类用于short。我们最终做了一个Delphi包装器，从Integer转换为Short，而不是对Com4j进行了任何更改。
最后，我记得我在整合时对项目状态有些担心。似乎没有定期更新(自上次维护版本以来已经两年了)。
关于java - com4j与jacob从Java调用COM方法，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2066318/