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.
