<Swing Dev> JDK-8189938: Proposed patch

[Semyon Sadetsky]

I meant the case when MTA COM service is actually used, it might cause 
issues since the JDK code invokes an another API which assumes 
synchronization. At least performance may be affected.

We don't do separate testing of JDK in MTA mode especially on the 
regular base. That is why I wouldn't consider MTA mode as supported.

So, before push the change I would make sure of the regression test 
suite run in MTA mode hasn't brought any surprises.

--Semyon

On 02/08/2018 11:18 AM, Matthias Bläsing wrote:

> Resend: I accidentally dropped swing-dev from receivers (@Semyon I'm
> subscribed to swing-dev, so we could direct the mails to the
> mailinglist)
>
>
> Hey Semyon,
>
> Am Donnerstag, den 08.02.2018, 10:52 -0800 schrieb Semyon Sadetsky:
>> Since you are suggesting to switch from STA to MTA which
>> consequences
>> will it have to the current JDK code that was written to support STA
>> only?
> I think there are two questions hidden here:
>
> === How does this affect the common codepath taken today? ===
>
> It does not. It only changes the behaviour if CoInitalize fails. So
> behavioural changes can only occur in environments that did not work
> previously.
>
> Before this changeset:
>
>   * CoInitialize works => The ShellFolder code can be used as is
>   * CoInitialize failes => The ShellFolder code raises an exception
>
> After this changeset:
>
>   * CoInitialize works => The ShellFolder code can be used as is
>   * CoInitialize failes => retry CoInitializeEx with multi-threaded
>     apartment
>   * if CoInitializeEx fails for multi-threaded apartment raise exception
>     as before
>
> === Is it expected to cause problems in the new code path? ====
>
> My understanding of STA vs. MTA is, that it only affects calls from
> native to java and not the other way round.
>
> To get calls from outside you'd need to install a callback. My
> understanding is, that you'd need to use an IConnectionPoint and call
> its Advise method. I did not spot any such methods.
>
> So while I did not go through the whole code base, I think this
> changeset should be save.
>
> Greetings
>
> Matthias
>
>> On 02/08/2018 10:32 AM, Matthias Bläsing wrote:
>>> referring to this bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8189938
>>>
>>> With the instructions given in:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8193928 (closed as
>>> duplicate of JDK-8189938)
>>>
>>> I was able to reproduce the problem on a clean Windows 10
>>> Installation,
>>> as described in the initial report.
>>>
>>> The resulting exception leads to my proposed fix:
>>>
>>>           Could not initialize COM: HRESULT=0x80010106
>>>
>>> That HRESULT translates to: RPC_E_CHANGED_MODE
>>>
>>> This means, that the COM subsystem is already initialized, but with
>>> a
>>> different mode. The code uses CoInitialize and this initializes the
>>> threading module to be apartment threaded. The above HRESULT means
>>> the
>>> thread was already initialized to be multi-threaded.
>>>
>>> The mode can't be changed after is was set once, so instead of
>>> bailing
>>> out, I suggest to accept the situation and initialize to be multi-
>>> threaded.
>>>
>>> The consequence is that calls from COM to Java could end up on the
>>> wrong thread. A quick look through the code suggest, that COM
>>> advises
>>> are not used, so this is a risk that should be taken.
>>>
>>> The fix in this case works like this:
>>>
>>>    * try to initialize COM as it was
>>>    * check the return
>>>    * if it is RPC_E_CHANGED_MODE, retry initialization als multi-
>>> threaded
>>>    * only if that fails raise an exception