<Swing Dev> JDK-8189938: Proposed patch

[Matthias Bläsing]

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