Did you know that Java does COM Interop? Well using the MSJVM it can. Recently I deployed a project where a .Net Windows Service uses an externally supplied Java COM dll + associated jar file to communicate with IBM MQ. This is wonderful; Microsoft, Sun and IBM technologies playing together – a beautiful Interop example.
After several mock deployments to ensure no hiccups, go-live day arrived and it was a little shocking to notice the client’s machine was 2003 Server. All testing was done on Windows 2000!
You have guessed it already. The install did not take the expected 20 minutes, giving an error similar to this:
COM object with CLSID {……} is either not valid or not registered
Unflustered, regsvr32.exe was used to manually install the dll – it was no help. Searching the registry proved the COM dll was registered. Thoughts of an all nighter then set in. Unfortunately the original developer abandoned this code two weeks before go-live, so I was mostly in the dark about how the software worked. Luckily I remembered that it used some Java, and I once read an MSDN Article discussing the end of the MSJVM.
Due to legal issues Microsoft no longer distributes the MSJVM, but ships Sun’s own JVM with Windows 2003 Server. Unsurprisingly Sun’s JVM does not do COM interop. This is all fair-enough but:
1. The original error message was very misleading
2. Finding a copy of the MSJVM was not easy
If Microsoft or Sun really are concerned about interop both of these would be non-issues. The error message would have said ‘Installed JVM cannot perform COM Interop, you should use the Microsoft JVM’ + the MSJVM would be on Microsoft’s AND Sun’s JVM download page instead of neither. I thought the whole point of publicly swapping smelly sports jerseys was to show they understood the industry’s frustration with Interop issues?
Conclusion:
Interop is fraught with gotchas. Interop is unlikely to be well tested or well supported by vendors. Well known names like Ted Neward tell us to communicate through common and solid technologies such as databases, or even the file system when possible. I concur, even for message queuing I shun technologies like MSMQ if possible and queue to a database table. When Window Server 2006 arrives the table based solution will still work, who knows what will break in MSMQ or even if MSMQ will be there then because of Indigo.
