Hi all, this sounds good for JDK 11. And I agree with Phil, that September this year is absolutely ok.
It might be worth though to update the bug report with the information from my "Updated analysis" mail. The most important part would be, that there is a work around: * either force the users to have the updates VC++ 12.0 binaries installed (by introducing the depdency cited in the blog post) or * replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages I tested the second variant: Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned Reinhards testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem we are discussing (Initialization of COM fails). I then replaced the msvcr120.dlls in the JRE folder of my systems installation with the one contained in the APPX container from: https://www.microsoft.com/en-us/download/details.aspx?id=53176 Hint: *.appx are just ZIP files with additional signatures, so you can just rename them and extract the contents. I rebuild the testcase and it is working as it should (no COM initialization errors anymore). For anyone wanting to build java apps for the windows store this should be trivial and help with updates. Greetings Matthias PS: I added Reinhard to the recipients, as he started this. Am Donnerstag, den 22.02.2018, 10:36 -0800 schrieb Phil Race: > And since JDK 11 has a GA date of mid-September this year .. it is > not many years off > like it might have been in the past for these toolchain updates. > > > -phil. > > On 02/22/2018 07:16 AM, Erik Joelsson wrote: > > (Note that I'm not subscribed to swing-dev so delivery there may be > > delayed) > > Hello Matthias, > > We are indeed working on changing the toolchain versions used for > > building JDK 11 at Oracle. For Windows, we are aiming for VS2017, > > currently 15.5.5. There are several issues that need to be resolved > > first to even get it to compile however. You can get a list of the > > relevant bugs here: > > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%2011-cp-upgr > > ade > > JDK 8 and 7 are built with VS2010 SP1. We upgraded to 2013 SP4 for > > JDK 9. > > /Erik > > > > On 2018-02-21 18:33, Semyon Sadetsky wrote: > > > Hi Erik, > > > There is a message on Swing alias from a guy who did > > > investigation why after migrating to VS 2103 java starts to crash > > > with InternalError when running apps in UWP mode on Windows. UWP > > > mode is not supported officially but it had worked till 8. > > > Starting 9 it doesn't work and it is a VS 2013 bug. > > > Are there any plans to update VS version? As per the > > > information below compiling with VS 2015+ fixes the issue. You > > > could reply directly to the thread. > > > --Semyon > > > > > > -------- Forwarded Message -------- > > > Subject: Re: <Swing Dev> JDK-8189938: Updated analysis > > > Date: Wed, 21 Feb 2018 22:54:24 +0100 > > > From: Matthias Bläsing <mblaes...@doppel-helix.eu> > > > To: swing-dev@openjdk.java.net > > > > > > Hi again, > > > > > > I debugged the issue a bit further and I think I tracked it down > > > into > > > the visual c runtime. What got me curious, was that in any case > > > MTA-COM > > > initialization had already happend even when a new java thread > > > was > > > created. So I modified the java launcher (jvm.dll) and inserted > > > debugging statements into some of the native methods in > > > os_windows.cpp. > > > I focused on the threading methods. What I found was this: > > > > > > - create_main_thread, create_os_thread, pd_start_thread all > > > run with COM not yet initialized > > > - the native thread initializer (thread_native_entry) is already > > > running with COM initialized > > > > > > Every article I read about COM insists, that your are required to > > > initialize the COM environment on each thread from which you do > > > COM > > > calls. So there was something fishy. > > > > > > I looked more into in _beginthreadex and indeed I finally found a > > > lead > > > on stackoverflow. That pointed me to the sourcecode of > > > threadex.c, > > > which is part of the Visual Studio 2013 Express Installation. > > > > > > There you find, that _beginthreadex does not directly start the > > > supplied thread function, but runs a library initializer > > > (_threadstartex) first. Part of this initializer reads: > > > > > > _ptd->_initapartment = __crtIsPackagedApp(); > > > if (_ptd->_initapartment) > > > { > > > _ptd->_initapartment = _initMTAoncurrentthread(); > > > } > > > > > > _callthreadstartex(); > > > > > > __crtIsPackagedApp detects via a kernel function if the > > > application is > > > run as a "PackagedApp" (i.e. AppX package) and if so, then the > > > RoInitialize is called, which from my understanding acts like the > > > big > > > brother of CoInitialize. > > > > > > Long story short: If your application is build with Visual Studio > > > 2013 > > > and run as a packaged application, you get a broken environment. > > > > > > I assume that the Oracle JDK 8 binaries are build with an older > > > version > > > of Visual Studio, which would explain the behavioural > > > differences. > > > > > > This looks like it supports my findings: > > > > > > https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c > > > -runtime-in-centennial-project/ > > > > > > Quote from the article: > > > > > > Note that the existing VC++ 12.0 libraries created during > > > the > > > Windows 8 timeframe have runtime checks to determine > > > whether the > > > app is running under the app container or not. When > > > running > > > desktop apps as a packaged app, these checks might limit > > > the > > > functionality of the desktop app or cause it to behave > > > like a UWA > > > (Universal Windows Application) (limited file system > > > access or > > > create thread initializing MTA etc.). We have fixed this > > > behavior > > > in the VC++ libraries contained in these framework > > > packages and > > > thus removing the modern app limitations from your > > > desktop > > > applications. > > > > > > So the solution for packagers is: > > > > > > - Read the above referenced blog > > > - Install the updated VC 12.0 framework packages for Desktop > > > Bridge > > > - Install the appropriate contained appx packages (I tested > > > Retail/x64) > > > - Package again > > > - Done > > > > > > After the steps above my test application (a modified version of > > > the > > > original version from Reinhard) reports, that the COM > > > initialization > > > has not happend yet and everything is as it should be > > > (initialization > > > in the JDKs ShellFolder native part is correctly initialized to > > > STA). > > > > > > => Yay! > > > > > > I suspect a java version compiled with a "fixed" version of > > > Visual > > > Studio (2015 and later) should behave "correctly". It took much > > > effort > > > not to write what I'm thinking about VS 2013 right now. > > > > > > If I'm not mistaken the default compiler for future JDKs is about > > > to be > > > bumped (I think I read something like this on one of the openjdk > > > mailinglists), so could someone please check if it has happend > > > already? > > > > > > After literally putting hours into this, I think I will conclude > > > my > > > investigations here - it was an interesting ride through the JDK > > > build > > > system, the JDK source and VS documentation. > > > > > > I hope this helps someone out there > > > > > > Greetings > > > > > > Matthias > > > > > > Am Donnerstag, den 08.02.2018, 19:32 +0100 schrieb Matthias > > > Bläsing: > > > > Hi all, > > > > > > > > last month I saw the message from Reinhard Pointer on this > > > list: > > > > > > > > http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/0 > > > 08132. > > > > html > > > > > > > > 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 > > > > > > > > One could argue, that if COM is already initialized, you don't > > > need > > > > to > > > > do it yourself, but documentation states, that every successful > > > call > > > > to > > > > CoInitialize/CoInitializeEx must be paired with CoUninitialize. > > > > > > > > D3DPipelineManager tracks this in bComInitialized, the other > > > two > > > > callers in the JDK are: > > > > > > > > - PLATFORM_API_WinOS_DirectSound.cpp > > > > - ShellFolder2.cpp > > > > > > > > Both are covered in the patches. For ShellFolder2 there is an > > > > initialization check, this is modified as described above. And > > > if > > > > both > > > > initialization variant (apartment threaded and multi threaded > > > fail) > > > > this raises an exception. > > > > > > > > PLATFORM_API_WinOS_DirectSound is slightly different. The > > > fallback in > > > > the initialization is still done, but no exception is raised in > > > the > > > > error case. This follows the code flow before this change. > > > > > > > > I attached the diffs against JDK10 and JDK9 to this email. If > > > they > > > > are > > > > stripped, they can be found here: > > > > > > > > http://www.doppel-helix.eu/JDK8189938-openjdk9.diff > > > > http://www.doppel-helix.eu/JDK8189938-openjdk10.diff > > > > > > > > I hope this helps with a fix. > > > > > > > > Greetings > > > > > > > > Matthias > > >
