<Swing Dev> JDK-8189938: Proposed patch

[Semyon Sadetsky]

Yet another question. Do you know what might call CoInitialize in a 
different mode? It looks like we use STA everywhere in JDK.

--Semyon


On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> 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
>