Removal of COMThread broke simplification usecase of the COM.util package

[matthiasblaesing]

@dhakehurst raised in a comment to pullrequest #649 the following issue in regard to the removal of the COMThread from jna codebase:

Part of the purpose of the ...COM.util classes (ProxyObject etc) is (was) to create a 'nicer' java like interface over the COM interactions.
For example, so that the user of the classes does not need to know anything about COM threading issues,
and doesn't have to make calls such as "Ole32.INSTANCE.CoInitializeEx(Pointer.NULL, Ole32.COINIT_MULTITHREADED);"

If the client codes wants to have that level of control it should use the ...COM classes directly.

Your recent modifications of the COM.util classes have changed the use case significantly,
and consequently I cannot move my client code to using the latest version of JNA.

[matthiasblaesing]

Thanks for starting this discussion - indeed I failed to explain why I went ahead and removed the COMThread. While it looked like a good idea when looking at it at first, I became less enthusiastic at that time.

Basicly the util classes have a different approach to the basic COM classes, that uses much less boiler plate code and move the common code into the basic module (wrapping, dispatch handling, memory handling) and this can now used at the price, that you need to initialize COM in the threads that access the COM methods.

While I see that this is break in the API (a massive one), I consider it worth it. The proxy approach can now be used in MTA and STA mode, provided the user prepares the environment correctly (that would be calling the CoInitializeEx/CoUninitialize pair).

In fact the save part of the current api could be reimplemented see:

https://gist.github.com/matthiasblaesing/72c0b4751d52ebfd4406a72e5c7fe6d0

The idea, layer a single threaded factory on top of the basic factory. This factory wraps the COM objects into a layer, that pushes them into the thread executor.

I still would strongly advice against using callbacks in this scenario, but for a basic usecase this might be ok.

At first I tried to stay with the single thread approach, but then I tried to enhance it and uglyness entered. To be able to handle callbacks, I introduces a "COM initialized" flag, that would allow the callback and the factory to be used in the callback thread (which is by definition COM initialized), but that flag needed to be maintained.

Another pain point were the places, where calls had to be pushed into the COM thread. Then Interrupted-, Execution- and TimeoutException were caught and rethrown as a RuntimeException. The interesting question: what happens when the COM call comes back, after the TimeoutException happened? In all fairness I have no idea, but I don't want to try.

[dhakehurst]

My usecase for this involves many different java threads accessing the COM objects, hence the reason I included the ComThread in my original implementation of this.

I accept that this does make it a bottle neck, and there may be other usecases that require something like you suggest.

Is there a way that we can have both options available?

[matthiasblaesing]

@dhakehurst did you have a look at the gist I referenced? The idea is, that you can replace the Factory class with COMFactory, that will do the same "move calling into one central thread" handling, that the old Factory did.

I ran the Word MSDN sample through this and that works as I'd expect. I have to think about the callback handlers, but maybe I could retrofit the "mark thread as COM thread approach".

If this works out, I see this option:

• move the current Factory to another name - "BaseFactory" or something along the lines
• reintroduce COMThread
• Move COMFactory from the gist into the project under the name "Factory"

[dhakehurst]

That sounds like it could work.
I can't look in detail until next week.
But I will do.

On Thursday, 5 May 2016, matthiasblaesing [email protected] wrote:

@dhakehurst https://github.com/dhakehurst did you have a look at the
gist I referenced? The idea is, that you can replace the Factory class with
COMFactory, that will do the same "move calling into one central thread"
handling, that the old Factory did.

I ran the Word MSDN sample through this and that works as I'd expect. I
have to think about the callback handlers, but maybe I could retrofit the
"mark thread as COM thread approach".

If this works out, I see this option:

• move the current Factory to another name - "BaseFactory" or
  something along the lines
• reintroduce COMThread
• Move COMFactory from the gist into the project under the name
  "Factory"

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#651 (comment)

[matthiasblaesing]

@dhakehurst - I made a prototype implementation available as:

https://github.com/matthiasblaesing/jna/tree/simple_com_htread

I added unittests to cover the new baseclass ObjectFactory and the old Factory. This is pretty much the implementation sketched above.

[dhakehurst]

this looks like it could work,
I will need a bit more time to test it out.

On 8 May 2016 at 16:56, matthiasblaesing [email protected] wrote:

@dhakehurst https://github.com/dhakehurst - I made a prototype
implementation available as:

https://github.com/matthiasblaesing/jna/tree/simple_com_htread

I added unittests to cover the new baseclass ObjectFactory and the old
Factory. This is pretty much the implementation sketched above.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#651 (comment)