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
