Are the available Java-COM bridges like j-Integra, com4j and Jacob and others suitable to be used in a J2EE container? Which one is the most appropriate for that use? I need to evaluate the risk of JVM crashes, native memory leak and unmanaged thread creation (since it's not recommended in a J2EE container that uses thread pools) for the available Java-COM bridges available today.
+2
A:
I've used those bridges you mentioned. I would chose a very different approach, because of the things you said: crashes, mem leaks, and a lot of other stuff.
I would have a little Windows Server, using COM components since it is its native environment. In that little Windows Server you can expose some HTTP interfaces (WEB requests) you can use in your Java EE server to access COM components through Windows Server. That Windows Server can be an IIS with ASP.NET server, or a custom made program with a proprietary protocol you can write in C#, C++, C, VB.NET.
It's in my opinion, your safest choice. It will save you a lot of headaches when you go to production mode.
Pablo Santa Cruz
2010-10-29 16:14:15
This is a very interesting approach. A Web Service on IIS could safely encapsulate the COM interface to the J2EE server.
Renan Vinícius Mozone
2010-10-29 16:21:57
A:
One of the reason you need to use JAVA-COM bridge is you need some Windows based functionality which is not available in Unix based system. Few years back it was no MS WORD, EXCEL JAVA APIs were available on Unix. So if possible try to use native JAVA APIs to achieve Windows based functionality. Like using APACHE POI. Setting J-Integra on machine with high security settings is tricky and needs special considerations.
Abhijit
2010-10-29 17:44:45