<Swing Dev> swing-dev Digest, Vol 130, Issue 13
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Mon Feb 12 05:21:13 UTC 2018
Hi Reinhard,
This is the event log from powershell. I took a look into
http://go.microsoft.com/fwlink/?LinkId=235160 but could not get
0x80070005 error code there, but it seems to be a general access denied
problem. Not sure what access rights I need to give.
Get-AppxLog -ActivityID 02867602-9e78-0003-0675-8902789ed301
Time ID Message
---- -- -------
2/12/2018 10:46:04 AM 603 Started deployment Register
operation on a package with main parameter:
AppxManifest.xml and Options:
DevelopmentModeOption. See
http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app
deployment issues.
2/12/2018 10:46:04 AM 10002 Creating Resiliency File
C:\ProgramData\Microsoft\Windows\AppRepository\0e4badcc
-4375-4273-8437-a272b775a415_S-1-5-21-582946636-1726034447-2572216908-1005_1.rsl
c for Register Operation on
Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a.
2/12/2018 10:46:04 AM 607 Deployment Register operation on
package JDK8189938_1.0.0.0_x64__hz258y3tkez3a
has been de-queued and is
running for user SID
S-1-5-21-582946636-1726034447-2572216908-1005.
2/12/2018 10:46:04 AM 613 Adding uri to the list of Uris:
D:\prasanta\bug8189938\JDK-8189938-master\dist\appx\AppxManifest.xml.
2/12/2018 10:46:05 AM 492 In-place package update policy
result for JDK8189938_1.0.0.0_x64__hz258y3tkez3a
- staging: false, applying false
2/12/2018 10:46:05 AM 468 error 0x80070005: Failed to set
access rights to appx.
2/12/2018 10:46:05 AM 605 The last successful state reached
was PreStagePackagesInUseClosed. Failure
occurred before reaching the
next state Staged. hr: 0x80070005
2/12/2018 10:46:05 AM 401 Deployment Register operation
with target volume C: on Package
JDK8189938_1.0.0.0_x64__hz258y3tkez3a from: (AppxManifest.xml) failed with
error 0x80070005. See
http://go.microsoft.com/fwlink/?LinkId=235160 for help
diagnosing app deployment issues.
2/12/2018 10:46:05 AM 404 AppX Deployment operation failed
for package
JDK8189938_1.0.0.0_x64__hz258y3tkez3a with error 0x80070005. The
specific error
text for this failure is:
Deployment Register operation with target volume C:
on Package
JDK8189938_1.0.0.0_x64__hz258y3tkez3a from: (AppxManifest.xml)
failed with error 0x80070005.
See http://go.microsoft.com/fwlink/?LinkId=235160
for help diagnosing app
deployment issues.
PS D:\prasanta\bug8189938\JDK-8189938-master>
Regards
Prasanta
On 2/9/2018 9:28 PM, Reinhard Pointner wrote:
> Hi Prasanta,
>
> Thanks for looking into this issue. When doing Windows development,
> the Event Log is sometimes quite useful. The error output hints at
> some additional information in the Windows Event Log. Have you had a
> look to see if there's any hints as to why it's not working on your
> test machine?
>
> >> NOTE: For additional information, look for *[ActivityId]
> 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log* or use the
> command line *Get-AppxLog -ActivityID
> 02867602-9e78-0006-8ffb-8802789ed301*
> *
> *
> Kind Regards,
> Reinhard
>
> On 9 February 2018 at 16:23, Prasanta Sadhukhan
> <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> wrote:
>
> Hi Reinhard,
>
> Yes, I was running as a Administrator. But, I created another
> Standard user and login through that but I still get the same problem.
>
> Regards
> Prasanta
> On 2/9/2018 12:09 PM, Reinhard Pointner wrote:
>> Dear Prasanta,
>>
>> The ant script calls the Add-AppxPackage function and fails with
>> this error message:
>> "Add-AppxPackage : Deployment failed with HRESULT: 0x80070005,
>> Access is denied."
>>
>> Are you running CMD / PowerShell as Administrator? I search for
>> this error message on Google, and I found a few results were
>> running as normal user (and not as Administrator) solved the
>> issue. I've tried again myself as well, and I can easily
>> reproduce the issue on a newly factory reset Windows 10 machine
>> with the latest updates running the build via CMD as my normal user.
>>
>> Greetings,
>> Reinhard
>>
>> On 9 February 2018 at 12:58, <swing-dev-request at openjdk.java.net
>> <mailto:swing-dev-request at openjdk.java.net>> wrote:
>>
>> Send swing-dev mailing list submissions to
>> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mail.openjdk.java.net/mailman/listinfo/swing-dev
>> <http://mail.openjdk.java.net/mailman/listinfo/swing-dev>
>> or, via email, send a message with subject or body 'help' to
>> swing-dev-request at openjdk.java.net
>> <mailto:swing-dev-request at openjdk.java.net>
>>
>> You can reach the person managing the list at
>> swing-dev-owner at openjdk.java.net
>> <mailto:swing-dev-owner at openjdk.java.net>
>>
>> When replying, please edit your Subject line so it is more
>> specific
>> than "Re: Contents of swing-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
>> 2. Re: JDK-8189938: Proposed patch (Matthias Bl?sing)
>> 3. Re: JDK-8189938: Proposed patch (Sergey Bylokhov)
>> 4. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
>> 5. Re: JDK-8189938: Proposed patch (Prasanta Sadhukhan)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 8 Feb 2018 12:06:04 -0800
>> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
>> <mailto:semyon.sadetsky at oracle.com>>
>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>> <mailto:mblaesing at doppel-helix.eu>>,
>> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>> Message-ID: <31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com
>> <mailto:31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> 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
>> <https://bugs.openjdk.java.net/browse/JDK-8189938>
>> >>>>
>> >>>> With the instructions given in:
>> >>>>
>> >>>> https://bugs.openjdk.java.net/browse/JDK-8193928
>> <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
>> >
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 08 Feb 2018 22:19:51 +0100
>> From: Matthias Bl?sing <mblaesing at doppel-helix.eu
>> <mailto:mblaesing at doppel-helix.eu>>
>> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
>> <mailto:semyon.sadetsky at oracle.com>>,
>> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>> Message-ID: <1518124791.13185.19.camel at doppel-helix.eu
>> <mailto:1518124791.13185.19.camel at doppel-helix.eu>>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Hi,
>>
>> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb 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.
>>
>> I tried to find some documentation how the
>> FullTrustProcessLauncher of
>> an UWP application works, but while the MSDN full of
>> documentation
>> about UWP, the lifecycle of a native application seems not to be
>> covered. But my suspicion is this: The launching of an APPX
>> package
>> involves the runtime system creating an environment for the
>> application
>> and that seems to rely heavily on COM.
>>
>> So I assume, that COM is initialized outside the java core
>> and the java
>> process get this inherited. (But this is speculation!).
>>
>> I base this on the fact, that CoInitializeEx succeeds and multi
>> threaded, but fails appartment threaded and the JDK code
>> holds exactly
>> three files calling CoInitialize (D2DPipelineManager.cpp,
>> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>>
>> > 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.
>>
>> Aggreed and I'd like to help you, but in fact I was happy, that I
>> managed to compile the JDK on windows and I have zero experience
>> working on the JDK sources.
>>
>> As an observation: The COM initialization and usage looked
>> pretty tight
>> together in the sources and at least initialization happens
>> only in the
>> three files mentioned above. The DirectSound part is even
>> limit to a
>> small thread. The ShellFolder2 code looks to be the biggest
>> direct
>> user.
>>
>> Greetings,
>> Matthias
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 8 Feb 2018 13:58:32 -0800
>> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com
>> <mailto:Sergey.Bylokhov at oracle.com>>
>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>> <mailto:mblaesing at doppel-helix.eu>>,
>> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>> Message-ID: <340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com
>> <mailto:340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hi, Matthias.
>> Did you have a chance to find why this code works on
>> jdk8u152(this is
>> reported in the bug description).
>>
>> On 08/02/2018 10:32, Matthias Bl?sing wrote:
>> > Hi all,
>> >
>> > last month I saw the message from Reinhard Pointer on this
>> list:
>> >
>> >
>> http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html
>> <http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html>
>> >
>> > referring to this bug:
>> >
>> > https://bugs.openjdk.java.net/browse/JDK-8189938
>> <https://bugs.openjdk.java.net/browse/JDK-8189938>
>> >
>> > With the instructions given in:
>> >
>> > https://bugs.openjdk.java.net/browse/JDK-8193928
>> <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-openjdk9.diff>
>> > http://www.doppel-helix.eu/JDK8189938-openjdk10.diff
>> <http://www.doppel-helix.eu/JDK8189938-openjdk10.diff>
>> >
>> > I hope this helps with a fix.
>> >
>> > Greetings
>> >
>> > Matthias
>> >
>>
>>
>> --
>> Best regards, Sergey.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 8 Feb 2018 14:42:12 -0800
>> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
>> <mailto:semyon.sadetsky at oracle.com>>
>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>> <mailto:mblaesing at doppel-helix.eu>>,
>> swing-dev at openjdk.java.net
>> <mailto:swing-dev at openjdk.java.net>, Prasanta Sadhukhan
>> <prasanta.sadhukhan at oracle.com
>> <mailto:prasanta.sadhukhan at oracle.com>>
>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>> Message-ID: <d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com
>> <mailto:d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>>
>> > Hi,
>> >
>> > Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb 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.
>> > I tried to find some documentation how the
>> FullTrustProcessLauncher of
>> > an UWP application works, but while the MSDN full of
>> documentation
>> > about UWP, the lifecycle of a native application seems not
>> to be
>> > covered. But my suspicion is this: The launching of an APPX
>> package
>> > involves the runtime system creating an environment for the
>> application
>> > and that seems to rely heavily on COM.
>> It looks like there is an internal reason. Probably for UWP
>> apps only
>> MTA is allowed because of their life-cycle (the app may be
>> suspended).
>> > So I assume, that COM is initialized outside the java core
>> and the java
>> > process get this inherited. (But this is speculation!).
>> >
>> > I base this on the fact, that CoInitializeEx succeeds and multi
>> > threaded, but fails appartment threaded and the JDK code
>> holds exactly
>> > three files calling CoInitialize (D2DPipelineManager.cpp,
>> > ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>> >
>> >> 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.
>> > Aggreed and I'd like to help you, but in fact I was happy,
>> that I
>> > managed to compile the JDK on windows and I have zero
>> experience
>> > working on the JDK sources.
>> Prasanta,
>>
>> since the bug is assigned to you can you test the suggested
>> fix in MTA
>> mode and sponsor it if there are no issues?
>>
>> --Semyon
>> >
>> > As an observation: The COM initialization and usage looked
>> pretty tight
>> > together in the sources and at least initialization happens
>> only in the
>> > three files mentioned above. The DirectSound part is even
>> limit to a
>> > small thread. The ShellFolder2 code looks to be the biggest
>> direct
>> > user.
>> >
>> > Greetings,
>> > Matthias
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Fri, 9 Feb 2018 11:24:30 +0530
>> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com
>> <mailto:prasanta.sadhukhan at oracle.com>>
>> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
>> <mailto:semyon.sadetsky at oracle.com>>, Matthias Bl?sing
>> <mblaesing at doppel-helix.eu
>> <mailto:mblaesing at doppel-helix.eu>>,
>> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>> Message-ID: <ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com
>> <mailto:ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hi,
>>
>>
>> On 2/9/2018 4:12 AM, Semyon Sadetsky wrote:
>> > On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>> >
>> >> Hi,
>> >>
>> >> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb 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.
>> >> I tried to find some documentation how the
>> FullTrustProcessLauncher of
>> >> an UWP application works, but while the MSDN full of
>> documentation
>> >> about UWP, the lifecycle of a native application seems not
>> to be
>> >> covered. But my suspicion is this: The launching of an
>> APPX package
>> >> involves the runtime system creating an environment for
>> the application
>> >> and that seems to rely heavily on COM.
>> > It looks like there is an internal reason. Probably for UWP
>> apps only
>> > MTA is allowed because of their life-cycle (the app may be
>> suspended).
>> >> So I assume, that COM is initialized outside the java core
>> and the java
>> >> process get this inherited. (But this is speculation!).
>> >>
>> >> I base this on the fact, that CoInitializeEx succeeds and
>> multi
>> >> threaded, but fails appartment threaded and the JDK code
>> holds exactly
>> >> three files calling CoInitialize (D2DPipelineManager.cpp,
>> >> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>> >>
>> >>> 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.
>> >> Aggreed and I'd like to help you, but in fact I was happy,
>> that I
>> >> managed to compile the JDK on windows and I have zero
>> experience
>> >> working on the JDK sources.
>> > Prasanta,
>> >
>> > since the bug is assigned to you can you test the suggested
>> fix in MTA
>> > mode and sponsor it if there are no issues?
>> >
>> I am still not able to reproduce in our WIndows 10 Pro
>> (EN-W10P64-10.0.01.0). "Developer Mode" and "execute
>> powershell script"
>> is enabled. This is what I am getting
>> $ ant clean appx install
>> Buildfile: D:\prasanta\8189938\JDK-8189938-master\build.xml
>>
>> clean:
>> ?? [delete] Deleting directory
>> D:\prasanta\8189938\JDK-8189938-master\bin
>> ?? [delete] Deleting directory
>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>> ??? [mkdir] Created dir:
>> D:\prasanta\8189938\JDK-8189938-master\bin
>> ??? [mkdir] Created dir:
>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>>
>> build:
>> ??? [javac] Compiling 1 source file to
>> D:\prasanta\8189938\JDK-8189938-master\bin
>> ??? [javac] warning: [options] bootstrap class path not set in
>> conjunction with -source 9
>> ??? [javac] 1 warning
>> ????? [jar] Building jar:
>> D:\prasanta\8189938\JDK-8189938-master\dist\appx\main.jar
>>
>> appx:
>> ???? [copy] Copying 5 files to
>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>> ???? [exec] Expected SHA256 checksum:
>> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
>> ???? [exec] Actual SHA256 checksum:
>> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
>> ???? [exec] Download complete: jre-9.0.4_windows-x64_bin.tar.gz
>> ??? [untar] Expanding:
>> D:\prasanta\8189938\JDK-8189938-master\jre-9.0.4_windows-x64_bin.tar.gz
>> into D:\prasanta\8189938\JDK-8189938-master\dist\appx\jre
>>
>> install:
>> ???? [exec] Add-AppxPackage : Deployment failed with HRESULT:
>> 0x80070005, Access is denied.
>> ???? [exec] Deployment Register operation with target volume
>> C: on
>> Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a from:
>> ???? [exec] (AppxManifest.xml)? failed with error
>> 0x80070005. See
>> http://go.microsoft.com/fwlink/?LinkId=235160
>> <http://go.microsoft.com/fwlink/?LinkId=235160> for help
>> ???? [exec] diagnosing app deployment issues.
>> ???? [exec] NOTE: For additional information, look for
>> [ActivityId]
>> 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log or use
>> ???? [exec] the command line Get-AppxLog -ActivityID
>> 02867602-9e78-0006-8ffb-8802789ed301
>> ???? [exec] At line:1 char:1
>> ???? [exec] + Add-AppxPackage -Register
>> dist/appx/AppxManifest.xml
>> ???? [exec] +
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ???? [exec]???? + CategoryInfo????????? : SecurityError:
>> (D:\prasanta\818...ppxManifest.xml:String) [Add-AppxPackage],
>> PSSecurityE
>> ???? [exec]??? xception
>> ???? [exec]???? + FullyQualifiedErrorId :
>> DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
>> ???? [exec]
>> ???? [exec] Result: 1
>>
>> BUILD SUCCESSFUL
>> Total time: 6 seconds
>>
>> ARAPTE-PC+client at ARAPTE-PC
>> /cygdrive/d/prasanta/8189938/JDK-8189938-master
>> $ ls
>> appx? bin? build.xml? dist? get-java.ps1
>> jre-9.0.4_windows-x64_bin.tar.gz? LICENSE? README.md
>> screenshot.png? src
>>
>> ARAPTE-PC+client at ARAPTE-PC
>> /cygdrive/d/prasanta/8189938/JDK-8189938-master
>> $ JDK8189938
>> bash: JDK8189938: command not found
>>
>> Regards
>> Prasanta
>> > --Semyon
>> >>
>> >> As an observation: The COM initialization and usage looked
>> pretty tight
>> >> together in the sources and at least initialization
>> happens only in the
>> >> three files mentioned above. The DirectSound part is even
>> limit to a
>> >> small thread. The ShellFolder2 code looks to be the
>> biggest direct
>> >> user.
>> >>
>> >> Greetings,
>> >> Matthias
>> >
>>
>>
>>
>> End of swing-dev Digest, Vol 130, Issue 13
>> ******************************************
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180212/cad0c44b/attachment.html>
More information about the swing-dev
mailing list