this code will actually look pretty damn normal

One thing that you need to be aware of is that you're really only supposed to call CoInitialize once per thread, and you should only call CoUninitialize at thread exit.

Now, this probably won't cause a problem if you're using JINI or whatever to call C++ methods, since you'll be doing it from a Java app. It becomes a problem when those functions are called from a C or C++ application that has already initialized COM. For one thing, your call will return S_FALSE (in the best-case), or RPC_E_CHANGED_MODE (in a worst case).

To understand what I mean about "worst-case", go and read up on threading models in COM. To cut a long story short, there are two main thread models in COM:

The first is the single threaded apartment model (STA), where you guarantee that a call to an object will only occur on the thread that created it (and, conversely, COM guarantees that it'll only ever call you back on the same thread). It's called "apartment", because you can have several different apartments in an application, each with their own thread. This is what you get when you call CoInitialize().

The second is the multi-threaded apartment model (MTA), where the apartment contains multiple threads, and you can issue calls on any one of them, and receive callbacks on any one of them. You get into this mode by calling CoInitializeEx and passing a different flag.

Now, some components are only compatible with a single model. This doesn't generally cause a problem, because COM will sort out the marshalling correctly -- as long as you don't lie about your requirements and the component doesn't lie about its.

Anyway, the point of this is that you're not allowed to change modes once you've initialised COM, which means that it's generally a bad idea to try to initialise COM from a library function, because it might have been initialised with a different mode already.