From Sergey.Bylokhov at oracle.com  Mon Sep  3 23:36:26 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 3 Sep 2018 16:36:26 -0700
Subject: <AWT Dev> [12] Review Request: 8210286 Drop of sun.awt.HToolkit
	class
Message-ID: <26981c6e-9237-b8c8-574f-49fa0d49a46e@oracle.com>

Hello.
Please review the fix for jdk 12.

This class was used as a headless toolkit for embedded purposes.
  - It was added in the JDK-7030063
  - Its usage was removed in JDK-8140723 and JDK-8025673.

The usage of strings "sun.awt.HToolkit" and "javaplugin.version" in 
GraphicsEnvironment were also dropped, because both are never use.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210286
Webrev: http://cr.openjdk.java.net/~serb/8210286/webrev.00

-- 
Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Tue Sep  4 09:39:36 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 4 Sep 2018 09:39:36 +0000 (UTC)
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
Message-ID: <378efc00-ae1a-4e9c-861e-e563657486ce@default>

Hi All, Please find the updated Webrev per the discussion:

 

http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.02/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah 
Sent: Monday, July 30, 2018 1:32 PM
To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

 

Hi Prashanta, Thanks for your review. Below are my replies:

 

http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.01/

 

Thanks and regards,
Shashi

 

From: Prasanta Sadhukhan 
Sent: Friday, July 20, 2018 3:42 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

 

Hi Shashi,

The previous review thread is too long so probably need the original reviewer to take a look.
But here are my 2 cents

Can you please explain how the new API is supposed to be used? It says "Scaled icon for a file, directory, or folder as it would be displayed in a system file browser"

                getSystemIcon(File f, int width, int height)
            If the specified width, height is not available, then it will be scaled to available icon size, is it? I do not think the javadoc captures the essence of the api thoroughly.
            For example, if width/height asked for is 100 and we have icon of 96/96 and 128/128, then what it will return, the closest size 96/96 or the next positive one 128/128.

[Shashi] Yes. It will be scaled to the requested size. For the example that you mentioned, it is OS dependent. Typically it will pick up the higher resolution if available and scales it down to the requested level. If the higher resolution icon is not available then it will pick the lower one and scales it up. Hence I just happened to mention it as 'scaled icon' in the explanation.

As per fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8151385"JDK-8151385, MAX_ICON_SIZE=128 was added so even if you accept width/height as 256 (by your check it will still restrict icon size to 128)...

        287         if((width > 256 || width < 1) || (height > 256 || height < 1)) {
        288             System.err.println("Warning: Icon scaling may be distorted");
        289             throw new IllegalArgumentException("unexpected icon scaling size");
        290         }

            so maybe either increase MAX_ICON_SIZE or adjust your check accordingly. 

[Shashi] The size I have kept is in a similar scale that is available with the OS. Though there is an internal limit of 128, code is present to scale it to 256 if the user wants in such a way.

We normally do not throw unchecked exception (RuntimeException) from public API, so you should consider throwing checked exception instead.

[Shashi] Fixed this.

Also, you need to change javadoc to have @throws instead of @exception

[Shashi] Fixed this.

Also, it was asked, IIUC that the public API used MutliResolutionImage and uses HYPERLINK "https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html#getResolutionVariants%28%29"getResolutionVariants() to select appropriate icon image or let user select it (for case mentioned above, if we are not sure ourselves)

[Shashi] Since the icon is scaled to the levels that was requested and limits are mentioned as part of Javadoc comments. Fixed in the updated Webrev.

.        scaleIconImage, scaleIcon uses lot of common code so we can have a common method

[Shashi] Fixed this.

makeIcon(long hIcon, int bsize).. I guess parameter name bsize does not convey meaning, is it "bestsize"?

[Shashi] Just an alternative and no meaning for that.

.        int size = getLargeIcon ? 32 : 16; and also in Win32ShellFolderManager2. java probably you can have constants for these 2 number
.        Win32ShellFolderManager2
.        1118                         return getShell32Icon(4, size);
.        1119                     } else {
.        1120                         return getShell32Icon(1, size);

You should use constant to be more readable FILE_ICON_ID = 1; FOLDER_ICON_ID = 4;

[Shashi] For the constants, I have newly added some comments explaining that magic number. Adding a new constant is not worth as it is used only once!!

Regards
Prasanta

On 7/20/2018 12:02 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8182043

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/

 

History: This fix is derived from an earlier fix proposed under this mail thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html. Thanks to Semyon for that trial and part of this solution is continued from where it was left off.

 

Solution details: Large system icons were not able to be extracted because of sun package internal classes are not exposed anymore. This change adds a new api to get access to those icons.

 

Thanks and regards,

Shashi

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180904/39aaffd5/attachment-0001.html>

From Alan.Bateman at oracle.com  Tue Sep  4 12:34:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Sep 2018 13:34:45 +0100
Subject: <AWT Dev> RFR(M) : 8210039 : move OSInfo to top level
	testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <1ca44734-0f9e-1a4d-4479-ea72289efb44@oracle.com>



On 31/08/2018 19:42, Igor Ignatyev wrote:
> Alan, Chris,
>
> thanks for looking at it, I went w/ the alternative suggested by 
> Chris. that required a sprinkle of doPrivileged in the testlibrary, 
> but now Sockets/policy.* files grant the minimal required permissions 
> to the test code.
> the incremental webrev can found here[1], please let me know if you 
> need the whole webrev.
>
> [1] 
> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html 
> <http://cr.openjdk.java.net/%7Eiignatyev//8210039/webrev.0-1/index.html>
>
I can't quickly verify that the code source 
"file:${test.classes}/../../../../test/lib/-" results in granting the 
permission to the right library but I assume it will fail if it's not 
correct. So I think this approach looks good to me.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180904/263dd51c/attachment.html>

From chris.hegarty at oracle.com  Tue Sep  4 12:43:51 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 4 Sep 2018 13:43:51 +0100
Subject: <AWT Dev> RFR(M) : 8210039 : move OSInfo to top level
	testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <D21B3142-47C0-42A6-BE58-8C7176312FAD@oracle.com>

Igor,

> On 31 Aug 2018, at 19:42, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Alan, Chris,
> 
> thanks for looking at it, I went w/ the alternative suggested by Chris. that required a sprinkle of doPrivileged in the testlibrary, but now Sockets/policy.* files grant the minimal required permissions to the test code.

It?s bit annoying to have retrofit the test library classes with doPriv,
but I think that it is the right approach, if we intend them to be
usable with tests running with a security manager ( which we do ).

> the incremental webrev can found here[1], please let me know if you need the whole webrev.
> 
> [1] http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html <http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html>
I think this is fine.

Thanks,
-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180904/0514df0b/attachment.html>

From bourges.laurent at gmail.com  Tue Sep  4 12:56:38 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 4 Sep 2018 14:56:38 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
Message-ID: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>

Phil & Sergey,

I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
times the GUI hanging with AWT-EventQueue threads in the WAITING state
(SequencedEvent) at EventQueue.getNextEvent().

I fixed the netx code (EDT violations in swing code) but the problem
is still happening randomly. This JavaWS implementation displays
several JDialogs: Splash screen + download dialogs + Security prompts.
When the application is hanging, I can not click on the Proceed/Cancel
buttons of the Security dialogs and it is blocked forever.

Are you aware about this problem ?

As I can reproduce the problem, I can provide a heap-dump if you need.

Here is a complete thread dump:

Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):

Threads class SMR info:
_java_thread_list=0x00007f94500170a0, length=44, elements={
0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800, 0x00007f94b01ba800,
0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800, 0x00007f94b01ff800,
0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800, 0x00007f94b046b000,
0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000, 0x00007f94b0aa8800,
0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000, 0x00007f9428017800,
0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000, 0x00007f942c1d0000,
0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000, 0x00007f942c192000,
0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000, 0x00007f942c1ca800,
0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000, 0x00007f942c16a000,
0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800, 0x00007f942c16f800,
0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000, 0x00007f942c1d3800
}

"main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
[0x00007f94b9bee000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <0x00000000cd9c0c78> (a net.sourceforge.jnlp.Launcher$TgThread)
    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
net.sourceforge.jnlp.Launcher$TgThread)
    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:258)
    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:208)
    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:287)
    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11/JnlpBoot.java:67)
    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:270)
    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:65)
    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11/Boot.java:210)

"Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
[0x00007f9490efc000]
   java.lang.Thread.State: RUNNABLE
    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11/Native
Method)
    at java.lang.ref.Reference.processPendingReferences(java.base at 11/Reference.java:241)
    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11/Reference.java:213)

"Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
[0x00007f9490dfb000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <0x00000000c01f16d0> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11/Finalizer.java:170)

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
[0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
[0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   No compile task

"C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
[0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   No compile task

"Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
[0x00007f94904e3000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <0x00000000c01f2140> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
    - waiting to re-lock in wait() <0x00000000c01f2140> (a
java.lang.ref.ReferenceQueue$Lock)
    at jdk.internal.ref.CleanerImpl.run(java.base at 11/CleanerImpl.java:148)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)
    at jdk.internal.misc.InnocuousThread.run(java.base at 11/InnocuousThread.java:134)

"Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
[0x00007f944ddd7000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <0x00000000c01f2898> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
    - waiting to re-lock in wait() <0x00000000c01f2898> (a
java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
   java.lang.Thread.State: RUNNABLE
    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native Method)
    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
[0x00007f944dbd5000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(java.base at 11/Native Method)
    at net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11/TracingEventQueue.java:92)

"Output controller consumer daemon" #15 daemon prio=5 os_prio=0
cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
Object.wait()  [0x00007f944d8d4000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <no object reference available>
    at net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11/OutputController.java:122)
    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
net.sourceforge.jnlp.util.logging.OutputController)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
[0x00007f944d7d3000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <no object reference available>
    at java.lang.Object.wait(java.base at 11/Object.java:328)
    at sun.awt.AWTAutoShutdown.run(java.desktop at 11/AWTAutoShutdown.java:291)
    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a java.lang.Object)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
tid=0x00007f943400e000 nid=0x15fa waiting on condition
[0x00007f944d6d2000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000c01f3870> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:566)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)

"NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
[0x00007f9420dac000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd519d48> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11/LinkedBlockingQueue.java:433)
    at net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11/SecurityDialogMessageHandler.java:93)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
[0x00007f9420865000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
[0x00007f942011e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <no object reference available>
    at java.lang.Object.wait(java.base at 11/Object.java:328)
    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
java.awt.EventQueue$1AWTInvocationLock)
    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
    at net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11/DefaultDownloadIndicator.java:146)
    at net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11/CacheUtil.java:569)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11/JNLPClassLoader.java:1498)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11/JNLPClassLoader.java:712)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:338)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:500)
    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:545)
    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11/JNLPClassLoader.java:578)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:336)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11/JNLPClassLoader.java:421)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:495)
    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:468)
    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11/Launcher.java:815)
    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11/Launcher.java:529)
    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11/Launcher.java:947)

"AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
tid=0x00007f942c075000 nid=0x1608 waiting on condition
[0x00007f940bbf7000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd9a80a8> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:620)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)

"Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
[0x00007f940bafd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:565)
    - waiting to lock <0x00000000cd9a85d8> (a
net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11/BasePainter.java:419)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
tid=0x00007f9428024000 nid=0x160a in Object.wait()
[0x00007f940b9fc000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(java.base at 11/Native Method)
    - waiting on <no object reference available>
    at java.lang.Object.wait(java.base at 11/Object.java:328)
    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
java.awt.EventQueue$1AWTInvocationLock)
    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:579)
    - locked <0x00000000cd9a85d8> (a
net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11/BasePainter.java:452)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
[0x00007f940b4e7000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
tid=0x00007f942c15b000 nid=0x1613 waiting on condition
[0x00007f940b5fa000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cf319e08> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
    at java.util.concurrent.DelayQueue.take(java.base at 11/DelayQueue.java:217)
    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
[0x00007f9407bfa000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
[0x00007f9407cfb000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
[0x00007f9407af9000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
[0x00007f94079f8000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
[0x00007f94078f7000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
[0x00007f94077f6000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
[0x00007f94074f3000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
[0x00007f94073f2000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
[0x00007f94072f1000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
[0x00007f94071f0000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
[0x00007f94070ef000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
[0x00007f9406fee000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
[0x00007f9406eed000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
[0x00007f94076f5000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
[0x00007f9406dec000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
[0x00007f94075f4000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
[0x00007f9406ceb000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
[0x00007f94069e8000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
[0x00007f9406bea000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
[0x00007f9406ae9000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
[0x00007f94061e0000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
    - parking to wait for  <0x00000000cd726dc0> (a
java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(java.base at 11/Thread.java:834)

"VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
tid=0x00007f94b019b800 nid=0x15e7 runnable

"GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
tid=0x00007f94b0040000 nid=0x15e2 runnable

"GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
tid=0x00007f9480001000 nid=0x15fb runnable

"GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
tid=0x00007f9480002800 nid=0x15fc runnable

"GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
tid=0x00007f9480004000 nid=0x15fd runnable

"G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
tid=0x00007f94b005b800 nid=0x15e3 runnable

"G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
tid=0x00007f94b005d800 nid=0x15e4 runnable

"G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
tid=0x00007f94b013a800 nid=0x15e5 runnable

"G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
tid=0x00007f9488001000 nid=0x15fe runnable

"G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
tid=0x00007f94b013c800 nid=0x15e6 runnable
"VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
tid=0x00007f94b02db000 nid=0x15f1 waiting on condition

JNI global refs: 88, weak refs: 487

Heap
 garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
0x0000000100000000)
  region size 1024K, 99 young (101376K), 5 survivors (5120K)
 Metaspace       used 32074K, capacity 32873K, committed 33280K,
reserved 1079296K
  class space    used 3388K, capacity 3743K, committed 3840K, reserved 1048576K

From daniel.fuchs at oracle.com  Tue Sep  4 13:08:04 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 4 Sep 2018 14:08:04 +0100
Subject: <AWT Dev> RFR(M) : 8210039 : move OSInfo to top level
	testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>

Hi Igor,

Nit: You could have introduced a
private static String getProperty(String name) {
      return AccessController.doP....
}
in Platform.java to avoid the long lines.

Otherwise looks good to me too!

best regards,

-- daniel

On 31/08/2018 19:42, Igor Ignatyev wrote:
> Alan, Chris,
> 
> thanks for looking at it, I went w/ the alternative suggested by Chris. that required a sprinkle of doPrivileged in the testlibrary, but now Sockets/policy.* files grant the minimal required permissions to the test code.
> the incremental webrev can found here[1], please let me know if you need the whole webrev.
> 
> [1] http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html
> 
> Thanks,
> -- Igor
> 
> 
>> On Aug 30, 2018, at 3:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>
>>>
>>> On 30 Aug 2018, at 08:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>
>>> On 28/08/2018 17:50, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>>>> 698 lines changed: 114 ins; 240 del; 344 mod
>>>> Hi all,
>>>>
>>>> could you please review this clean up of jdk testlibrary?
>>>> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
>>>>
>>>> testing: changed tests + :jdk_desktop test group
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
>>>>
>>> The updates to the Sockets policy file suggests using this jdk.test.lib.Platform/OSVersion requires permissions that the test infrastructure needs, not the test. It's not wrong but it's always a concern when tests running with a security manager are granted non-obvious permissions.
>>
>> The uses of test libraries with security manager is a little
>> cumbersome, and usually ends up with the test code being
>> granted more permissions than is necessary. I share Alan?s
>> concern.
>>
>> Another alternative, that we used in other areas, is to grant
>> the test library only minimal permissions, separate to the
>> actual test code. For example:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24 <http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24>
>>
>> -Chris.
> 


From krishna.addepalli at oracle.com  Tue Sep  4 13:59:12 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 4 Sep 2018 19:29:12 +0530
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
Message-ID: <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>

Hi Laurent,

Thanks for bringing this up. I have fixed a problem in this area JDK-8152974, which is about AWT hang when SequencedEvents arrive out of order.
However, the fix was partial, and same problem was reported in JDK8(because of webstart), after it was backported. At that point, the fix was reverted in JDK8, and since we couldn?t find a scenario in JDK11 (since webstart is deprecated). It would be helpful if you could provide smallest possible test case / sequence of steps to reproduce the problem.

Thanks,
Krishna

> On 04-Sep-2018, at 6:26 PM, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
> 
> Phil & Sergey,
> 
> I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
> times the GUI hanging with AWT-EventQueue threads in the WAITING state
> (SequencedEvent) at EventQueue.getNextEvent().
> 
> I fixed the netx code (EDT violations in swing code) but the problem
> is still happening randomly. This JavaWS implementation displays
> several JDialogs: Splash screen + download dialogs + Security prompts.
> When the application is hanging, I can not click on the Proceed/Cancel
> buttons of the Security dialogs and it is blocked forever.
> 
> Are you aware about this problem ?
> 
> As I can reproduce the problem, I can provide a heap-dump if you need.
> 
> Here is a complete thread dump:
> 
> Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
> 
> Threads class SMR info:
> _java_thread_list=0x00007f94500170a0, length=44, elements={
> 0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800, 0x00007f94b01ba800,
> 0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800, 0x00007f94b01ff800,
> 0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800, 0x00007f94b046b000,
> 0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000, 0x00007f94b0aa8800,
> 0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000, 0x00007f9428017800,
> 0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000, 0x00007f942c1d0000,
> 0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000, 0x00007f942c192000,
> 0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000, 0x00007f942c1ca800,
> 0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000, 0x00007f942c16a000,
> 0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800, 0x00007f942c16f800,
> 0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000, 0x00007f942c1d3800
> }
> 
> "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
> tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
> [0x00007f94b9bee000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <0x00000000cd9c0c78> (a net.sourceforge.jnlp.Launcher$TgThread)
>    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
>    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
> net.sourceforge.jnlp.Launcher$TgThread)
>    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
>    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:258)
>    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:208)
>    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:287)
>    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11/JnlpBoot.java:67)
>    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:270)
>    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:65)
>    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
>    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11/Boot.java:210)
> 
> "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
> elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
> [0x00007f9490efc000]
>   java.lang.Thread.State: RUNNABLE
>    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11/Native
> Method)
>    at java.lang.ref.Reference.processPendingReferences(java.base at 11/Reference.java:241)
>    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11/Reference.java:213)
> 
> "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
> tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
> [0x00007f9490dfb000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <0x00000000c01f16d0> (a java.lang.ref.ReferenceQueue$Lock)
>    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
>    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
> java.lang.ref.ReferenceQueue$Lock)
>    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
>    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11/Finalizer.java:170)
> 
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
> elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
> [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
> 
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
> elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
> [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
>   No compile task
> 
> "C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
> elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
> [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
>   No compile task
> 
> "Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
> tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
> 
> "Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
> tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
> [0x00007f94904e3000]
>   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <0x00000000c01f2140> (a java.lang.ref.ReferenceQueue$Lock)
>    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
>    - waiting to re-lock in wait() <0x00000000c01f2140> (a
> java.lang.ref.ReferenceQueue$Lock)
>    at jdk.internal.ref.CleanerImpl.run(java.base at 11/CleanerImpl.java:148)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>    at jdk.internal.misc.InnocuousThread.run(java.base at 11/InnocuousThread.java:134)
> 
> "Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
> tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
>   java.lang.Thread.State: RUNNABLE
> 
> "Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
> elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
> [0x00007f944ddd7000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <0x00000000c01f2898> (a java.lang.ref.ReferenceQueue$Lock)
>    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
>    - waiting to re-lock in wait() <0x00000000c01f2898> (a
> java.lang.ref.ReferenceQueue$Lock)
>    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
>    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
> tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
>   java.lang.Thread.State: RUNNABLE
>    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native Method)
>    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
>    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
> tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
> [0x00007f944dbd5000]
>   java.lang.Thread.State: TIMED_WAITING (sleeping)
>    at java.lang.Thread.sleep(java.base at 11/Native Method)
>    at net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11/TracingEventQueue.java:92)
> 
> "Output controller consumer daemon" #15 daemon prio=5 os_prio=0
> cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
> Object.wait()  [0x00007f944d8d4000]
>   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <no object reference available>
>    at net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11/OutputController.java:122)
>    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
> net.sourceforge.jnlp.util.logging.OutputController)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
> tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
> [0x00007f944d7d3000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <no object reference available>
>    at java.lang.Object.wait(java.base at 11/Object.java:328)
>    at sun.awt.AWTAutoShutdown.run(java.desktop at 11/AWTAutoShutdown.java:291)
>    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a java.lang.Object)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
> tid=0x00007f943400e000 nid=0x15fa waiting on condition
> [0x00007f944d6d2000]
>   java.lang.Thread.State: WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000c01f3870> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
>    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
>    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:566)
>    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
>    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
>    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
>    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)
> 
> "NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
> elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
> [0x00007f9420dac000]
>   java.lang.Thread.State: WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd519d48> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
>    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
>    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11/LinkedBlockingQueue.java:433)
>    at net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11/SecurityDialogMessageHandler.java:93)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
> elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
> [0x00007f9420865000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
> tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
> [0x00007f942011e000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <no object reference available>
>    at java.lang.Object.wait(java.base at 11/Object.java:328)
>    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
>    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
> java.awt.EventQueue$1AWTInvocationLock)
>    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
>    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
>    at net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11/DefaultDownloadIndicator.java:146)
>    at net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11/CacheUtil.java:569)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11/JNLPClassLoader.java:1498)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11/JNLPClassLoader.java:712)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:338)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:500)
>    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:545)
>    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11/JNLPClassLoader.java:578)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:336)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11/JNLPClassLoader.java:421)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:495)
>    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
>    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:468)
>    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11/Launcher.java:815)
>    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11/Launcher.java:529)
>    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11/Launcher.java:947)
> 
> "AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
> tid=0x00007f942c075000 nid=0x1608 waiting on condition
> [0x00007f940bbf7000]
>   java.lang.Thread.State: WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd9a80a8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
>    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
>    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:620)
>    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
>    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
>    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
>    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
>    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
>    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
>    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
>    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
>    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
>    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
>    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
>    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
>    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
>    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
>    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
>    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
>    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
>    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
>    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
>    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
>    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
>    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)
> 
> "Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
> tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
> [0x00007f940bafd000]
>   java.lang.Thread.State: BLOCKED (on object monitor)
>    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:565)
>    - waiting to lock <0x00000000cd9a85d8> (a
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
>    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
>    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11/BasePainter.java:419)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
> tid=0x00007f9428024000 nid=0x160a in Object.wait()
> [0x00007f940b9fc000]
>   java.lang.Thread.State: WAITING (on object monitor)
>    at java.lang.Object.wait(java.base at 11/Native Method)
>    - waiting on <no object reference available>
>    at java.lang.Object.wait(java.base at 11/Object.java:328)
>    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
>    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
> java.awt.EventQueue$1AWTInvocationLock)
>    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
>    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
>    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:579)
>    - locked <0x00000000cd9a85d8> (a
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
>    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
>    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11/BasePainter.java:452)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
> elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
> [0x00007f940b4e7000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
> tid=0x00007f942c15b000 nid=0x1613 waiting on condition
> [0x00007f940b5fa000]
>   java.lang.Thread.State: WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cf319e08> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
>    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
>    at java.util.concurrent.DelayQueue.take(java.base at 11/DelayQueue.java:217)
>    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
> elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
> [0x00007f9407bfa000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
> elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
> [0x00007f9407cfb000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
> elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
> [0x00007f9407af9000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
> elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
> [0x00007f94079f8000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
> elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
> [0x00007f94078f7000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
> elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
> [0x00007f94077f6000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
> elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
> [0x00007f94074f3000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
> elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
> [0x00007f94073f2000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
> elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
> [0x00007f94072f1000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
> elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
> [0x00007f94071f0000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
> elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
> [0x00007f94070ef000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
> elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
> [0x00007f9406fee000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
> elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
> [0x00007f9406eed000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
> elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
> [0x00007f94076f5000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
> elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
> [0x00007f9406dec000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
> elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
> [0x00007f94075f4000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
> elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
> [0x00007f9406ceb000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
> elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
> [0x00007f94069e8000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
> elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
> [0x00007f9406bea000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
> elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
> [0x00007f9406ae9000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
> elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
> [0x00007f94061e0000]
>   java.lang.Thread.State: TIMED_WAITING (parking)
>    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>    - parking to wait for  <0x00000000cd726dc0> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
>    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
>    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
>    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
>    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
>    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
>    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
>    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
>    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> 
> "VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
> tid=0x00007f94b019b800 nid=0x15e7 runnable
> 
> "GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
> tid=0x00007f94b0040000 nid=0x15e2 runnable
> 
> "GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
> tid=0x00007f9480001000 nid=0x15fb runnable
> 
> "GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
> tid=0x00007f9480002800 nid=0x15fc runnable
> 
> "GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
> tid=0x00007f9480004000 nid=0x15fd runnable
> 
> "G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
> tid=0x00007f94b005b800 nid=0x15e3 runnable
> 
> "G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
> tid=0x00007f94b005d800 nid=0x15e4 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
> tid=0x00007f94b013a800 nid=0x15e5 runnable
> 
> "G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
> tid=0x00007f9488001000 nid=0x15fe runnable
> 
> "G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
> tid=0x00007f94b013c800 nid=0x15e6 runnable
> "VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
> tid=0x00007f94b02db000 nid=0x15f1 waiting on condition
> 
> JNI global refs: 88, weak refs: 487
> 
> Heap
> garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
> 0x0000000100000000)
>  region size 1024K, 99 young (101376K), 5 survivors (5120K)
> Metaspace       used 32074K, capacity 32873K, committed 33280K,
> reserved 1079296K
>  class space    used 3388K, capacity 3743K, committed 3840K, reserved 1048576K


From krishna.addepalli at oracle.com  Tue Sep  4 15:20:28 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 4 Sep 2018 08:20:28 -0700 (PDT)
Subject: <AWT Dev> StackOverflowError happened by TextField.setFont(...)
In-Reply-To: <b67141f59aac0fc92c5ef0cf2d2eb497@linux.vnet.ibm.com>
References: <246641344f11cd8c8beea5bbee12b898@linux.vnet.ibm.com>
 <1c835ef6-d8f6-440c-bbbb-717765697d4d@default>
 <c5067ac4c31c9da5d24e8ed1c04a50e7@linux.vnet.ibm.com>
 <b67141f59aac0fc92c5ef0cf2d2eb497@linux.vnet.ibm.com>
Message-ID: <8d293bb4-53d1-458d-84aa-14da927e5fb6@default>

Hi Ichiroh,

Yes I'm able to see this issue in jdk12 repo on Ubuntu. But this issue is not reproducible on Windows. 
So, I guess the fix has to be specific to Linux.

Thanks,
Krishna

-----Original Message-----
From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com> 
Sent: Monday, September 3, 2018 4:26 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Subject: Re: <AWT Dev> StackOverflowError happened by TextField.setFont(...)

Hello Krishna.

Sorry for bothering you.
I'd like to know you could recreate this issue or not.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-08-27 15:14, Ichiroh Takiguchi wrote:
> Hello Krishna.
> 
> Thank you for your testing.
> 
> I'm sorry, I could not put information about tested platform.
> I just tested this issue with jdk-12+8 on RHEL6/7 x86_64 and Ubuntu
> 14.04.5 x86_64.
> Still I could recreate this issue.
> 
> Test instruction is as follows:
> 1. Compile and run FontChangeTest
> 2. Press "Shuffle" button to top
> 3. Change Font size (TextField) "12" to "24" on right-buttom, then 
> press Enter/Return key
>    Then above exception will be happened
> 
> Thanks,
> 
> On 2018-08-27 12:55, Krishna Addepalli wrote:
>> Hi Ichiroh,
>> 
>> I have tried the steps you outlined, but I'm not able to reproduce 
>> the issue you are seeing. Could you try with the latest jdk12 repo?
>> 
>> Thanks,
>> Krishna
>> 
>> -----Original Message-----
>> From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
>> Sent: Friday, August 24, 2018 1:42 PM
>> To: awt-dev at openjdk.java.net
>> Subject: <AWT Dev> StackOverflowError happened by
>> TextField.setFont(...)
>> 
>> Hello.
>> 
>> I could see following exception by TextField.setFont(...) by jdk-12+6
>> 
>> =====================
>> Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
>>          at
>> java.desktop/javax.swing.plaf.basic.BasicTextUI$UpdateHandler.layoutContainer(BasicTextUI.java:2061)
>>          at
>> java.desktop/java.awt.Container.layout(Container.java:1537)
>>          at
>> java.desktop/java.awt.Container.doLayout(Container.java:1526)
>>          at
>> java.desktop/java.awt.Container.validateTree(Container.java:1722)
>>          at
>> java.desktop/java.awt.Container.validate(Container.java:1657)
>>          at
>> java.desktop/sun.awt.X11.XTextFieldPeer.setFont(XTextFieldPeer.java:290)
>>          at
>> java.desktop/java.awt.Component.validate(Component.java:2976)
>>          at
>> java.desktop/java.awt.Container.validateTree(Container.java:1740)
>>          at
>> java.desktop/java.awt.Container.validate(Container.java:1657)
>>          at
>> java.desktop/sun.awt.X11.XTextFieldPeer.setFont(XTextFieldPeer.java:290)
>>          at
>> java.desktop/java.awt.Component.validate(Component.java:2976)
>>          at
>> java.desktop/java.awt.Container.validateTree(Container.java:1740)
>> ...
>> =====================
>> 
>> It seemed that sun.awt.X11.XTextFieldPeer.setFont(...) was called 
>> recursively.
>> 
>> I used following test program to recreate this issue.
>> =====================
>> import java.awt.*;
>> import java.awt.event.*;
>> import java.awt.font.*;
>> import java.util.*;
>> 
>> public class FontChangeTest extends Frame
>>    implements ActionListener, ItemListener {
>>    Panel p;
>>    java.util.List list = Arrays.asList(
>>      "1","2","3","4","5","6","7","8","9");
>>    TextField[] textfs = new TextField[list.size()];;
>>    Choice fontName, fontStyle;
>>    TextField fontSize;
>>    final static String[] fontStyles = new String[]{
>>      "Plain","Bold","Italic","ItalicBold"};
>>    final static int[] fontStylesId = new int[]{
>>      Font.PLAIN,Font.BOLD,Font.ITALIC,Font.BOLD+Font.ITALIC};
>>    Button btn;
>>    final int fSize = 12;
>>    void shuffle() {
>>      Collections.shuffle(list);
>>      for(int i=0; i<list.size(); i++) {
>>        textfs[i].setText(list.get(i).toString());
>>      }
>>    }
>>    void init() {
>>      setLayout(new BorderLayout());
>>      Panel p0 = new Panel();
>>      p0.setLayout(new FlowLayout());
>>      add(p0, BorderLayout.NORTH);
>>      btn = new Button("Shuffle");
>>      btn.addActionListener(this);
>>      p0.add(btn);
>>      Panel p1 = new Panel();
>>      p1.setLayout(new FlowLayout());
>>      add(p1, BorderLayout.SOUTH);
>>      fontName = new Choice();
>>      fontName.addItemListener(this);
>>      for(String s : Toolkit.getDefaultToolkit().getFontList()) {
>>        fontName.add(s);
>>      }
>>      p1.add(fontName);
>>      fontStyle = new Choice();
>>      fontStyle.addItemListener(this);
>>      for(String s : fontStyles) {
>>        fontStyle.add(s);
>>      }
>>      p1.add(fontStyle);
>>      fontSize = new TextField(String.valueOf(fSize),2);
>>      fontSize.addActionListener(this);
>>      p1.add(fontSize);
>>      p = new Panel();
>>      add(p, BorderLayout.CENTER);
>>      p.setLayout(new GridLayout(0,3,3,3));
>>      for(int i=0; i<list.size(); i++) {
>>        textfs[i] = new TextField(1);
>>        textfs[i].setFont(new Font(fontName.getSelectedItem(),
>>                          fontStylesId[fontStyle.getSelectedIndex()],
>>                          fSize));
>>        p.add(textfs[i]);
>>      }
>>      shuffle();
>>    }
>>    public void changeFont() {
>>      int size;
>>      try {
>>        size = Integer.parseInt(fontSize.getText());
>>        for(int i=0; i<textfs.length; i++) {
>>          textfs[i].setFont(new Font(fontName.getSelectedItem(),
>>                            fontStylesId[fontStyle.getSelectedIndex()],
>>                            size));
>>        }
>>      } catch (java.lang.NumberFormatException nfe) {
>>      }
>>    }
>>    FontChangeTest() {
>>      super("FontChangeTest");
>>      init();
>>      addWindowListener(new WindowAdapter() {
>>        public void windowClosing(WindowEvent we) { System.exit(0); }
>>      });
>>      pack();
>>      setVisible(true);
>>    }
>>    public void actionPerformed(ActionEvent ae) {
>>      if (ae.getSource().equals(btn)) {
>>        p.setVisible(false);
>>        shuffle();
>>        p.setVisible(true);
>>      } else if (ae.getSource().equals(fontSize)) {
>>        changeFont();
>>        pack();
>>      }
>>    }
>>    public void itemStateChanged(ItemEvent ie) {
>>      changeFont();
>>      pack();
>>    }
>>    public static void main(String[] args) {
>>      new FontChangeTest();
>>    }
>> }
>> =====================
>> 
>> Test instruction is as follows:
>> 1. Compile and run FontChangeTest
>> 2. Press "Shuffle" button to top
>> 3. Click left buttom's Choice button, then change "Dialog" to 
>> "SansSerif"
>>     Then above exception will be happened
>> 
>> It worked fine with JDK8
>> java version "1.8.0_181"
>> Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java 
>> HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>> 
>> Failed by
>> openjdk version "12-ea" 2019-03-19
>> OpenJDK Runtime Environment 19.3 (build 12-ea+6) OpenJDK 64-Bit 
>> Server VM 19.3 (build 12-ea+6, mixed mode)
>> 
>> One of fix candidate is:
>> =====================
>> diff -r 945ba9278a27
>> src/java.desktop/share/classes/java/awt/Component.java
>> --- a/src/java.desktop/share/classes/java/awt/Component.java    Tue 
>> Aug
>> 07 00:06:52 2018 -0700
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java    Fri 
>> Aug
>> 24 16:59:19 2018 +0900
>> @@ -1936,8 +1936,8 @@
>>               if (peer != null) {
>>                   f = getFont();
>>                   if (f != null) {
>> +                    peerFont = f;
>>                       peer.setFont(f);
>> -                    peerFont = f;
>>                   }
>>               }
>>           }
>> =====================
>> 
>> I'm not sure, it's good or not...
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.


From manajit.halder at oracle.com  Tue Sep  4 17:54:14 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 4 Sep 2018 23:24:14 +0530
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
Message-ID: <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>

Hi Dmitry,

Thanks for your reply. Please see my reply inline.

Thanks,
Manajit


On 01/09/18 12:02 AM, Dmitry Markov wrote:
> Hi Manajit,
>
> The current implementation assumes that orderAboveSiblings() places 
> the window in front of other windows located at the same level. The 
> proposed fix introduces new behaviour: if the window does not have an 
> owner and child windows it won?t be ordered, (i.e. in certain 
> conditions the window may be obscured by other windows even after 
> orderAboveSibling() execution). Most likely such approach will break 
> existed functionality - some windows will be incorrectly placed behind 
> other windows.
 ??? If I am not wrong windows (other than Window.Type.POPUP) are 
already ordered in setVisible method at line no 632 while creation. 
While debugging I observed that orderFront is called twice when the 
window is displayed for the first time (in method setVisible and in 
method orderAboveSiblings). Now when Key press COMMAND + ` is pressed 
the current window receives windowDidBecomeMain notification and which 
calls orderFront and also COMMAND + ` tries to order the window above. 
Two time ordering the window when COMMAND + ` is pressed is causing 
problem in case of multiple windows.
>
> I am sorry, but the relationship between the original problem 
> described in the bug, (i.e. cycling through windows issue) and 
> implementation of orderAboveSiblings() is NOT clear. Can you explain this?
 ??? This issue is a regression of JDK-8169589 introduced in JDK release 
8u131. 8169589 introduced new window ordering model and which has 
introduced the cycling through window issue.
>
> Thanks,
> Dmitry
>
>> On 31 Aug 2018, at 07:55, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Please review the fix for JDK12.
>>
>> 

Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8206392
>>
>> <https://bugs.openjdk.java.net/browse/JDK-8206392>
Webrev: 

>> http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>
>> Fix: 

>> ??? Window ordering is not required if the window doesn't own any 
>> other windows.
>>
>> Regards,
>> Manajit
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180904/b21a87c7/attachment.html>

From bourges.laurent at gmail.com  Tue Sep  4 20:11:55 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 4 Sep 2018 22:11:55 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
 <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
Message-ID: <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>

Hi Krishna,

Thanks for your answers, I managed writing a simple reproducer, see below.
I inspected heap dumps on jvisualvm but it looks like the First
SequencedEvent is not consumed and is blocking the queue for ever.

On JDK8 or JDK10: it works (windows are animated and not hanging).
On JDK11: it starts but is immediately frozen !

Could you have a look ?

----
import java.awt.AWTEvent;
import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.Toolkit;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowEvent;
import java.lang.reflect.Constructor;
import javax.swing.JButton;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import javax.swing.Timer;
import sun.awt.AppContext;
import sun.awt.SunToolkit;

/*
 * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
 * @author Laurent Bourges
 */
public class TestWinEvent extends JFrame implements ActionListener {

    private static final long serialVersionUID = 1L;

    private int counter = 0;
    private JButton btn;

    public static void main(String[] args) {
        createWin(1);
        createWin(2);
    }

    private static void createWin(int tgNum) {
        ThreadGroup tg = new ThreadGroup("TG " + tgNum);

        Thread t = new Thread(tg, new Runnable() {
            public void run() {
                AppContext context = SunToolkit.createNewAppContext();

                SwingUtilities.invokeLater(new Runnable() {
                    public void run() {
                        final TestWinEvent window = new TestWinEvent(tgNum);
                        window.setVisible(true);

                        new Timer(10, window).start();
                    }
                });
            }
        });
        t.start();
    }

    public TestWinEvent(final int num) {
        super("Test Window + " + num);
        setMinimumSize(new Dimension(300, 200));
        setLocation(100 + 400 * (num - 1), 100);

        setLayout(new BorderLayout());
        JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
        add(textBlock);

        btn = new JButton("TEST");
        btn.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                System.out.println("Button#" + num + " clicked: " +
counter);
            }

        });
        add(btn, BorderLayout.SOUTH);

        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        pack();
    }

    @Override
    public void actionPerformed(ActionEvent e) {
        AWTEvent eventOne =
getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
        AWTEvent eventTwo =
getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);

        btn.setText("TEST " + (counter++));


Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);

Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
    }

    private AWTEvent getSequencedEvent(int id) {
        AWTEvent wrapMe = new WindowEvent(this, id);
        try {
            @SuppressWarnings("unchecked")
            Class<? extends AWTEvent> seqClass = (Class<? extends
AWTEvent>) Class.forName("java.awt.SequencedEvent");
            Constructor<? extends AWTEvent> seqConst =
seqClass.getConstructor(AWTEvent.class);
            seqConst.setAccessible(true);
            AWTEvent instance = seqConst.newInstance(wrapMe);
            return instance;
        } catch (Throwable err) {
            throw new Error("Unable to instantiate SequencedEvent", err);
        }
    }
}
------

Regards,
Laurent

Le mar. 4 sept. 2018 ? 15:59, Krishna Addepalli <
krishna.addepalli at oracle.com> a ?crit :

> Hi Laurent,
>
> Thanks for bringing this up. I have fixed a problem in this area
> JDK-8152974, which is about AWT hang when SequencedEvents arrive out of
> order.
> However, the fix was partial, and same problem was reported in
> JDK8(because of webstart), after it was backported. At that point, the fix
> was reverted in JDK8, and since we couldn?t find a scenario in JDK11 (since
> webstart is deprecated). It would be helpful if you could provide smallest
> possible test case / sequence of steps to reproduce the problem.
>
> Thanks,
> Krishna
>
> > On 04-Sep-2018, at 6:26 PM, Laurent Bourg?s <bourges.laurent at gmail.com>
> wrote:
> >
> > Phil & Sergey,
> >
> > I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
> > times the GUI hanging with AWT-EventQueue threads in the WAITING state
> > (SequencedEvent) at EventQueue.getNextEvent().
> >
> > I fixed the netx code (EDT violations in swing code) but the problem
> > is still happening randomly. This JavaWS implementation displays
> > several JDialogs: Splash screen + download dialogs + Security prompts.
> > When the application is hanging, I can not click on the Proceed/Cancel
> > buttons of the Security dialogs and it is blocked forever.
> >
> > Are you aware about this problem ?
> >
> > As I can reproduce the problem, I can provide a heap-dump if you need.
> >
> > Here is a complete thread dump:
> >
> > Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
> >
> > Threads class SMR info:
> > _java_thread_list=0x00007f94500170a0, length=44, elements={
> > 0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800,
> 0x00007f94b01ba800,
> > 0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800,
> 0x00007f94b01ff800,
> > 0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800,
> 0x00007f94b046b000,
> > 0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000,
> 0x00007f94b0aa8800,
> > 0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000,
> 0x00007f9428017800,
> > 0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000,
> 0x00007f942c1d0000,
> > 0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000,
> 0x00007f942c192000,
> > 0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000,
> 0x00007f942c1ca800,
> > 0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000,
> 0x00007f942c16a000,
> > 0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800,
> 0x00007f942c16f800,
> > 0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000,
> 0x00007f942c1d3800
> > }
> >
> > "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
> > tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
> > [0x00007f94b9bee000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000cd9c0c78> (a
> net.sourceforge.jnlp.Launcher$TgThread)
> >    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
> >    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
> > net.sourceforge.jnlp.Launcher$TgThread)
> >    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
> /Launcher.java:258)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
> /Launcher.java:208)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
> /Launcher.java:287)
> >    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11
> /JnlpBoot.java:67)
> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
> /Boot.java:270)
> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
> /Boot.java:65)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
> Method)
> >    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11
> /Boot.java:210)
> >
> > "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
> > elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
> > [0x00007f9490efc000]
> >   java.lang.Thread.State: RUNNABLE
> >    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11
> /Native
> > Method)
> >    at java.lang.ref.Reference.processPendingReferences(java.base at 11
> /Reference.java:241)
> >    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11
> /Reference.java:213)
> >
> > "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
> > tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
> > [0x00007f9490dfb000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f16d0> (a
> java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
> /ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
> /ReferenceQueue.java:176)
> >    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11
> /Finalizer.java:170)
> >
> > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
> > elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >
> > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
> > elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >   No compile task
> >
> > "C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
> > elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >   No compile task
> >
> > "Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
> > tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >
> > "Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
> > tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
> > [0x00007f94904e3000]
> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f2140> (a
> java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
> /ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f2140> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at jdk.internal.ref.CleanerImpl.run(java.base at 11
> /CleanerImpl.java:148)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >    at jdk.internal.misc.InnocuousThread.run(java.base at 11
> /InnocuousThread.java:134)
> >
> > "Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
> > tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >
> > "Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
> > elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
> > [0x00007f944ddd7000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f2898> (a
> java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
> /ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f2898> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
> /ReferenceQueue.java:176)
> >    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
> > tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
> >   java.lang.Thread.State: RUNNABLE
> >    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native Method)
> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
> > tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
> > [0x00007f944dbd5000]
> >   java.lang.Thread.State: TIMED_WAITING (sleeping)
> >    at java.lang.Thread.sleep(java.base at 11/Native Method)
> >    at
> net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11
> /TracingEventQueue.java:92)
> >
> > "Output controller consumer daemon" #15 daemon prio=5 os_prio=0
> > cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
> > Object.wait()  [0x00007f944d8d4000]
> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at
> net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11
> /OutputController.java:122)
> >    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
> > net.sourceforge.jnlp.util.logging.OutputController)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
> > tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
> > [0x00007f944d7d3000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at sun.awt.AWTAutoShutdown.run(java.desktop at 11
> /AWTAutoShutdown.java:291)
> >    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a
> java.lang.Object)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
> > tid=0x00007f943400e000 nid=0x15fa waiting on condition
> > [0x00007f944d6d2000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000c01f3870> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
> /LockSupport.java:194)
> >    at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
> /AbstractQueuedSynchronizer.java:2081)
> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
> /EventQueue.java:566)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
> /EventDispatchThread.java:190)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
> /EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
> /EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:109)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:101)
> >    at java.awt.EventDispatchThread.run(java.desktop at 11
> /EventDispatchThread.java:90)
> >
> > "NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
> > elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
> > [0x00007f9420dac000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd519d48> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
> /LockSupport.java:194)
> >    at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
> /AbstractQueuedSynchronizer.java:2081)
> >    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11
> /LinkedBlockingQueue.java:433)
> >    at
> net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11
> /SecurityDialogMessageHandler.java:93)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
> > elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
> > [0x00007f9420865000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
> > tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
> > [0x00007f942011e000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
> /EventQueue.java:1361)
> >    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
> > java.awt.EventQueue$1AWTInvocationLock)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
> /EventQueue.java:1342)
> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
> /SwingUtilities.java:1480)
> >    at
> net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11
> /DefaultDownloadIndicator.java:146)
> >    at
> net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11
> /CacheUtil.java:569)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11
> /JNLPClassLoader.java:1498)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11
> /JNLPClassLoader.java:712)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
> /JNLPClassLoader.java:338)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
> /JNLPClassLoader.java:500)
> >    - locked <0x00000000cd98b9d8> (a
> java.util.concurrent.locks.ReentrantLock)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
> /JNLPClassLoader.java:545)
> >    - locked <0x00000000cd98b9d8> (a
> java.util.concurrent.locks.ReentrantLock)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11
> /JNLPClassLoader.java:578)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
> /JNLPClassLoader.java:336)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11
> /JNLPClassLoader.java:421)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
> /JNLPClassLoader.java:495)
> >    - locked <0x00000000cd98b9d8> (a
> java.util.concurrent.locks.ReentrantLock)
> >    at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
> /JNLPClassLoader.java:468)
> >    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11
> /Launcher.java:815)
> >    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11
> /Launcher.java:529)
> >    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11
> /Launcher.java:947)
> >
> > "AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
> > tid=0x00007f942c075000 nid=0x1608 waiting on condition
> > [0x00007f940bbf7000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd9a80a8> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
> /LockSupport.java:194)
> >    at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
> /AbstractQueuedSynchronizer.java:2081)
> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
> /EventQueue.java:620)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
> /EventDispatchThread.java:190)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
> /EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
> /EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:109)
> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
> /SequencedEvent.java:138)
> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
> /EventQueue.java:770)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
> Method)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:85)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:95)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
> Method)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:85)
> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
> /EventQueue.java:742)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
> /EventDispatchThread.java:203)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
> /EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
> /EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:109)
> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
> /SequencedEvent.java:138)
> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
> /EventQueue.java:770)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
> Method)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:85)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:95)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
> Method)
> >    at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
> /ProtectionDomain.java:85)
> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
> /EventQueue.java:742)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
> /EventDispatchThread.java:203)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
> /EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
> /EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:109)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
> /EventDispatchThread.java:101)
> >    at java.awt.EventDispatchThread.run(java.desktop at 11
> /EventDispatchThread.java:90)
> >
> > "Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
> > tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
> > [0x00007f940bafd000]
> >   java.lang.Thread.State: BLOCKED (on object monitor)
> >    at
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
> /BasePainter.java:565)
> >    - waiting to lock <0x00000000cd9a85d8> (a
> >
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
> >    at java.util.Observable.notifyObservers(java.base at 11
> /Observable.java:173)
> >    at java.util.Observable.notifyObservers(java.base at 11
> /Observable.java:129)
> >    at
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11
> /BasePainter.java:419)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
> > tid=0x00007f9428024000 nid=0x160a in Object.wait()
> > [0x00007f940b9fc000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
> /EventQueue.java:1361)
> >    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
> > java.awt.EventQueue$1AWTInvocationLock)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
> /EventQueue.java:1342)
> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
> /SwingUtilities.java:1480)
> >    at
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
> /BasePainter.java:579)
> >    - locked <0x00000000cd9a85d8> (a
> >
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
> >    at java.util.Observable.notifyObservers(java.base at 11
> /Observable.java:173)
> >    at java.util.Observable.notifyObservers(java.base at 11
> /Observable.java:129)
> >    at
> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11
> /BasePainter.java:452)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
> > elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
> > [0x00007f940b4e7000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
> > tid=0x00007f942c15b000 nid=0x1613 waiting on condition
> > [0x00007f940b5fa000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cf319e08> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
> /LockSupport.java:194)
> >    at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
> /AbstractQueuedSynchronizer.java:2081)
> >    at java.util.concurrent.DelayQueue.take(java.base at 11
> /DelayQueue.java:217)
> >    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
> > elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
> > [0x00007f9407bfa000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
> > elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
> > [0x00007f9407cfb000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
> > elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
> > [0x00007f9407af9000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
> > elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
> > [0x00007f94079f8000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
> > elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
> > [0x00007f94078f7000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
> > elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
> > [0x00007f94077f6000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
> > elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
> > [0x00007f94074f3000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
> > elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
> > [0x00007f94073f2000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
> > elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
> > [0x00007f94072f1000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
> > elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
> > [0x00007f94071f0000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
> > elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
> > [0x00007f94070ef000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
> > elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
> > [0x00007f9406fee000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
> > elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
> > [0x00007f9406eed000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
> > elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
> > [0x00007f94076f5000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
> > elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
> > [0x00007f9406dec000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
> > elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
> > [0x00007f94075f4000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
> > elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
> > [0x00007f9406ceb000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
> > elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
> > [0x00007f94069e8000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
> > elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
> > [0x00007f9406bea000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
> > elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
> > [0x00007f9406ae9000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
> > elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
> > [0x00007f94061e0000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
> /LockSupport.java:234)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
> /SynchronousQueue.java:462)
> >    at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
> /SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
> /SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
> /ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
> /ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
> /ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >
> > "VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
> > tid=0x00007f94b019b800 nid=0x15e7 runnable
> >
> > "GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
> > tid=0x00007f94b0040000 nid=0x15e2 runnable
> >
> > "GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
> > tid=0x00007f9480001000 nid=0x15fb runnable
> >
> > "GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
> > tid=0x00007f9480002800 nid=0x15fc runnable
> >
> > "GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
> > tid=0x00007f9480004000 nid=0x15fd runnable
> >
> > "G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
> > tid=0x00007f94b005b800 nid=0x15e3 runnable
> >
> > "G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
> > tid=0x00007f94b005d800 nid=0x15e4 runnable
> >
> > "G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
> > tid=0x00007f94b013a800 nid=0x15e5 runnable
> >
> > "G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
> > tid=0x00007f9488001000 nid=0x15fe runnable
> >
> > "G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
> > tid=0x00007f94b013c800 nid=0x15e6 runnable
> > "VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
> > tid=0x00007f94b02db000 nid=0x15f1 waiting on condition
> >
> > JNI global refs: 88, weak refs: 487
> >
> > Heap
> > garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
> > 0x0000000100000000)
> >  region size 1024K, 99 young (101376K), 5 survivors (5120K)
> > Metaspace       used 32074K, capacity 32873K, committed 33280K,
> > reserved 1079296K
> >  class space    used 3388K, capacity 3743K, committed 3840K, reserved
> 1048576K
>
>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180904/e07289ae/attachment-0001.html>

From igor.ignatyev at oracle.com  Tue Sep  4 22:02:17 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 4 Sep 2018 15:02:17 -0700
Subject: <AWT Dev> RFR(M) : 8210039 : move OSInfo to top level
	testlibrary
In-Reply-To: <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
 <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>
Message-ID: <9F6E234B-23EE-4E6C-9144-EEBCBA7F6CFB@oracle.com>

Daniel, Chris, Alan,

thank you for your review.

I've pushed it w/ Platfform::privilegedGetProperty method added to shorten lines in Platform.java

Cheers,
-- Igor


> On Sep 4, 2018, at 6:08 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Igor,
> 
> Nit: You could have introduced a
> private static String getProperty(String name) {
>     return AccessController.doP....
> }
> in Platform.java to avoid the long lines.
> 
> Otherwise looks good to me too!
> 
> best regards,
> 
> -- daniel
> 
> On 31/08/2018 19:42, Igor Ignatyev wrote:
>> Alan, Chris,
>> thanks for looking at it, I went w/ the alternative suggested by Chris. that required a sprinkle of doPrivileged in the testlibrary, but now Sockets/policy.* files grant the minimal required permissions to the test code.
>> the incremental webrev can found here[1], please let me know if you need the whole webrev.
>> [1] http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html
>> Thanks,
>> -- Igor
>>> On Aug 30, 2018, at 3:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>> 
>>>> 
>>>> On 30 Aug 2018, at 08:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> 
>>>> On 28/08/2018 17:50, Igor Ignatyev wrote:
>>>>> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>>>>> 698 lines changed: 114 ins; 240 del; 344 mod
>>>>> Hi all,
>>>>> 
>>>>> could you please review this clean up of jdk testlibrary?
>>>>> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
>>>>> 
>>>>> testing: changed tests + :jdk_desktop test group
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
>>>>> 
>>>> The updates to the Sockets policy file suggests using this jdk.test.lib.Platform/OSVersion requires permissions that the test infrastructure needs, not the test. It's not wrong but it's always a concern when tests running with a security manager are granted non-obvious permissions.
>>> 
>>> The uses of test libraries with security manager is a little
>>> cumbersome, and usually ends up with the test code being
>>> granted more permissions than is necessary. I share Alan?s
>>> concern.
>>> 
>>> Another alternative, that we used in other areas, is to grant
>>> the test library only minimal permissions, separate to the
>>> actual test code. For example:
>>> 
>>> http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24 <http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24>
>>> 
>>> -Chris.
> 


From bourges.laurent at gmail.com  Wed Sep  5 06:45:46 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 5 Sep 2018 08:45:46 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
 <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
 <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>
Message-ID: <CAKjRUT7t7D2txuDC6Lh9G5YXqKp=-ufZ4RP4AE9YduaPNRtPZw@mail.gmail.com>

Hi,
Should we submit a new bug or complete the opened bug with this reproducer ?

It is quite critical for OpenJDK 11 adoption as I expect linux
distributions at least will provide icedtea-web for javaws support, even
for 11+.

I will try implementing a workaround redirecting EDT using a single
AppContext... to reduce the opportunity to have deadlock = only 1 EDT used
at the same time.

Regards,
Laurent

Le mar. 4 sept. 2018 ? 22:11, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi Krishna,
>
> Thanks for your answers, I managed writing a simple reproducer, see below.
> I inspected heap dumps on jvisualvm but it looks like the First
> SequencedEvent is not consumed and is blocking the queue for ever.
>
> On JDK8 or JDK10: it works (windows are animated and not hanging).
> On JDK11: it starts but is immediately frozen !
>
> Could you have a look ?
>
> ----
> import java.awt.AWTEvent;
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import java.awt.Toolkit;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.awt.event.WindowEvent;
> import java.lang.reflect.Constructor;
> import javax.swing.JButton;
>
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.SwingUtilities;
> import javax.swing.Timer;
> import sun.awt.AppContext;
> import sun.awt.SunToolkit;
>
> /*
>  * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
>  * @author Laurent Bourges
>  */
> public class TestWinEvent extends JFrame implements ActionListener {
>
>     private static final long serialVersionUID = 1L;
>
>     private int counter = 0;
>     private JButton btn;
>
>     public static void main(String[] args) {
>         createWin(1);
>         createWin(2);
>     }
>
>     private static void createWin(int tgNum) {
>         ThreadGroup tg = new ThreadGroup("TG " + tgNum);
>
>         Thread t = new Thread(tg, new Runnable() {
>             public void run() {
>                 AppContext context = SunToolkit.createNewAppContext();
>
>                 SwingUtilities.invokeLater(new Runnable() {
>                     public void run() {
>                         final TestWinEvent window = new
> TestWinEvent(tgNum);
>                         window.setVisible(true);
>
>                         new Timer(10, window).start();
>                     }
>                 });
>             }
>         });
>         t.start();
>     }
>
>     public TestWinEvent(final int num) {
>         super("Test Window + " + num);
>         setMinimumSize(new Dimension(300, 200));
>         setLocation(100 + 400 * (num - 1), 100);
>
>         setLayout(new BorderLayout());
>         JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
>         add(textBlock);
>
>         btn = new JButton("TEST");
>         btn.addActionListener(new ActionListener() {
>             @Override
>             public void actionPerformed(ActionEvent e) {
>                 System.out.println("Button#" + num + " clicked: " +
> counter);
>             }
>
>         });
>         add(btn, BorderLayout.SOUTH);
>
>         setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>         pack();
>     }
>
>     @Override
>     public void actionPerformed(ActionEvent e) {
>         AWTEvent eventOne =
> getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
>         AWTEvent eventTwo =
> getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
>
>         btn.setText("TEST " + (counter++));
>
>
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
>
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
>     }
>
>     private AWTEvent getSequencedEvent(int id) {
>         AWTEvent wrapMe = new WindowEvent(this, id);
>         try {
>             @SuppressWarnings("unchecked")
>             Class<? extends AWTEvent> seqClass = (Class<? extends
> AWTEvent>) Class.forName("java.awt.SequencedEvent");
>             Constructor<? extends AWTEvent> seqConst =
> seqClass.getConstructor(AWTEvent.class);
>             seqConst.setAccessible(true);
>             AWTEvent instance = seqConst.newInstance(wrapMe);
>             return instance;
>         } catch (Throwable err) {
>             throw new Error("Unable to instantiate SequencedEvent", err);
>         }
>     }
> }
> ------
>
> Regards,
> Laurent
>
> Le mar. 4 sept. 2018 ? 15:59, Krishna Addepalli <
> krishna.addepalli at oracle.com> a ?crit :
>
>> Hi Laurent,
>>
>> Thanks for bringing this up. I have fixed a problem in this area
>> JDK-8152974, which is about AWT hang when SequencedEvents arrive out of
>> order.
>> However, the fix was partial, and same problem was reported in
>> JDK8(because of webstart), after it was backported. At that point, the fix
>> was reverted in JDK8, and since we couldn?t find a scenario in JDK11 (since
>> webstart is deprecated). It would be helpful if you could provide smallest
>> possible test case / sequence of steps to reproduce the problem.
>>
>> Thanks,
>> Krishna
>>
>> > On 04-Sep-2018, at 6:26 PM, Laurent Bourg?s <bourges.laurent at gmail.com>
>> wrote:
>> >
>> > Phil & Sergey,
>> >
>> > I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
>> > times the GUI hanging with AWT-EventQueue threads in the WAITING state
>> > (SequencedEvent) at EventQueue.getNextEvent().
>> >
>> > I fixed the netx code (EDT violations in swing code) but the problem
>> > is still happening randomly. This JavaWS implementation displays
>> > several JDialogs: Splash screen + download dialogs + Security prompts.
>> > When the application is hanging, I can not click on the Proceed/Cancel
>> > buttons of the Security dialogs and it is blocked forever.
>> >
>> > Are you aware about this problem ?
>> >
>> > As I can reproduce the problem, I can provide a heap-dump if you need.
>> >
>> > Here is a complete thread dump:
>> >
>> > Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
>> >
>> > Threads class SMR info:
>> > _java_thread_list=0x00007f94500170a0, length=44, elements={
>> > 0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800,
>> 0x00007f94b01ba800,
>> > 0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800,
>> 0x00007f94b01ff800,
>> > 0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800,
>> 0x00007f94b046b000,
>> > 0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000,
>> 0x00007f94b0aa8800,
>> > 0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000,
>> 0x00007f9428017800,
>> > 0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000,
>> 0x00007f942c1d0000,
>> > 0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000,
>> 0x00007f942c192000,
>> > 0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000,
>> 0x00007f942c1ca800,
>> > 0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000,
>> 0x00007f942c16a000,
>> > 0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800,
>> 0x00007f942c16f800,
>> > 0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000,
>> 0x00007f942c1d3800
>> > }
>> >
>> > "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
>> > tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
>> > [0x00007f94b9bee000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <0x00000000cd9c0c78> (a
>> net.sourceforge.jnlp.Launcher$TgThread)
>> >    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
>> >    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
>> > net.sourceforge.jnlp.Launcher$TgThread)
>> >    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>> /Launcher.java:258)
>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>> /Launcher.java:208)
>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>> /Launcher.java:287)
>> >    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11
>> /JnlpBoot.java:67)
>> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
>> /Boot.java:270)
>> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
>> /Boot.java:65)
>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>> Method)
>> >    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11
>> /Boot.java:210)
>> >
>> > "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
>> > elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
>> > [0x00007f9490efc000]
>> >   java.lang.Thread.State: RUNNABLE
>> >    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11
>> /Native
>> > Method)
>> >    at java.lang.ref.Reference.processPendingReferences(java.base at 11
>> /Reference.java:241)
>> >    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11
>> /Reference.java:213)
>> >
>> > "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
>> > tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
>> > [0x00007f9490dfb000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <0x00000000c01f16d0> (a
>> java.lang.ref.ReferenceQueue$Lock)
>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>> /ReferenceQueue.java:155)
>> >    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
>> > java.lang.ref.ReferenceQueue$Lock)
>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>> /ReferenceQueue.java:176)
>> >    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11
>> /Finalizer.java:170)
>> >
>> > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
>> > elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
>> > [0x0000000000000000]
>> >   java.lang.Thread.State: RUNNABLE
>> >
>> > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
>> > elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
>> > [0x0000000000000000]
>> >   java.lang.Thread.State: RUNNABLE
>> >   No compile task
>> >
>> > "C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
>> > elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
>> > [0x0000000000000000]
>> >   java.lang.Thread.State: RUNNABLE
>> >   No compile task
>> >
>> > "Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
>> > tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
>> >   java.lang.Thread.State: RUNNABLE
>> >
>> > "Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
>> > tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
>> > [0x00007f94904e3000]
>> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <0x00000000c01f2140> (a
>> java.lang.ref.ReferenceQueue$Lock)
>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>> /ReferenceQueue.java:155)
>> >    - waiting to re-lock in wait() <0x00000000c01f2140> (a
>> > java.lang.ref.ReferenceQueue$Lock)
>> >    at jdk.internal.ref.CleanerImpl.run(java.base at 11
>> /CleanerImpl.java:148)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >    at jdk.internal.misc.InnocuousThread.run(java.base at 11
>> /InnocuousThread.java:134)
>> >
>> > "Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
>> > tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
>> >   java.lang.Thread.State: RUNNABLE
>> >
>> > "Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
>> > elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
>> > [0x00007f944ddd7000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <0x00000000c01f2898> (a
>> java.lang.ref.ReferenceQueue$Lock)
>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>> /ReferenceQueue.java:155)
>> >    - waiting to re-lock in wait() <0x00000000c01f2898> (a
>> > java.lang.ref.ReferenceQueue$Lock)
>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>> /ReferenceQueue.java:176)
>> >    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
>> > tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
>> >   java.lang.Thread.State: RUNNABLE
>> >    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native Method)
>> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
>> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
>> > tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
>> > [0x00007f944dbd5000]
>> >   java.lang.Thread.State: TIMED_WAITING (sleeping)
>> >    at java.lang.Thread.sleep(java.base at 11/Native Method)
>> >    at
>> net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11
>> /TracingEventQueue.java:92)
>> >
>> > "Output controller consumer daemon" #15 daemon prio=5 os_prio=0
>> > cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
>> > Object.wait()  [0x00007f944d8d4000]
>> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <no object reference available>
>> >    at
>> net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11
>> /OutputController.java:122)
>> >    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
>> > net.sourceforge.jnlp.util.logging.OutputController)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
>> > tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
>> > [0x00007f944d7d3000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <no object reference available>
>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>> >    at sun.awt.AWTAutoShutdown.run(java.desktop at 11
>> /AWTAutoShutdown.java:291)
>> >    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a
>> java.lang.Object)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
>> > tid=0x00007f943400e000 nid=0x15fa waiting on condition
>> > [0x00007f944d6d2000]
>> >   java.lang.Thread.State: WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000c01f3870> (a
>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>> /LockSupport.java:194)
>> >    at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>> /AbstractQueuedSynchronizer.java:2081)
>> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
>> /EventQueue.java:566)
>> >    at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>> /EventDispatchThread.java:190)
>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>> /EventDispatchThread.java:124)
>> >    at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>> /EventDispatchThread.java:113)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:109)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:101)
>> >    at java.awt.EventDispatchThread.run(java.desktop at 11
>> /EventDispatchThread.java:90)
>> >
>> > "NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
>> > elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
>> > [0x00007f9420dac000]
>> >   java.lang.Thread.State: WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd519d48> (a
>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>> /LockSupport.java:194)
>> >    at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>> /AbstractQueuedSynchronizer.java:2081)
>> >    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11
>> /LinkedBlockingQueue.java:433)
>> >    at
>> net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11
>> /SecurityDialogMessageHandler.java:93)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
>> > elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
>> > [0x00007f9420865000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
>> > tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
>> > [0x00007f942011e000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <no object reference available>
>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>> /EventQueue.java:1361)
>> >    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
>> > java.awt.EventQueue$1AWTInvocationLock)
>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>> /EventQueue.java:1342)
>> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
>> /SwingUtilities.java:1480)
>> >    at
>> net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11
>> /DefaultDownloadIndicator.java:146)
>> >    at
>> net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11
>> /CacheUtil.java:569)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11
>> /JNLPClassLoader.java:1498)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11
>> /JNLPClassLoader.java:712)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
>> /JNLPClassLoader.java:338)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>> /JNLPClassLoader.java:500)
>> >    - locked <0x00000000cd98b9d8> (a
>> java.util.concurrent.locks.ReentrantLock)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>> /JNLPClassLoader.java:545)
>> >    - locked <0x00000000cd98b9d8> (a
>> java.util.concurrent.locks.ReentrantLock)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11
>> /JNLPClassLoader.java:578)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
>> /JNLPClassLoader.java:336)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11
>> /JNLPClassLoader.java:421)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>> /JNLPClassLoader.java:495)
>> >    - locked <0x00000000cd98b9d8> (a
>> java.util.concurrent.locks.ReentrantLock)
>> >    at
>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>> /JNLPClassLoader.java:468)
>> >    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11
>> /Launcher.java:815)
>> >    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11
>> /Launcher.java:529)
>> >    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11
>> /Launcher.java:947)
>> >
>> > "AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
>> > tid=0x00007f942c075000 nid=0x1608 waiting on condition
>> > [0x00007f940bbf7000]
>> >   java.lang.Thread.State: WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd9a80a8> (a
>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>> /LockSupport.java:194)
>> >    at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>> /AbstractQueuedSynchronizer.java:2081)
>> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
>> /EventQueue.java:620)
>> >    at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>> /EventDispatchThread.java:190)
>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>> /EventDispatchThread.java:124)
>> >    at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>> /EventDispatchThread.java:113)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:109)
>> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
>> /SequencedEvent.java:138)
>> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
>> /EventQueue.java:770)
>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>> Method)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:85)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:95)
>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>> Method)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:85)
>> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
>> /EventQueue.java:742)
>> >    at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>> /EventDispatchThread.java:203)
>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>> /EventDispatchThread.java:124)
>> >    at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>> /EventDispatchThread.java:113)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:109)
>> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
>> /SequencedEvent.java:138)
>> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
>> /EventQueue.java:770)
>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>> Method)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:85)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:95)
>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>> Method)
>> >    at
>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>> /ProtectionDomain.java:85)
>> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
>> /EventQueue.java:742)
>> >    at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>> /EventDispatchThread.java:203)
>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>> /EventDispatchThread.java:124)
>> >    at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>> /EventDispatchThread.java:113)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:109)
>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>> /EventDispatchThread.java:101)
>> >    at java.awt.EventDispatchThread.run(java.desktop at 11
>> /EventDispatchThread.java:90)
>> >
>> > "Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
>> > tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
>> > [0x00007f940bafd000]
>> >   java.lang.Thread.State: BLOCKED (on object monitor)
>> >    at
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
>> /BasePainter.java:565)
>> >    - waiting to lock <0x00000000cd9a85d8> (a
>> >
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>> >    at java.util.Observable.notifyObservers(java.base at 11
>> /Observable.java:173)
>> >    at java.util.Observable.notifyObservers(java.base at 11
>> /Observable.java:129)
>> >    at
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11
>> /BasePainter.java:419)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
>> > tid=0x00007f9428024000 nid=0x160a in Object.wait()
>> > [0x00007f940b9fc000]
>> >   java.lang.Thread.State: WAITING (on object monitor)
>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>> >    - waiting on <no object reference available>
>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>> /EventQueue.java:1361)
>> >    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
>> > java.awt.EventQueue$1AWTInvocationLock)
>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>> /EventQueue.java:1342)
>> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
>> /SwingUtilities.java:1480)
>> >    at
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
>> /BasePainter.java:579)
>> >    - locked <0x00000000cd9a85d8> (a
>> >
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>> >    at java.util.Observable.notifyObservers(java.base at 11
>> /Observable.java:173)
>> >    at java.util.Observable.notifyObservers(java.base at 11
>> /Observable.java:129)
>> >    at
>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11
>> /BasePainter.java:452)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
>> > elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
>> > [0x00007f940b4e7000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
>> > tid=0x00007f942c15b000 nid=0x1613 waiting on condition
>> > [0x00007f940b5fa000]
>> >   java.lang.Thread.State: WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cf319e08> (a
>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>> /LockSupport.java:194)
>> >    at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>> /AbstractQueuedSynchronizer.java:2081)
>> >    at java.util.concurrent.DelayQueue.take(java.base at 11
>> /DelayQueue.java:217)
>> >    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
>> > elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
>> > [0x00007f9407bfa000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
>> > elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
>> > [0x00007f9407cfb000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
>> > elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
>> > [0x00007f9407af9000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
>> > elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
>> > [0x00007f94079f8000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
>> > elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
>> > [0x00007f94078f7000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
>> > elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
>> > [0x00007f94077f6000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
>> > elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
>> > [0x00007f94074f3000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
>> > elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
>> > [0x00007f94073f2000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
>> > elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
>> > [0x00007f94072f1000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
>> > elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
>> > [0x00007f94071f0000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
>> > elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
>> > [0x00007f94070ef000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
>> > elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
>> > [0x00007f9406fee000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
>> > elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
>> > [0x00007f9406eed000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
>> > elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
>> > [0x00007f94076f5000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
>> > elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
>> > [0x00007f9406dec000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
>> > elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
>> > [0x00007f94075f4000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
>> > elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
>> > [0x00007f9406ceb000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
>> > elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
>> > [0x00007f94069e8000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
>> > elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
>> > [0x00007f9406bea000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
>> > elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
>> > [0x00007f9406ae9000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
>> > elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
>> > [0x00007f94061e0000]
>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>> >    - parking to wait for  <0x00000000cd726dc0> (a
>> > java.util.concurrent.SynchronousQueue$TransferStack)
>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>> /LockSupport.java:234)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>> /SynchronousQueue.java:462)
>> >    at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>> /SynchronousQueue.java:361)
>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>> /SynchronousQueue.java:937)
>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>> /ThreadPoolExecutor.java:1053)
>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>> /ThreadPoolExecutor.java:1114)
>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>> /ThreadPoolExecutor.java:628)
>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>> >
>> > "VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
>> > tid=0x00007f94b019b800 nid=0x15e7 runnable
>> >
>> > "GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
>> > tid=0x00007f94b0040000 nid=0x15e2 runnable
>> >
>> > "GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
>> > tid=0x00007f9480001000 nid=0x15fb runnable
>> >
>> > "GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
>> > tid=0x00007f9480002800 nid=0x15fc runnable
>> >
>> > "GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
>> > tid=0x00007f9480004000 nid=0x15fd runnable
>> >
>> > "G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
>> > tid=0x00007f94b005b800 nid=0x15e3 runnable
>> >
>> > "G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
>> > tid=0x00007f94b005d800 nid=0x15e4 runnable
>> >
>> > "G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
>> > tid=0x00007f94b013a800 nid=0x15e5 runnable
>> >
>> > "G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
>> > tid=0x00007f9488001000 nid=0x15fe runnable
>> >
>> > "G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
>> > tid=0x00007f94b013c800 nid=0x15e6 runnable
>> > "VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
>> > tid=0x00007f94b02db000 nid=0x15f1 waiting on condition
>> >
>> > JNI global refs: 88, weak refs: 487
>> >
>> > Heap
>> > garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
>> > 0x0000000100000000)
>> >  region size 1024K, 99 young (101376K), 5 survivors (5120K)
>> > Metaspace       used 32074K, capacity 32873K, committed 33280K,
>> > reserved 1079296K
>> >  class space    used 3388K, capacity 3743K, committed 3840K, reserved
>> 1048576K
>>
>>
>
> --
> --
> Laurent Bourg?s
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/bb44c945/attachment-0001.html>

From pankaj.b.bansal at oracle.com  Wed Sep  5 07:56:56 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 5 Sep 2018 00:56:56 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional
 support for GTK 3 on Linux
Message-ID: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>

Hi All,

 

Please review the patch for 8u-dev backport for JDK-8145547. It adds conditional support for gtk3. 

The original fix does not apply cleanly as few changes were done  in jdk9 before the gtk3 support was added, major once being HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8025815"JDK-8025815, HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8014212"JDK-8014212 and HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8137571"JDK-8137571 

 

Along with the enhancement, following bug fixes have also been included in the backport webrev

 

1.      https://bugs.openjdk.java.net/browse/JDK-8155772: gtk3_interface.c compilation error on Ubuntu 12.10

2.      https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 breaks AIX and and uses RTLD_NOLOAD incorrectly

3.      https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward" fails for GTK3 if no GTK2 available

4.      https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for [AWT/Swing] Conditional support for GTK 3 on Linux 

5.      https://bugs.openjdk.java.net/browse/JDK-8157827: AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK version when jdk.gtk.version=3

6.      https://bugs.openjdk.java.net/browse/JDK-8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".

7.      https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable Rendering of Disabled Text in Swing GTK L&F

8.      https://bugs.openjdk.java.net/browse/JDK-8203003: Several FileDialog Modality Tests fail on Linux due to X errors

9.      https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure on Linux arm64

10.   https://bugs.openjdk.java.net/browse/JDK-8154546: Retire sun.misc.GThreadHelper

11.   https://bugs.openjdk.java.net/browse/JDK-8152968: JTree Collapse Buttons Clipped Off Under GTK

12.   https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 menus appearence similar to native.

13.   https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash in AWT_Desktop/Automated/Exceptions/BasicTest

14.   https://bugs.openjdk.java.net/browse/JDK-8160054: The FileChooser didn't displayed large font with GTK LAF option.

15.   https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of SwingNode with GTK LaF

16.   https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait] Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of awt_UNIXToolkit.c:132

17.   https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris build failed: gtk2_interface.h typedef redeclared: GThreadFunctions

 

 

webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8145547

JDK 9 Changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8

I have run the related jtreg and jck tests and results are fine.

 

Regards,

Pankaj

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/660f76fb/attachment.html>

From dmitry.markov at oracle.com  Wed Sep  5 11:17:47 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 5 Sep 2018 12:17:47 +0100
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
Message-ID: <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>

Hi Manajit,

Thank you for the clarification.

Actually I worry about the case when a window is blocked by another window or a modal dialog. We call orderAboveSiblings() for the blocker window in several places, (e.g. inside setVisible(), checkBlockingAndOrder(), etc.) and I guess some of these call might fail with the new implementation of orderAboveSiblings(), (i.e. the modal dialog might be placed behind the blocked window).

For example, let?s say we have the window which is blocked by the modal dialog. What will be the position of the dialog (above or behind the blocked window) once the window is activated? Please note: there are several ways to activate the window: mouse click, toFront() call, etc. Can you verify that these scenarios still work properly on the build with your fix, please?

Also it would be good to execute related AWT/Swing jtreg tests to ensure that nothing is broken.

Thanks,
Dmitry 

> On 4 Sep 2018, at 18:54, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> Thanks for your reply. Please see my reply inline.
> 
> Thanks,
> Manajit
> 
> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>> Hi Manajit,
>> 
>> The current implementation assumes that orderAboveSiblings() places the window in front of other windows located at the same level. The proposed fix introduces new behaviour: if the window does not have an owner and child windows it won?t be ordered, (i.e. in certain conditions the window may be obscured by other windows even after orderAboveSibling() execution). Most likely such approach will break existed functionality - some windows will be incorrectly placed behind other windows.
>     If I am not wrong windows (other than Window.Type.POPUP) are already ordered in setVisible method at line no 632 while creation. While debugging I observed that orderFront is called twice when the window is displayed for the first time (in method setVisible and in method orderAboveSiblings). Now when Key press COMMAND + ` is pressed the current window receives windowDidBecomeMain notification and which calls orderFront and also COMMAND + ` tries to order the window above. Two time ordering the window when COMMAND + ` is pressed is causing problem in case of multiple windows.
>> 
>> I am sorry, but the relationship between the original problem described in the bug, (i.e. cycling through windows issue) and implementation of orderAboveSiblings() is NOT clear. Can you explain this?
>     This issue is a regression of JDK-8169589 introduced in JDK release 8u131. 8169589 introduced new window ordering model and which has introduced the cycling through window issue.
>> 
>> Thanks,
>> Dmitry  
>> 
>>> On 31 Aug 2018, at 07:55, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review the fix for JDK12.
>>> 
>>> 
>>> 
>>> Bug: 
>>>      https://bugs.openjdk.java.net/browse/JDK-8206392 <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>>  <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>> Webrev: 
>>> 
>>>     http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>> Fix: 
>>> 
>>>     Window ordering is not required if the window doesn't own any other windows.
>>> 
>>> Regards,
>>> Manajit
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/68fe1077/attachment-0001.html>

From magnus.ihse.bursie at oracle.com  Wed Sep  5 12:19:10 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 5 Sep 2018 14:19:10 +0200
Subject: <AWT Dev> RFR: JDK-8056217 Remove awt_makecube.cpp
Message-ID: <c505107f-beb4-6b6a-c441-cd80539538ce@oracle.com>

As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
is not compiler nor used) should be removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8056217

Change:
$ hg status
R src/java.desktop/windows/native/common/awt_makecube.cpp

/Magnus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/9860dfef/attachment.html>

From takiguc at linux.vnet.ibm.com  Wed Sep  5 14:08:14 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 05 Sep 2018 23:08:14 +0900
Subject: <AWT Dev> StackOverflowError happened by TextField.setFont(...)
In-Reply-To: <8d293bb4-53d1-458d-84aa-14da927e5fb6@default>
References: <246641344f11cd8c8beea5bbee12b898@linux.vnet.ibm.com>
 <1c835ef6-d8f6-440c-bbbb-717765697d4d@default>
 <c5067ac4c31c9da5d24e8ed1c04a50e7@linux.vnet.ibm.com>
 <b67141f59aac0fc92c5ef0cf2d2eb497@linux.vnet.ibm.com>
 <8d293bb4-53d1-458d-84aa-14da927e5fb6@default>
Message-ID: <92b7945b0ed0b538d9b5904cb9cc128a@linux.vnet.ibm.com>

Hello Krishna.

Thank you for your testing.

As you suggested, I tried to check peer side.
I think, to avoid recursive call. Java may call validate() against XAWT 
peer.

=====================
diff -r 499b873761d8 
src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java
--- a/src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java	Wed 
Jul 25 11:03:07 2018 +0800
+++ b/src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java	Wed 
Sep 05 23:03:57 2018 +0900
@@ -284,6 +284,8 @@
          synchronized (getStateLock()) {
              font = f;
              if (xtext != null && xtext.getFont() != f) {
+                if (!xtext.isValid())
+                    xtext.validate();
                  xtext.setFont(font);
              }
          }
=====================

How about this fix ?

On 2018-09-05 00:20, Krishna Addepalli wrote:
> Hi Ichiroh,
> 
> Yes I'm able to see this issue in jdk12 repo on Ubuntu. But this issue
> is not reproducible on Windows.
> So, I guess the fix has to be specific to Linux.
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Sent: Monday, September 3, 2018 4:26 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>
> Subject: Re: <AWT Dev> StackOverflowError happened by 
> TextField.setFont(...)
> 
> Hello Krishna.
> 
> Sorry for bothering you.
> I'd like to know you could recreate this issue or not.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-08-27 15:14, Ichiroh Takiguchi wrote:
>> Hello Krishna.
>> 
>> Thank you for your testing.
>> 
>> I'm sorry, I could not put information about tested platform.
>> I just tested this issue with jdk-12+8 on RHEL6/7 x86_64 and Ubuntu
>> 14.04.5 x86_64.
>> Still I could recreate this issue.
>> 
>> Test instruction is as follows:
>> 1. Compile and run FontChangeTest
>> 2. Press "Shuffle" button to top
>> 3. Change Font size (TextField) "12" to "24" on right-buttom, then
>> press Enter/Return key
>>    Then above exception will be happened
>> 
>> Thanks,
>> 
>> On 2018-08-27 12:55, Krishna Addepalli wrote:
>>> Hi Ichiroh,
>>> 
>>> I have tried the steps you outlined, but I'm not able to reproduce
>>> the issue you are seeing. Could you try with the latest jdk12 repo?
>>> 
>>> Thanks,
>>> Krishna
>>> 
>>> -----Original Message-----
>>> From: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
>>> Sent: Friday, August 24, 2018 1:42 PM
>>> To: awt-dev at openjdk.java.net
>>> Subject: <AWT Dev> StackOverflowError happened by
>>> TextField.setFont(...)
>>> 
>>> Hello.
>>> 
>>> I could see following exception by TextField.setFont(...) by jdk-12+6
>>> 
>>> =====================
>>> Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
>>>          at
>>> java.desktop/javax.swing.plaf.basic.BasicTextUI$UpdateHandler.layoutContainer(BasicTextUI.java:2061)
>>>          at
>>> java.desktop/java.awt.Container.layout(Container.java:1537)
>>>          at
>>> java.desktop/java.awt.Container.doLayout(Container.java:1526)
>>>          at
>>> java.desktop/java.awt.Container.validateTree(Container.java:1722)
>>>          at
>>> java.desktop/java.awt.Container.validate(Container.java:1657)
>>>          at
>>> java.desktop/sun.awt.X11.XTextFieldPeer.setFont(XTextFieldPeer.java:290)
>>>          at
>>> java.desktop/java.awt.Component.validate(Component.java:2976)
>>>          at
>>> java.desktop/java.awt.Container.validateTree(Container.java:1740)
>>>          at
>>> java.desktop/java.awt.Container.validate(Container.java:1657)
>>>          at
>>> java.desktop/sun.awt.X11.XTextFieldPeer.setFont(XTextFieldPeer.java:290)
>>>          at
>>> java.desktop/java.awt.Component.validate(Component.java:2976)
>>>          at
>>> java.desktop/java.awt.Container.validateTree(Container.java:1740)
>>> ...
>>> =====================
>>> 
>>> It seemed that sun.awt.X11.XTextFieldPeer.setFont(...) was called
>>> recursively.
>>> 
>>> I used following test program to recreate this issue.
>>> =====================
>>> import java.awt.*;
>>> import java.awt.event.*;
>>> import java.awt.font.*;
>>> import java.util.*;
>>> 
>>> public class FontChangeTest extends Frame
>>>    implements ActionListener, ItemListener {
>>>    Panel p;
>>>    java.util.List list = Arrays.asList(
>>>      "1","2","3","4","5","6","7","8","9");
>>>    TextField[] textfs = new TextField[list.size()];;
>>>    Choice fontName, fontStyle;
>>>    TextField fontSize;
>>>    final static String[] fontStyles = new String[]{
>>>      "Plain","Bold","Italic","ItalicBold"};
>>>    final static int[] fontStylesId = new int[]{
>>>      Font.PLAIN,Font.BOLD,Font.ITALIC,Font.BOLD+Font.ITALIC};
>>>    Button btn;
>>>    final int fSize = 12;
>>>    void shuffle() {
>>>      Collections.shuffle(list);
>>>      for(int i=0; i<list.size(); i++) {
>>>        textfs[i].setText(list.get(i).toString());
>>>      }
>>>    }
>>>    void init() {
>>>      setLayout(new BorderLayout());
>>>      Panel p0 = new Panel();
>>>      p0.setLayout(new FlowLayout());
>>>      add(p0, BorderLayout.NORTH);
>>>      btn = new Button("Shuffle");
>>>      btn.addActionListener(this);
>>>      p0.add(btn);
>>>      Panel p1 = new Panel();
>>>      p1.setLayout(new FlowLayout());
>>>      add(p1, BorderLayout.SOUTH);
>>>      fontName = new Choice();
>>>      fontName.addItemListener(this);
>>>      for(String s : Toolkit.getDefaultToolkit().getFontList()) {
>>>        fontName.add(s);
>>>      }
>>>      p1.add(fontName);
>>>      fontStyle = new Choice();
>>>      fontStyle.addItemListener(this);
>>>      for(String s : fontStyles) {
>>>        fontStyle.add(s);
>>>      }
>>>      p1.add(fontStyle);
>>>      fontSize = new TextField(String.valueOf(fSize),2);
>>>      fontSize.addActionListener(this);
>>>      p1.add(fontSize);
>>>      p = new Panel();
>>>      add(p, BorderLayout.CENTER);
>>>      p.setLayout(new GridLayout(0,3,3,3));
>>>      for(int i=0; i<list.size(); i++) {
>>>        textfs[i] = new TextField(1);
>>>        textfs[i].setFont(new Font(fontName.getSelectedItem(),
>>>                          fontStylesId[fontStyle.getSelectedIndex()],
>>>                          fSize));
>>>        p.add(textfs[i]);
>>>      }
>>>      shuffle();
>>>    }
>>>    public void changeFont() {
>>>      int size;
>>>      try {
>>>        size = Integer.parseInt(fontSize.getText());
>>>        for(int i=0; i<textfs.length; i++) {
>>>          textfs[i].setFont(new Font(fontName.getSelectedItem(),
>>>                            
>>> fontStylesId[fontStyle.getSelectedIndex()],
>>>                            size));
>>>        }
>>>      } catch (java.lang.NumberFormatException nfe) {
>>>      }
>>>    }
>>>    FontChangeTest() {
>>>      super("FontChangeTest");
>>>      init();
>>>      addWindowListener(new WindowAdapter() {
>>>        public void windowClosing(WindowEvent we) { System.exit(0); }
>>>      });
>>>      pack();
>>>      setVisible(true);
>>>    }
>>>    public void actionPerformed(ActionEvent ae) {
>>>      if (ae.getSource().equals(btn)) {
>>>        p.setVisible(false);
>>>        shuffle();
>>>        p.setVisible(true);
>>>      } else if (ae.getSource().equals(fontSize)) {
>>>        changeFont();
>>>        pack();
>>>      }
>>>    }
>>>    public void itemStateChanged(ItemEvent ie) {
>>>      changeFont();
>>>      pack();
>>>    }
>>>    public static void main(String[] args) {
>>>      new FontChangeTest();
>>>    }
>>> }
>>> =====================
>>> 
>>> Test instruction is as follows:
>>> 1. Compile and run FontChangeTest
>>> 2. Press "Shuffle" button to top
>>> 3. Click left buttom's Choice button, then change "Dialog" to
>>> "SansSerif"
>>>     Then above exception will be happened
>>> 
>>> It worked fine with JDK8
>>> java version "1.8.0_181"
>>> Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java
>>> HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>>> 
>>> Failed by
>>> openjdk version "12-ea" 2019-03-19
>>> OpenJDK Runtime Environment 19.3 (build 12-ea+6) OpenJDK 64-Bit
>>> Server VM 19.3 (build 12-ea+6, mixed mode)
>>> 
>>> One of fix candidate is:
>>> =====================
>>> diff -r 945ba9278a27
>>> src/java.desktop/share/classes/java/awt/Component.java
>>> --- a/src/java.desktop/share/classes/java/awt/Component.java    Tue
>>> Aug
>>> 07 00:06:52 2018 -0700
>>> +++ b/src/java.desktop/share/classes/java/awt/Component.java    Fri
>>> Aug
>>> 24 16:59:19 2018 +0900
>>> @@ -1936,8 +1936,8 @@
>>>               if (peer != null) {
>>>                   f = getFont();
>>>                   if (f != null) {
>>> +                    peerFont = f;
>>>                       peer.setFont(f);
>>> -                    peerFont = f;
>>>                   }
>>>               }
>>>           }
>>> =====================
>>> 
>>> I'm not sure, it's good or not...
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.


From bourges.laurent at gmail.com  Wed Sep  5 14:59:25 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 5 Sep 2018 16:59:25 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <CAKjRUT7t7D2txuDC6Lh9G5YXqKp=-ufZ4RP4AE9YduaPNRtPZw@mail.gmail.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
 <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
 <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>
 <CAKjRUT7t7D2txuDC6Lh9G5YXqKp=-ufZ4RP4AE9YduaPNRtPZw@mail.gmail.com>
Message-ID: <CAKjRUT7z6EH657tkhLMBfagC_z2EfyALnc1FLZHkUOD_WU8pog@mail.gmail.com>

Hi again,

FYI Today I managed fixing the AWT deadlock by using the forementioned
workaround:
- use a specific thread pool within the Main thread group (not JNLP's
AppContext) to relay the EDT invocations (invokeLater / invokeAndWait) as I
figured out that SplashScreen & DownloadIndicator dialogs were using the
JNLP AppContext
=> 2 concurrent AppContexts were used and 2 event dispatcher threads led to
deadlocks in AWT SequencedEvent processing (Window Gain / Lost focus).

With that workaround, all EDT actions from ITW are delivered via the Main
AppContext and it works well now : no more AWT hanging !

Laurent

Le mer. 5 sept. 2018 ? 08:45, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi,
> Should we submit a new bug or complete the opened bug with this reproducer
> ?
>
> It is quite critical for OpenJDK 11 adoption as I expect linux
> distributions at least will provide icedtea-web for javaws support, even
> for 11+.
>
> I will try implementing a workaround redirecting EDT using a single
> AppContext... to reduce the opportunity to have deadlock = only 1 EDT used
> at the same time.
>
> Regards,
> Laurent
>
> Le mar. 4 sept. 2018 ? 22:11, Laurent Bourg?s <bourges.laurent at gmail.com>
> a ?crit :
>
>> Hi Krishna,
>>
>> Thanks for your answers, I managed writing a simple reproducer, see below.
>> I inspected heap dumps on jvisualvm but it looks like the First
>> SequencedEvent is not consumed and is blocking the queue for ever.
>>
>> On JDK8 or JDK10: it works (windows are animated and not hanging).
>> On JDK11: it starts but is immediately frozen !
>>
>> Could you have a look ?
>>
>> ----
>> import java.awt.AWTEvent;
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import java.awt.Toolkit;
>> import java.awt.event.ActionEvent;
>> import java.awt.event.ActionListener;
>> import java.awt.event.WindowEvent;
>> import java.lang.reflect.Constructor;
>> import javax.swing.JButton;
>>
>> import javax.swing.JFrame;
>> import javax.swing.JLabel;
>> import javax.swing.SwingUtilities;
>> import javax.swing.Timer;
>> import sun.awt.AppContext;
>> import sun.awt.SunToolkit;
>>
>> /*
>>  * Running this code causes the AWT Event Queues to be blocked on
>> OpenJDK11
>>  * @author Laurent Bourges
>>  */
>> public class TestWinEvent extends JFrame implements ActionListener {
>>
>>     private static final long serialVersionUID = 1L;
>>
>>     private int counter = 0;
>>     private JButton btn;
>>
>>     public static void main(String[] args) {
>>         createWin(1);
>>         createWin(2);
>>     }
>>
>>     private static void createWin(int tgNum) {
>>         ThreadGroup tg = new ThreadGroup("TG " + tgNum);
>>
>>         Thread t = new Thread(tg, new Runnable() {
>>             public void run() {
>>                 AppContext context = SunToolkit.createNewAppContext();
>>
>>                 SwingUtilities.invokeLater(new Runnable() {
>>                     public void run() {
>>                         final TestWinEvent window = new
>> TestWinEvent(tgNum);
>>                         window.setVisible(true);
>>
>>                         new Timer(10, window).start();
>>                     }
>>                 });
>>             }
>>         });
>>         t.start();
>>     }
>>
>>     public TestWinEvent(final int num) {
>>         super("Test Window + " + num);
>>         setMinimumSize(new Dimension(300, 200));
>>         setLocation(100 + 400 * (num - 1), 100);
>>
>>         setLayout(new BorderLayout());
>>         JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
>>         add(textBlock);
>>
>>         btn = new JButton("TEST");
>>         btn.addActionListener(new ActionListener() {
>>             @Override
>>             public void actionPerformed(ActionEvent e) {
>>                 System.out.println("Button#" + num + " clicked: " +
>> counter);
>>             }
>>
>>         });
>>         add(btn, BorderLayout.SOUTH);
>>
>>         setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>         pack();
>>     }
>>
>>     @Override
>>     public void actionPerformed(ActionEvent e) {
>>         AWTEvent eventOne =
>> getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
>>         AWTEvent eventTwo =
>> getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
>>
>>         btn.setText("TEST " + (counter++));
>>
>>
>> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
>>
>> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
>>     }
>>
>>     private AWTEvent getSequencedEvent(int id) {
>>         AWTEvent wrapMe = new WindowEvent(this, id);
>>         try {
>>             @SuppressWarnings("unchecked")
>>             Class<? extends AWTEvent> seqClass = (Class<? extends
>> AWTEvent>) Class.forName("java.awt.SequencedEvent");
>>             Constructor<? extends AWTEvent> seqConst =
>> seqClass.getConstructor(AWTEvent.class);
>>             seqConst.setAccessible(true);
>>             AWTEvent instance = seqConst.newInstance(wrapMe);
>>             return instance;
>>         } catch (Throwable err) {
>>             throw new Error("Unable to instantiate SequencedEvent", err);
>>         }
>>     }
>> }
>> ------
>>
>> Regards,
>> Laurent
>>
>> Le mar. 4 sept. 2018 ? 15:59, Krishna Addepalli <
>> krishna.addepalli at oracle.com> a ?crit :
>>
>>> Hi Laurent,
>>>
>>> Thanks for bringing this up. I have fixed a problem in this area
>>> JDK-8152974, which is about AWT hang when SequencedEvents arrive out of
>>> order.
>>> However, the fix was partial, and same problem was reported in
>>> JDK8(because of webstart), after it was backported. At that point, the fix
>>> was reverted in JDK8, and since we couldn?t find a scenario in JDK11 (since
>>> webstart is deprecated). It would be helpful if you could provide smallest
>>> possible test case / sequence of steps to reproduce the problem.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> > On 04-Sep-2018, at 6:26 PM, Laurent Bourg?s <bourges.laurent at gmail.com>
>>> wrote:
>>> >
>>> > Phil & Sergey,
>>> >
>>> > I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
>>> > times the GUI hanging with AWT-EventQueue threads in the WAITING state
>>> > (SequencedEvent) at EventQueue.getNextEvent().
>>> >
>>> > I fixed the netx code (EDT violations in swing code) but the problem
>>> > is still happening randomly. This JavaWS implementation displays
>>> > several JDialogs: Splash screen + download dialogs + Security prompts.
>>> > When the application is hanging, I can not click on the Proceed/Cancel
>>> > buttons of the Security dialogs and it is blocked forever.
>>> >
>>> > Are you aware about this problem ?
>>> >
>>> > As I can reproduce the problem, I can provide a heap-dump if you need.
>>> >
>>> > Here is a complete thread dump:
>>> >
>>> > Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
>>> >
>>> > Threads class SMR info:
>>> > _java_thread_list=0x00007f94500170a0, length=44, elements={
>>> > 0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800,
>>> 0x00007f94b01ba800,
>>> > 0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800,
>>> 0x00007f94b01ff800,
>>> > 0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800,
>>> 0x00007f94b046b000,
>>> > 0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000,
>>> 0x00007f94b0aa8800,
>>> > 0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000,
>>> 0x00007f9428017800,
>>> > 0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000,
>>> 0x00007f942c1d0000,
>>> > 0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000,
>>> 0x00007f942c192000,
>>> > 0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000,
>>> 0x00007f942c1ca800,
>>> > 0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000,
>>> 0x00007f942c16a000,
>>> > 0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800,
>>> 0x00007f942c16f800,
>>> > 0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000,
>>> 0x00007f942c1d3800
>>> > }
>>> >
>>> > "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
>>> > tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
>>> > [0x00007f94b9bee000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <0x00000000cd9c0c78> (a
>>> net.sourceforge.jnlp.Launcher$TgThread)
>>> >    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
>>> >    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
>>> > net.sourceforge.jnlp.Launcher$TgThread)
>>> >    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
>>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>>> /Launcher.java:258)
>>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>>> /Launcher.java:208)
>>> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11
>>> /Launcher.java:287)
>>> >    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11
>>> /JnlpBoot.java:67)
>>> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
>>> /Boot.java:270)
>>> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11
>>> /Boot.java:65)
>>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>>> Method)
>>> >    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11
>>> /Boot.java:210)
>>> >
>>> > "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
>>> > elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
>>> > [0x00007f9490efc000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11
>>> /Native
>>> > Method)
>>> >    at java.lang.ref.Reference.processPendingReferences(java.base at 11
>>> /Reference.java:241)
>>> >    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11
>>> /Reference.java:213)
>>> >
>>> > "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
>>> > tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
>>> > [0x00007f9490dfb000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <0x00000000c01f16d0> (a
>>> java.lang.ref.ReferenceQueue$Lock)
>>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>>> /ReferenceQueue.java:155)
>>> >    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
>>> > java.lang.ref.ReferenceQueue$Lock)
>>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>>> /ReferenceQueue.java:176)
>>> >    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11
>>> /Finalizer.java:170)
>>> >
>>> > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
>>> > elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
>>> > [0x0000000000000000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >
>>> > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
>>> > elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
>>> > [0x0000000000000000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >   No compile task
>>> >
>>> > "C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
>>> > elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
>>> > [0x0000000000000000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >   No compile task
>>> >
>>> > "Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
>>> > tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >
>>> > "Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
>>> > tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
>>> > [0x00007f94904e3000]
>>> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <0x00000000c01f2140> (a
>>> java.lang.ref.ReferenceQueue$Lock)
>>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>>> /ReferenceQueue.java:155)
>>> >    - waiting to re-lock in wait() <0x00000000c01f2140> (a
>>> > java.lang.ref.ReferenceQueue$Lock)
>>> >    at jdk.internal.ref.CleanerImpl.run(java.base at 11
>>> /CleanerImpl.java:148)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >    at jdk.internal.misc.InnocuousThread.run(java.base at 11
>>> /InnocuousThread.java:134)
>>> >
>>> > "Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
>>> > tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >
>>> > "Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
>>> > elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
>>> > [0x00007f944ddd7000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <0x00000000c01f2898> (a
>>> java.lang.ref.ReferenceQueue$Lock)
>>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>>> /ReferenceQueue.java:155)
>>> >    - waiting to re-lock in wait() <0x00000000c01f2898> (a
>>> > java.lang.ref.ReferenceQueue$Lock)
>>> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11
>>> /ReferenceQueue.java:176)
>>> >    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
>>> > tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
>>> >   java.lang.Thread.State: RUNNABLE
>>> >    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native
>>> Method)
>>> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
>>> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
>>> > tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
>>> > [0x00007f944dbd5000]
>>> >   java.lang.Thread.State: TIMED_WAITING (sleeping)
>>> >    at java.lang.Thread.sleep(java.base at 11/Native Method)
>>> >    at
>>> net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11
>>> /TracingEventQueue.java:92)
>>> >
>>> > "Output controller consumer daemon" #15 daemon prio=5 os_prio=0
>>> > cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
>>> > Object.wait()  [0x00007f944d8d4000]
>>> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <no object reference available>
>>> >    at
>>> net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11
>>> /OutputController.java:122)
>>> >    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
>>> > net.sourceforge.jnlp.util.logging.OutputController)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
>>> > tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
>>> > [0x00007f944d7d3000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <no object reference available>
>>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>>> >    at sun.awt.AWTAutoShutdown.run(java.desktop at 11
>>> /AWTAutoShutdown.java:291)
>>> >    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a
>>> java.lang.Object)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
>>> > tid=0x00007f943400e000 nid=0x15fa waiting on condition
>>> > [0x00007f944d6d2000]
>>> >   java.lang.Thread.State: WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000c01f3870> (a
>>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>>> /LockSupport.java:194)
>>> >    at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>>> /AbstractQueuedSynchronizer.java:2081)
>>> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
>>> /EventQueue.java:566)
>>> >    at
>>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>>> /EventDispatchThread.java:190)
>>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>>> /EventDispatchThread.java:124)
>>> >    at
>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>>> /EventDispatchThread.java:113)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:109)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:101)
>>> >    at java.awt.EventDispatchThread.run(java.desktop at 11
>>> /EventDispatchThread.java:90)
>>> >
>>> > "NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
>>> > elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
>>> > [0x00007f9420dac000]
>>> >   java.lang.Thread.State: WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd519d48> (a
>>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>>> /LockSupport.java:194)
>>> >    at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>>> /AbstractQueuedSynchronizer.java:2081)
>>> >    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11
>>> /LinkedBlockingQueue.java:433)
>>> >    at
>>> net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11
>>> /SecurityDialogMessageHandler.java:93)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
>>> > elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
>>> > [0x00007f9420865000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
>>> > tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
>>> > [0x00007f942011e000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <no object reference available>
>>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>>> /EventQueue.java:1361)
>>> >    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
>>> > java.awt.EventQueue$1AWTInvocationLock)
>>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>>> /EventQueue.java:1342)
>>> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
>>> /SwingUtilities.java:1480)
>>> >    at
>>> net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11
>>> /DefaultDownloadIndicator.java:146)
>>> >    at
>>> net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11
>>> /CacheUtil.java:569)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11
>>> /JNLPClassLoader.java:1498)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11
>>> /JNLPClassLoader.java:712)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
>>> /JNLPClassLoader.java:338)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>>> /JNLPClassLoader.java:500)
>>> >    - locked <0x00000000cd98b9d8> (a
>>> java.util.concurrent.locks.ReentrantLock)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>>> /JNLPClassLoader.java:545)
>>> >    - locked <0x00000000cd98b9d8> (a
>>> java.util.concurrent.locks.ReentrantLock)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11
>>> /JNLPClassLoader.java:578)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11
>>> /JNLPClassLoader.java:336)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11
>>> /JNLPClassLoader.java:421)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>>> /JNLPClassLoader.java:495)
>>> >    - locked <0x00000000cd98b9d8> (a
>>> java.util.concurrent.locks.ReentrantLock)
>>> >    at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11
>>> /JNLPClassLoader.java:468)
>>> >    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11
>>> /Launcher.java:815)
>>> >    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11
>>> /Launcher.java:529)
>>> >    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11
>>> /Launcher.java:947)
>>> >
>>> > "AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
>>> > tid=0x00007f942c075000 nid=0x1608 waiting on condition
>>> > [0x00007f940bbf7000]
>>> >   java.lang.Thread.State: WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd9a80a8> (a
>>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>>> /LockSupport.java:194)
>>> >    at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>>> /AbstractQueuedSynchronizer.java:2081)
>>> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11
>>> /EventQueue.java:620)
>>> >    at
>>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>>> /EventDispatchThread.java:190)
>>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>>> /EventDispatchThread.java:124)
>>> >    at
>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>>> /EventDispatchThread.java:113)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:109)
>>> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
>>> /SequencedEvent.java:138)
>>> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
>>> /EventQueue.java:770)
>>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>>> Method)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:85)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:95)
>>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>>> Method)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:85)
>>> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
>>> /EventQueue.java:742)
>>> >    at
>>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>>> /EventDispatchThread.java:203)
>>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>>> /EventDispatchThread.java:124)
>>> >    at
>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>>> /EventDispatchThread.java:113)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:109)
>>> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11
>>> /SequencedEvent.java:138)
>>> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11
>>> /EventQueue.java:770)
>>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
>>> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
>>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>>> Method)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:85)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:95)
>>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
>>> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
>>> >    at java.security.AccessController.doPrivileged(java.base at 11/Native
>>> Method)
>>> >    at
>>> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11
>>> /ProtectionDomain.java:85)
>>> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11
>>> /EventQueue.java:742)
>>> >    at
>>> java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11
>>> /EventDispatchThread.java:203)
>>> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11
>>> /EventDispatchThread.java:124)
>>> >    at
>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11
>>> /EventDispatchThread.java:113)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:109)
>>> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11
>>> /EventDispatchThread.java:101)
>>> >    at java.awt.EventDispatchThread.run(java.desktop at 11
>>> /EventDispatchThread.java:90)
>>> >
>>> > "Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
>>> > tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
>>> > [0x00007f940bafd000]
>>> >   java.lang.Thread.State: BLOCKED (on object monitor)
>>> >    at
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
>>> /BasePainter.java:565)
>>> >    - waiting to lock <0x00000000cd9a85d8> (a
>>> >
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>>> >    at java.util.Observable.notifyObservers(java.base at 11
>>> /Observable.java:173)
>>> >    at java.util.Observable.notifyObservers(java.base at 11
>>> /Observable.java:129)
>>> >    at
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11
>>> /BasePainter.java:419)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
>>> > tid=0x00007f9428024000 nid=0x160a in Object.wait()
>>> > [0x00007f940b9fc000]
>>> >   java.lang.Thread.State: WAITING (on object monitor)
>>> >    at java.lang.Object.wait(java.base at 11/Native Method)
>>> >    - waiting on <no object reference available>
>>> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
>>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>>> /EventQueue.java:1361)
>>> >    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
>>> > java.awt.EventQueue$1AWTInvocationLock)
>>> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11
>>> /EventQueue.java:1342)
>>> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11
>>> /SwingUtilities.java:1480)
>>> >    at
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11
>>> /BasePainter.java:579)
>>> >    - locked <0x00000000cd9a85d8> (a
>>> >
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
>>> >    at java.util.Observable.notifyObservers(java.base at 11
>>> /Observable.java:173)
>>> >    at java.util.Observable.notifyObservers(java.base at 11
>>> /Observable.java:129)
>>> >    at
>>> net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11
>>> /BasePainter.java:452)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
>>> > elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
>>> > [0x00007f940b4e7000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
>>> > tid=0x00007f942c15b000 nid=0x1613 waiting on condition
>>> > [0x00007f940b5fa000]
>>> >   java.lang.Thread.State: WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cf319e08> (a
>>> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11
>>> /LockSupport.java:194)
>>> >    at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11
>>> /AbstractQueuedSynchronizer.java:2081)
>>> >    at java.util.concurrent.DelayQueue.take(java.base at 11
>>> /DelayQueue.java:217)
>>> >    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
>>> > elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
>>> > [0x00007f9407bfa000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
>>> > elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
>>> > [0x00007f9407cfb000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
>>> > elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
>>> > [0x00007f9407af9000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
>>> > elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
>>> > [0x00007f94079f8000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
>>> > elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
>>> > [0x00007f94078f7000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
>>> > elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
>>> > [0x00007f94077f6000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
>>> > elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
>>> > [0x00007f94074f3000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
>>> > elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
>>> > [0x00007f94073f2000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
>>> > elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
>>> > [0x00007f94072f1000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
>>> > elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
>>> > [0x00007f94071f0000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
>>> > elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
>>> > [0x00007f94070ef000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
>>> > elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
>>> > [0x00007f9406fee000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
>>> > elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
>>> > [0x00007f9406eed000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
>>> > elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
>>> > [0x00007f94076f5000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
>>> > elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
>>> > [0x00007f9406dec000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
>>> > elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
>>> > [0x00007f94075f4000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
>>> > elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
>>> > [0x00007f9406ceb000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
>>> > elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
>>> > [0x00007f94069e8000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
>>> > elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
>>> > [0x00007f9406bea000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
>>> > elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
>>> > [0x00007f9406ae9000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
>>> > elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
>>> > [0x00007f94061e0000]
>>> >   java.lang.Thread.State: TIMED_WAITING (parking)
>>> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
>>> >    - parking to wait for  <0x00000000cd726dc0> (a
>>> > java.util.concurrent.SynchronousQueue$TransferStack)
>>> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11
>>> /LockSupport.java:234)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11
>>> /SynchronousQueue.java:462)
>>> >    at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11
>>> /SynchronousQueue.java:361)
>>> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11
>>> /SynchronousQueue.java:937)
>>> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11
>>> /ThreadPoolExecutor.java:1053)
>>> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11
>>> /ThreadPoolExecutor.java:1114)
>>> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11
>>> /ThreadPoolExecutor.java:628)
>>> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
>>> >
>>> > "VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
>>> > tid=0x00007f94b019b800 nid=0x15e7 runnable
>>> >
>>> > "GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
>>> > tid=0x00007f94b0040000 nid=0x15e2 runnable
>>> >
>>> > "GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
>>> > tid=0x00007f9480001000 nid=0x15fb runnable
>>> >
>>> > "GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
>>> > tid=0x00007f9480002800 nid=0x15fc runnable
>>> >
>>> > "GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
>>> > tid=0x00007f9480004000 nid=0x15fd runnable
>>> >
>>> > "G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
>>> > tid=0x00007f94b005b800 nid=0x15e3 runnable
>>> >
>>> > "G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
>>> > tid=0x00007f94b005d800 nid=0x15e4 runnable
>>> >
>>> > "G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
>>> > tid=0x00007f94b013a800 nid=0x15e5 runnable
>>> >
>>> > "G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
>>> > tid=0x00007f9488001000 nid=0x15fe runnable
>>> >
>>> > "G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
>>> > tid=0x00007f94b013c800 nid=0x15e6 runnable
>>> > "VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
>>> > tid=0x00007f94b02db000 nid=0x15f1 waiting on condition
>>> >
>>> > JNI global refs: 88, weak refs: 487
>>> >
>>> > Heap
>>> > garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
>>> > 0x0000000100000000)
>>> >  region size 1024K, 99 young (101376K), 5 survivors (5120K)
>>> > Metaspace       used 32074K, capacity 32873K, committed 33280K,
>>> > reserved 1079296K
>>> >  class space    used 3388K, capacity 3743K, committed 3840K, reserved
>>> 1048576K
>>>
>>>
>>
>> --
>> --
>> Laurent Bourg?s
>>
>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/1a13a409/attachment-0001.html>

From kevin.rushforth at oracle.com  Wed Sep  5 16:59:19 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 5 Sep 2018 09:59:19 -0700
Subject: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional
 support for GTK 3 on Linux
In-Reply-To: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
Message-ID: <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>

The backport of the following fix, which removes sun.misc.GThreadHelper, 
will break all FX interop applications, even if GTK2 is used:

https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire 
sun.misc.GThreadHelper

The FX GTK port still uses that class, so the class needs to be left in 
until after the FX support for GTK 3 has been backported.

-- Kevin



On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the patch for 8u-dev backport for JDK-8145547. It adds 
> conditional support for gtk3.
>
> The original fix does not apply cleanly as few changes were done? in 
> jdk9 before the gtk3 support was added, major once being JDK-8025815 
> <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212 
> <https://bugs.openjdk.java.net/browse/JDK-8014212> and JDK-8137571 
> <https://bugs.openjdk.java.net/browse/JDK-8137571>
>
> Along with the enhancement, following bug fixes have also been 
> included in the backport webrev
>
> 1.https://bugs.openjdk.java.net/browse/JDK-8155772: gtk3_interface.c 
> compilation error on Ubuntu 12.10
>
> 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 breaks AIX 
> and and uses RTLD_NOLOAD incorrectly
>
> 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward" 
> fails for GTK3 if no GTK2 available
>
> 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for 
> [AWT/Swing] Conditional support for GTK 3 on Linux
>
> 5.https://bugs.openjdk.java.net/browse/JDK-8157827: 
> AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK version 
> when jdk.gtk.version=3
>
> 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu displayed 
> nothing with the option"-server -d64 -Xmixed 
> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>
> 7.https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable 
> Rendering of Disabled Text in Swing GTK L&F
>
> 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several FileDialog 
> Modality Tests fail on Linux due to X errors
>
> 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure on 
> Linux arm64
>
> 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire 
> sun.misc.GThreadHelper
>
> 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree Collapse 
> Buttons Clipped Off Under GTK
>
> 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 menus 
> appearence similar to native.
>
> 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash in 
> AWT_Desktop/Automated/Exceptions/BasicTest
>
> 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The FileChooser 
> didn't displayed large font with GTK LAF option.
>
> 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of 
> SwingNode with GTK LaF
>
> 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait] Memory 
> leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of awt_UNIXToolkit.c:132
>
> 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris build 
> failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>
> webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>
> JDK 9 Changeset: 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>
> I have run the related jtreg and jck tests and results are fine.
>
> Regards,
>
> Pankaj
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/f5728e11/attachment.html>

From erik.joelsson at oracle.com  Wed Sep  5 17:01:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Sep 2018 10:01:36 -0700
Subject: <AWT Dev> RFR: JDK-8056217 Remove awt_makecube.cpp
In-Reply-To: <c505107f-beb4-6b6a-c441-cd80539538ce@oracle.com>
References: <c505107f-beb4-6b6a-c441-cd80539538ce@oracle.com>
Message-ID: <2978bcaa-d43e-f385-6069-c3c18fe901fb@oracle.com>

Looks good to me.

/Erik


On 2018-09-05 05:19, Magnus Ihse Bursie wrote:
> As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
> is not compiler nor used) should be removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056217
>
> Change:
> $ hg status
> R src/java.desktop/windows/native/common/awt_makecube.cpp
>
> /Magnus
>


From pankaj.b.bansal at oracle.com  Wed Sep  5 18:44:53 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 5 Sep 2018 11:44:53 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional
 support for GTK 3 on Linux
In-Reply-To: <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
Message-ID: <7f658900-c5d7-4426-a64d-b9eb228120ad@default>

Hello Kevin,

 

Thanks for pointing it out. I will remove this fix for now. I hope its ok, if I create new webrev when I get some more comments here.

 

Regards,

Pankaj Bansal

 

From: Kevin Rushforth 
Sent: Wednesday, September 5, 2018 10:29 PM
To: Pankaj Bansal; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

 

The backport of the following fix, which removes sun.misc.GThreadHelper, will break all FX interop applications, even if GTK2 is used:

https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper

The FX GTK port still uses that class, so the class needs to be left in until after the FX support for GTK 3 has been backported.

-- Kevin




On 9/5/2018 12:56 AM, Pankaj Bansal wrote:

Hi All,

 

Please review the patch for 8u-dev backport for JDK-8145547. It adds conditional support for gtk3. 

The original fix does not apply cleanly as few changes were done  in jdk9 before the gtk3 support was added, major once being HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8025815"JDK-8025815, HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8014212"JDK-8014212 and HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8137571"JDK-8137571 

 

Along with the enhancement, following bug fixes have also been included in the backport webrev

 

1.      https://bugs.openjdk.java.net/browse/JDK-8155772: gtk3_interface.c compilation error on Ubuntu 12.10

2.      https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 breaks AIX and and uses RTLD_NOLOAD incorrectly

3.      https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward" fails for GTK3 if no GTK2 available

4.      https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for [AWT/Swing] Conditional support for GTK 3 on Linux 

5.      https://bugs.openjdk.java.net/browse/JDK-8157827: AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK version when jdk.gtk.version=3

6.      https://bugs.openjdk.java.net/browse/JDK-8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".

7.      https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable Rendering of Disabled Text in Swing GTK L&F

8.      https://bugs.openjdk.java.net/browse/JDK-8203003: Several FileDialog Modality Tests fail on Linux due to X errors

9.      https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure on Linux arm64

10.   https://bugs.openjdk.java.net/browse/JDK-8154546: Retire sun.misc.GThreadHelper

11.   https://bugs.openjdk.java.net/browse/JDK-8152968: JTree Collapse Buttons Clipped Off Under GTK

12.   https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 menus appearence similar to native.

13.   https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash in AWT_Desktop/Automated/Exceptions/BasicTest

14.   https://bugs.openjdk.java.net/browse/JDK-8160054: The FileChooser didn't displayed large font with GTK LAF option.

15.   https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of SwingNode with GTK LaF

16.   https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait] Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of awt_UNIXToolkit.c:132

17.   https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris build failed: gtk2_interface.h typedef redeclared: GThreadFunctions

 

 

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/"http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8145547

JDK 9 Changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8

I have run the related jtreg and jck tests and results are fine.

 

Regards,

Pankaj

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180905/7554b1ae/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Wed Sep  5 21:26:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Sep 2018 14:26:33 -0700
Subject: <AWT Dev> RFR: JDK-8056217 Remove awt_makecube.cpp
In-Reply-To: <c505107f-beb4-6b6a-c441-cd80539538ce@oracle.com>
References: <c505107f-beb4-6b6a-c441-cd80539538ce@oracle.com>
Message-ID: <4f4854ab-cfa3-35ea-d785-9318f8d83e80@oracle.com>

looks fine.

On 05/09/2018 05:19, Magnus Ihse Bursie wrote:
> As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
> is not compiler nor used) should be removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056217
> 
> Change:
> $ hg status
> R src/java.desktop/windows/native/common/awt_makecube.cpp
> 
> /Magnus
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Sep  5 21:35:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Sep 2018 14:35:43 -0700
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
Message-ID: <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>

HI, Pankaj.
Can you please recheck that FX<-->Swing interop still works? Probably 
there are some other than GThreadHelper issues

On 05/09/2018 11:44, Pankaj Bansal wrote:
> Hello Kevin,
> 
> Thanks for pointing it out. I will remove this fix for now. I hope its 
> ok, if I create new webrev when I get some more comments here.
> 
> Regards,
> 
> Pankaj Bansal
> 
> *From:*Kevin Rushforth
> *Sent:* Wednesday, September 5, 2018 10:29 PM
> *To:* Pankaj Bansal; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] 
> Conditional support for GTK 3 on Linux
> 
> The backport of the following fix, which removes sun.misc.GThreadHelper, 
> will break all FX interop applications, even if GTK2 is used:
> 
> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire 
> sun.misc.GThreadHelper
> 
> The FX GTK port still uses that class, so the class needs to be left in 
> until after the FX support for GTK 3 has been backported.
> 
> -- Kevin
> 
> 
> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
> 
>     Hi All,
> 
>     Please review the patch for 8u-dev backport for JDK-8145547. It adds
>     conditional support for gtk3.
> 
>     The original fix does not apply cleanly as few changes were done? in
>     jdk9 before the gtk3 support was added, major once being JDK-8025815
>     <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>     <https://bugs.openjdk.java.net/browse/JDK-8014212> and JDK-8137571
>     <https://bugs.openjdk.java.net/browse/JDK-8137571>
> 
>     Along with the enhancement, following bug fixes have also been
>     included in the backport webrev
> 
>     1.https://bugs.openjdk.java.net/browse/JDK-8155772: gtk3_interface.c
>     compilation error on Ubuntu 12.10
> 
>     2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 breaks
>     AIX and and uses RTLD_NOLOAD incorrectly
> 
>     3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>     fails for GTK3 if no GTK2 available
> 
>     4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>     [AWT/Swing] Conditional support for GTK 3 on Linux
> 
>     5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>     AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>     version when jdk.gtk.version=3
> 
>     6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>     displayed nothing with the option"-server -d64 -Xmixed
>     -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
> 
>     7.https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable
>     Rendering of Disabled Text in Swing GTK L&F
> 
>     8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>     FileDialog Modality Tests fail on Linux due to X errors
> 
>     9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure on
>     Linux arm64
> 
>     10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>     sun.misc.GThreadHelper
> 
>     11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree Collapse
>     Buttons Clipped Off Under GTK
> 
>     12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 menus
>     appearence similar to native.
> 
>     13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash in
>     AWT_Desktop/Automated/Exceptions/BasicTest
> 
>     14.https://bugs.openjdk.java.net/browse/JDK-8160054: The FileChooser
>     didn't displayed large font with GTK LAF option.
> 
>     15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>     SwingNode with GTK LaF
> 
>     16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>     Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>     awt_UNIXToolkit.c:132
> 
>     17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris build
>     failed: gtk2_interface.h typedef redeclared: GThreadFunctions
> 
>     webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>     <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
> 
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
> 
>     JDK 9 Changeset:
>     http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
> 
>     I have run the related jtreg and jck tests and results are fine.
> 
>     Regards,
> 
>     Pankaj
> 


-- 
Best regards, Sergey.

From kevin.rushforth at oracle.com  Wed Sep  5 21:59:28 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 5 Sep 2018 14:59:28 -0700
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
 <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
Message-ID: <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>

The simple testing that I did -- one each of a Swing app + JFXPanel and 
a JavaFX app + SwingNode -- worked for me on my local build after 
restoring that file. Some additional testing (necessarily limited to GTK 
2 until the FX backport for GTK 3 is done) might be needed.

-- Kevin


On 9/5/2018 2:35 PM, Sergey Bylokhov wrote:
> HI, Pankaj.
> Can you please recheck that FX<-->Swing interop still works? Probably 
> there are some other than GThreadHelper issues
>
> On 05/09/2018 11:44, Pankaj Bansal wrote:
>> Hello Kevin,
>>
>> Thanks for pointing it out. I will remove this fix for now. I hope 
>> its ok, if I create new webrev when I get some more comments here.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>> *From:*Kevin Rushforth
>> *Sent:* Wednesday, September 5, 2018 10:29 PM
>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] 
>> Conditional support for GTK 3 on Linux
>>
>> The backport of the following fix, which removes 
>> sun.misc.GThreadHelper, will break all FX interop applications, even 
>> if GTK2 is used:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire 
>> sun.misc.GThreadHelper
>>
>> The FX GTK port still uses that class, so the class needs to be left 
>> in until after the FX support for GTK 3 has been backported.
>>
>> -- Kevin
>>
>>
>> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>>
>> ??? Hi All,
>>
>> ??? Please review the patch for 8u-dev backport for JDK-8145547. It adds
>> ??? conditional support for gtk3.
>>
>> ??? The original fix does not apply cleanly as few changes were done? in
>> ??? jdk9 before the gtk3 support was added, major once being JDK-8025815
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8014212> and JDK-8137571
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8137571>
>>
>> ??? Along with the enhancement, following bug fixes have also been
>> ??? included in the backport webrev
>>
>> ??? 1.https://bugs.openjdk.java.net/browse/JDK-8155772: gtk3_interface.c
>> ??? compilation error on Ubuntu 12.10
>>
>> ??? 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 breaks
>> ??? AIX and and uses RTLD_NOLOAD incorrectly
>>
>> ??? 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>> ??? fails for GTK3 if no GTK2 available
>>
>> ??? 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>> ??? [AWT/Swing] Conditional support for GTK 3 on Linux
>>
>> ??? 5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>> ??? AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>> ??? version when jdk.gtk.version=3
>>
>> ??? 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>> ??? displayed nothing with the option"-server -d64 -Xmixed
>> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>>
>> ??? 7.https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable
>> ??? Rendering of Disabled Text in Swing GTK L&F
>>
>> ??? 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>> ??? FileDialog Modality Tests fail on Linux due to X errors
>>
>> ??? 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure on
>> ??? Linux arm64
>>
>> ??? 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>> ??? sun.misc.GThreadHelper
>>
>> ??? 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree Collapse
>> ??? Buttons Clipped Off Under GTK
>>
>> ??? 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 menus
>> ??? appearence similar to native.
>>
>> ??? 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash in
>> ??? AWT_Desktop/Automated/Exceptions/BasicTest
>>
>> ??? 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The FileChooser
>> ??? didn't displayed large font with GTK LAF option.
>>
>> ??? 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>> ??? SwingNode with GTK LaF
>>
>> ??? 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>> ??? Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>> ??? awt_UNIXToolkit.c:132
>>
>> ??? 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris build
>> ??? failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>>
>> ??? webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>>
>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>>
>> ??? JDK 9 Changeset:
>> ??? http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>>
>> ??? I have run the related jtreg and jck tests and results are fine.
>>
>> ??? Regards,
>>
>> ??? Pankaj
>>
>
>


From pankaj.b.bansal at oracle.com  Thu Sep  6 11:35:31 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 6 Sep 2018 04:35:31 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
 <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
 <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>
Message-ID: <e87d0b73-693c-40fa-af44-1529dd9343d4@default>

Hello Sergey/Kevin,

I have removed the backport for https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper. I did a clean build and tried few tests for Swing-FX interop. They all run fine. I have attached the link to tests if you would like to have a look. I did run the awt and swing jtreg tests also. 

Webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.01/
SwingFXInteropTests:  http://cr.openjdk.java.net/~pbansal/gtk3_backport/SwingFXInteropTests/

Please let me know if you would like me to do some further testing for Swing-FX interop.

Regards,
Pankaj Bansal

-----Original Message-----
From: Kevin Rushforth 
Sent: Thursday, September 6, 2018 3:29 AM
To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

The simple testing that I did -- one each of a Swing app + JFXPanel and a JavaFX app + SwingNode -- worked for me on my local build after restoring that file. Some additional testing (necessarily limited to GTK
2 until the FX backport for GTK 3 is done) might be needed.

-- Kevin


On 9/5/2018 2:35 PM, Sergey Bylokhov wrote:
> HI, Pankaj.
> Can you please recheck that FX<-->Swing interop still works? Probably 
> there are some other than GThreadHelper issues
>
> On 05/09/2018 11:44, Pankaj Bansal wrote:
>> Hello Kevin,
>>
>> Thanks for pointing it out. I will remove this fix for now. I hope 
>> its ok, if I create new webrev when I get some more comments here.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>> *From:*Kevin Rushforth
>> *Sent:* Wednesday, September 5, 2018 10:29 PM
>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] 
>> Conditional support for GTK 3 on Linux
>>
>> The backport of the following fix, which removes 
>> sun.misc.GThreadHelper, will break all FX interop applications, even 
>> if GTK2 is used:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire 
>> sun.misc.GThreadHelper
>>
>> The FX GTK port still uses that class, so the class needs to be left 
>> in until after the FX support for GTK 3 has been backported.
>>
>> -- Kevin
>>
>>
>> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>>
>> ??? Hi All,
>>
>> ??? Please review the patch for 8u-dev backport for JDK-8145547. It 
>> adds
>> ??? conditional support for gtk3.
>>
>> ??? The original fix does not apply cleanly as few changes were done? 
>> in
>> ??? jdk9 before the gtk3 support was added, major once being 
>> JDK-8025815
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8014212> and 
>> JDK-8137571
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8137571>
>>
>> ??? Along with the enhancement, following bug fixes have also been
>> ??? included in the backport webrev
>>
>> ??? 1.https://bugs.openjdk.java.net/browse/JDK-8155772: 
>> gtk3_interface.c
>> ??? compilation error on Ubuntu 12.10
>>
>> ??? 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 
>> breaks
>> ??? AIX and and uses RTLD_NOLOAD incorrectly
>>
>> ??? 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>> ??? fails for GTK3 if no GTK2 available
>>
>> ??? 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>> ??? [AWT/Swing] Conditional support for GTK 3 on Linux
>>
>> ??? 5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>> ??? AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>> ??? version when jdk.gtk.version=3
>>
>> ??? 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>> ??? displayed nothing with the option"-server -d64 -Xmixed 
>> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>>
>> ??? 7.https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable
>> ??? Rendering of Disabled Text in Swing GTK L&F
>>
>> ??? 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>> ??? FileDialog Modality Tests fail on Linux due to X errors
>>
>> ??? 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure 
>> on
>> ??? Linux arm64
>>
>> ??? 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>> ??? sun.misc.GThreadHelper
>>
>> ??? 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree 
>> Collapse
>> ??? Buttons Clipped Off Under GTK
>>
>> ??? 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 
>> menus
>> ??? appearence similar to native.
>>
>> ??? 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash 
>> in
>> ??? AWT_Desktop/Automated/Exceptions/BasicTest
>>
>> ??? 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The 
>> FileChooser
>> ??? didn't displayed large font with GTK LAF option.
>>
>> ??? 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>> ??? SwingNode with GTK LaF
>>
>> ??? 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>> ??? Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>> ??? awt_UNIXToolkit.c:132
>>
>> ??? 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris 
>> build
>> ??? failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>>
>> ??? webrev: 
>> http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>>
>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>>
>> ??? JDK 9 Changeset:
>> ??? http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>>
>> ??? I have run the related jtreg and jck tests and results are fine.
>>
>> ??? Regards,
>>
>> ??? Pankaj
>>
>
>


From krishna.addepalli at oracle.com  Thu Sep  6 14:08:17 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 6 Sep 2018 19:38:17 +0530
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <CAKjRUT7z6EH657tkhLMBfagC_z2EfyALnc1FLZHkUOD_WU8pog@mail.gmail.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
 <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
 <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>
 <CAKjRUT7t7D2txuDC6Lh9G5YXqKp=-ufZ4RP4AE9YduaPNRtPZw@mail.gmail.com>
 <CAKjRUT7z6EH657tkhLMBfagC_z2EfyALnc1FLZHkUOD_WU8pog@mail.gmail.com>
Message-ID: <A191B547-5C02-482E-B53E-CBC41097393E@oracle.com>

Hi Laurent,

Thanks for providing the test case. I was able to reproduce the issue. Glad to know that you found a workaround, as this issue is a bit tricky to fix.
Meanwhile, I?m looking into fixing this issue, and your test case greatly helps me toward finding the fix faster.

Krishna

> On 05-Sep-2018, at 8:29 PM, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
> 
> Hi again,
> 
> FYI Today I managed fixing the AWT deadlock by using the forementioned workaround:
> - use a specific thread pool within the Main thread group (not JNLP's AppContext) to relay the EDT invocations (invokeLater / invokeAndWait) as I figured out that SplashScreen & DownloadIndicator dialogs were using the JNLP AppContext
> => 2 concurrent AppContexts were used and 2 event dispatcher threads led to deadlocks in AWT SequencedEvent processing (Window Gain / Lost focus).
> 
> With that workaround, all EDT actions from ITW are delivered via the Main AppContext and it works well now : no more AWT hanging !
> 
> Laurent
> 
> Le mer. 5 sept. 2018 ? 08:45, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> a ?crit :
> Hi,
> Should we submit a new bug or complete the opened bug with this reproducer ?
> 
> It is quite critical for OpenJDK 11 adoption as I expect linux distributions at least will provide icedtea-web for javaws support, even for 11+.
> 
> I will try implementing a workaround redirecting EDT using a single AppContext... to reduce the opportunity to have deadlock = only 1 EDT used at the same time.
> 
> Regards,
> Laurent
> 
> Le mar. 4 sept. 2018 ? 22:11, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> a ?crit :
> Hi Krishna,
> 
> Thanks for your answers, I managed writing a simple reproducer, see below.
> I inspected heap dumps on jvisualvm but it looks like the First SequencedEvent is not consumed and is blocking the queue for ever. 
> 
> On JDK8 or JDK10: it works (windows are animated and not hanging).
> On JDK11: it starts but is immediately frozen !
> 
> Could you have a look ?
> 
> ----
> import java.awt.AWTEvent;
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import java.awt.Toolkit;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.awt.event.WindowEvent;
> import java.lang.reflect.Constructor;
> import javax.swing.JButton;
> 
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.SwingUtilities;
> import javax.swing.Timer;
> import sun.awt.AppContext;
> import sun.awt.SunToolkit;
> 
> /*
>  * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
>  * @author Laurent Bourges
>  */
> public class TestWinEvent extends JFrame implements ActionListener {
> 
>     private static final long serialVersionUID = 1L;
> 
>     private int counter = 0;
>     private JButton btn;
> 
>     public static void main(String[] args) {
>         createWin(1);
>         createWin(2);
>     }
> 
>     private static void createWin(int tgNum) {
>         ThreadGroup tg = new ThreadGroup("TG " + tgNum);
> 
>         Thread t = new Thread(tg, new Runnable() {
>             public void run() {
>                 AppContext context = SunToolkit.createNewAppContext();
> 
>                 SwingUtilities.invokeLater(new Runnable() {
>                     public void run() {
>                         final TestWinEvent window = new TestWinEvent(tgNum);
>                         window.setVisible(true);
> 
>                         new Timer(10, window).start();
>                     }
>                 });
>             }
>         });
>         t.start();
>     }
> 
>     public TestWinEvent(final int num) {
>         super("Test Window + " + num);
>         setMinimumSize(new Dimension(300, 200));
>         setLocation(100 + 400 * (num - 1), 100);
> 
>         setLayout(new BorderLayout());
>         JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
>         add(textBlock);
> 
>         btn = new JButton("TEST");
>         btn.addActionListener(new ActionListener() {
>             @Override
>             public void actionPerformed(ActionEvent e) {
>                 System.out.println("Button#" + num + " clicked: " + counter);
>             }
> 
>         });
>         add(btn, BorderLayout.SOUTH);
> 
>         setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>         pack();
>     }
> 
>     @Override
>     public void actionPerformed(ActionEvent e) {
>         AWTEvent eventOne = getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
>         AWTEvent eventTwo = getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
> 
>         btn.setText("TEST " + (counter++));
> 
>         Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
>         Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
>     }
> 
>     private AWTEvent getSequencedEvent(int id) {
>         AWTEvent wrapMe = new WindowEvent(this, id);
>         try {
>             @SuppressWarnings("unchecked")
>             Class<? extends AWTEvent> seqClass = (Class<? extends AWTEvent>) Class.forName("java.awt.SequencedEvent");
>             Constructor<? extends AWTEvent> seqConst = seqClass.getConstructor(AWTEvent.class);
>             seqConst.setAccessible(true);
>             AWTEvent instance = seqConst.newInstance(wrapMe);
>             return instance;
>         } catch (Throwable err) {
>             throw new Error("Unable to instantiate SequencedEvent", err);
>         }
>     }
> }
> ------
> 
> Regards,
> Laurent
> 
> Le mar. 4 sept. 2018 ? 15:59, Krishna Addepalli <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>> a ?crit :
> Hi Laurent,
> 
> Thanks for bringing this up. I have fixed a problem in this area JDK-8152974, which is about AWT hang when SequencedEvents arrive out of order.
> However, the fix was partial, and same problem was reported in JDK8(because of webstart), after it was backported. At that point, the fix was reverted in JDK8, and since we couldn?t find a scenario in JDK11 (since webstart is deprecated). It would be helpful if you could provide smallest possible test case / sequence of steps to reproduce the problem.
> 
> Thanks,
> Krishna
> 
> > On 04-Sep-2018, at 6:26 PM, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
> > 
> > Phil & Sergey,
> > 
> > I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
> > times the GUI hanging with AWT-EventQueue threads in the WAITING state
> > (SequencedEvent) at EventQueue.getNextEvent().
> > 
> > I fixed the netx code (EDT violations in swing code) but the problem
> > is still happening randomly. This JavaWS implementation displays
> > several JDialogs: Splash screen + download dialogs + Security prompts.
> > When the application is hanging, I can not click on the Proceed/Cancel
> > buttons of the Security dialogs and it is blocked forever.
> > 
> > Are you aware about this problem ?
> > 
> > As I can reproduce the problem, I can provide a heap-dump if you need.
> > 
> > Here is a complete thread dump:
> > 
> > Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
> > 
> > Threads class SMR info:
> > _java_thread_list=0x00007f94500170a0, length=44, elements={
> > 0x00007f94b0013800, 0x00007f94b01a3800, 0x00007f94b01a7800, 0x00007f94b01ba800,
> > 0x00007f94b01bc800, 0x00007f94b01be800, 0x00007f94b01c0800, 0x00007f94b01ff800,
> > 0x00007f94b02d8800, 0x00007f94b0462000, 0x00007f94b0467800, 0x00007f94b046b000,
> > 0x00007f94b04d7800, 0x00007f9434004000, 0x00007f943400e000, 0x00007f94b0aa8800,
> > 0x00007f94b0b2b000, 0x00007f94b0b43800, 0x00007f942c075000, 0x00007f9428017800,
> > 0x00007f9428024000, 0x00007f942c078000, 0x00007f942c15b000, 0x00007f942c1d0000,
> > 0x00007f942c1ce800, 0x00007f942c195800, 0x00007f942c191000, 0x00007f942c192000,
> > 0x00007f942c193000, 0x00007f942c1c7800, 0x00007f942c1c9000, 0x00007f942c1ca800,
> > 0x00007f942c1cc800, 0x00007f942c166800, 0x00007f942c168000, 0x00007f942c16a000,
> > 0x00007f942c16c000, 0x00007f942c16d800, 0x00007f942c16e800, 0x00007f942c16f800,
> > 0x00007f942c170800, 0x00007f942c1d8000, 0x00007f942c1d2000, 0x00007f942c1d3800
> > }
> > 
> > "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
> > tid=0x00007f94b0013800 nid=0x15e1 in Object.wait()
> > [0x00007f94b9bee000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000cd9c0c78> (a net.sourceforge.jnlp.Launcher$TgThread)
> >    at java.lang.Thread.join(java.base at 11/Thread.java:1305)
> >    - waiting to re-lock in wait() <0x00000000cd9c0c78> (a
> > net.sourceforge.jnlp.Launcher$TgThread)
> >    at java.lang.Thread.join(java.base at 11/Thread.java:1379)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:258)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:208)
> >    at net.sourceforge.jnlp.Launcher.launch(java.desktop at 11/Launcher.java:287)
> >    at net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop at 11/JnlpBoot.java:67)
> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:270)
> >    at net.sourceforge.jnlp.runtime.Boot.run(java.desktop at 11/Boot.java:65)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
> >    at net.sourceforge.jnlp.runtime.Boot.main(java.desktop at 11/Boot.java:210)
> > 
> > "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
> > elapsed=28,24s tid=0x00007f94b01a3800 nid=0x15e8 waiting on condition
> > [0x00007f9490efc000]
> >   java.lang.Thread.State: RUNNABLE
> >    at java.lang.ref.Reference.waitForReferencePendingList(java.base at 11/Native
> > Method)
> >    at java.lang.ref.Reference.processPendingReferences(java.base at 11/Reference.java:241)
> >    at java.lang.ref.Reference$ReferenceHandler.run(java.base at 11/Reference.java:213)
> > 
> > "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
> > tid=0x00007f94b01a7800 nid=0x15e9 in Object.wait()
> > [0x00007f9490dfb000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f16d0> (a java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f16d0> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
> >    at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 11/Finalizer.java:170)
> > 
> > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
> > elapsed=28,23s tid=0x00007f94b01ba800 nid=0x15ea waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> > 
> > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
> > elapsed=28,23s tid=0x00007f94b01bc800 nid=0x15eb waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >   No compile task
> > 
> > "C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
> > elapsed=28,23s tid=0x00007f94b01be800 nid=0x15ec waiting on condition
> > [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> >   No compile task
> > 
> > "Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
> > tid=0x00007f94b01c0800 nid=0x15ed runnable  [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> > 
> > "Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
> > tid=0x00007f94b01ff800 nid=0x15ee in Object.wait()
> > [0x00007f94904e3000]
> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f2140> (a java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f2140> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at jdk.internal.ref.CleanerImpl.run(java.base at 11/CleanerImpl.java:148)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> >    at jdk.internal.misc.InnocuousThread.run(java.base at 11/InnocuousThread.java:134)
> > 
> > "Service Thread" #10 daemon prio=9 os_prio=0 cpu=0,04ms elapsed=28,15s
> > tid=0x00007f94b02d8800 nid=0x15f0 runnable  [0x0000000000000000]
> >   java.lang.Thread.State: RUNNABLE
> > 
> > "Java2D Disposer" #12 daemon prio=10 os_prio=0 cpu=0,82ms
> > elapsed=28,03s tid=0x00007f94b0462000 nid=0x15f5 in Object.wait()
> > [0x00007f944ddd7000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <0x00000000c01f2898> (a java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:155)
> >    - waiting to re-lock in wait() <0x00000000c01f2898> (a
> > java.lang.ref.ReferenceQueue$Lock)
> >    at java.lang.ref.ReferenceQueue.remove(java.base at 11/ReferenceQueue.java:176)
> >    at sun.java2d.Disposer.run(java.desktop at 11/Disposer.java:144)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "AWT-XAWT" #13 daemon prio=6 os_prio=0 cpu=122,01ms elapsed=28,03s
> > tid=0x00007f94b0467800 nid=0x15f6 runnable  [0x00007f944dcd6000]
> >   java.lang.Thread.State: RUNNABLE
> >    at sun.awt.X11.XToolkit.waitForEvents(java.desktop at 11/Native Method)
> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:682)
> >    at sun.awt.X11.XToolkit.run(java.desktop at 11/XToolkit.java:646)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "Thread-0" #14 prio=5 os_prio=0 cpu=71,05ms elapsed=28,03s
> > tid=0x00007f94b046b000 nid=0x15f7 waiting on condition
> > [0x00007f944dbd5000]
> >   java.lang.Thread.State: TIMED_WAITING (sleeping)
> >    at java.lang.Thread.sleep(java.base at 11/Native Method)
> >    at net.sourceforge.bourgesl.TracingEventQueue$TracingEventQueueThread.run(java.desktop at 11/TracingEventQueue.java:92)
> > 
> > "Output controller consumer daemon" #15 daemon prio=5 os_prio=0
> > cpu=54,29ms elapsed=27,96s tid=0x00007f94b04d7800 nid=0x15f8 in
> > Object.wait()  [0x00007f944d8d4000]
> >   java.lang.Thread.State: TIMED_WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at net.sourceforge.jnlp.util.logging.OutputController$MessageQueConsumer.run(java.desktop at 11/OutputController.java:122)
> >    - waiting to re-lock in wait() <0x00000000c01f2fc0> (a
> > net.sourceforge.jnlp.util.logging.OutputController)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "AWT-Shutdown" #18 prio=5 os_prio=0 cpu=4,32ms elapsed=27,95s
> > tid=0x00007f9434004000 nid=0x15f9 in Object.wait()
> > [0x00007f944d7d3000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at sun.awt.AWTAutoShutdown.run(java.desktop at 11/AWTAutoShutdown.java:291)
> >    - waiting to re-lock in wait() <0x00000000c01f2fe8> (a java.lang.Object)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "AWT-EventQueue-1" #17 prio=6 os_prio=0 cpu=353,51ms elapsed=27,95s
> > tid=0x00007f943400e000 nid=0x15fa waiting on condition
> > [0x00007f944d6d2000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000c01f3870> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
> >    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:566)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
> >    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)
> > 
> > "NetxSecurityThread" #19 daemon prio=5 os_prio=0 cpu=4,16ms
> > elapsed=27,53s tid=0x00007f94b0aa8800 nid=0x1601 waiting on condition
> > [0x00007f9420dac000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd519d48> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
> >    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
> >    at java.util.concurrent.LinkedBlockingQueue.take(java.base at 11/LinkedBlockingQueue.java:433)
> >    at net.sourceforge.jnlp.security.SecurityDialogMessageHandler.run(java.desktop at 11/SecurityDialogMessageHandler.java:93)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-1" #20 daemon prio=5 os_prio=0 cpu=232,61ms
> > elapsed=27,42s tid=0x00007f94b0b2b000 nid=0x1602 waiting on condition
> > [0x00007f9420865000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "Aspro 2" #25 prio=5 os_prio=0 cpu=127,89ms elapsed=27,08s
> > tid=0x00007f94b0b43800 nid=0x1607 in Object.wait()
> > [0x00007f942011e000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
> >    - waiting to re-lock in wait() <0x00000000cc3c6e80> (a
> > java.awt.EventQueue$1AWTInvocationLock)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
> >    at net.sourceforge.jnlp.cache.DefaultDownloadIndicator.getListener(java.desktop at 11/DefaultDownloadIndicator.java:146)
> >    at net.sourceforge.jnlp.cache.CacheUtil.waitForResources(java.desktop at 11/CacheUtil.java:569)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.waitForJars(java.desktop at 11/JNLPClassLoader.java:1498)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(java.desktop at 11/JNLPClassLoader.java:712)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:338)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:500)
> >    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:545)
> >    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(java.desktop at 11/JNLPClassLoader.java:578)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(java.desktop at 11/JNLPClassLoader.java:336)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(java.desktop at 11/JNLPClassLoader.java:421)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:495)
> >    - locked <0x00000000cd98b9d8> (a java.util.concurrent.locks.ReentrantLock)
> >    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(java.desktop at 11/JNLPClassLoader.java:468)
> >    at net.sourceforge.jnlp.Launcher.createApplication(java.desktop at 11/Launcher.java:815)
> >    at net.sourceforge.jnlp.Launcher.launchApplication(java.desktop at 11/Launcher.java:529)
> >    at net.sourceforge.jnlp.Launcher$TgThread.run(java.desktop at 11/Launcher.java:947)
> > 
> > "AWT-EventQueue-2" #26 prio=6 os_prio=0 cpu=362,81ms elapsed=27,07s
> > tid=0x00007f942c075000 nid=0x1608 waiting on condition
> > [0x00007f940bbf7000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd9a80a8> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
> >    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
> >    at java.awt.EventQueue.getNextEvent(java.desktop at 11/EventQueue.java:620)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:190)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
> >    at java.awt.SequencedEvent.dispatch(java.desktop at 11/SequencedEvent.java:138)
> >    at java.awt.EventQueue.dispatchEventImpl(java.desktop at 11/EventQueue.java:770)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:721)
> >    at java.awt.EventQueue$4.run(java.desktop at 11/EventQueue.java:715)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:95)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:745)
> >    at java.awt.EventQueue$5.run(java.desktop at 11/EventQueue.java:743)
> >    at java.security.AccessController.doPrivileged(java.base at 11/Native Method)
> >    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base at 11/ProtectionDomain.java:85)
> >    at java.awt.EventQueue.dispatchEvent(java.desktop at 11/EventQueue.java:742)
> >    at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11/EventDispatchThread.java:203)
> >    at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11/EventDispatchThread.java:124)
> >    at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11/EventDispatchThread.java:113)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:109)
> >    at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11/EventDispatchThread.java:101)
> >    at java.awt.EventDispatchThread.run(java.desktop at 11/EventDispatchThread.java:90)
> > 
> > "Thread-3" #28 prio=6 os_prio=0 cpu=6,12ms elapsed=27,04s
> > tid=0x00007f9428017800 nid=0x1609 waiting for monitor entry
> > [0x00007f940bafd000]
> >   java.lang.Thread.State: BLOCKED (on object monitor)
> >    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:565)
> >    - waiting to lock <0x00000000cd9a85d8> (a
> > net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
> >    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
> >    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
> >    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$MovingTextRunner.run(java.desktop at 11/BasePainter.java:419)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "Thread-4" #29 prio=6 os_prio=0 cpu=4,04ms elapsed=27,04s
> > tid=0x00007f9428024000 nid=0x160a in Object.wait()
> > [0x00007f940b9fc000]
> >   java.lang.Thread.State: WAITING (on object monitor)
> >    at java.lang.Object.wait(java.base at 11/Native Method)
> >    - waiting on <no object reference available>
> >    at java.lang.Object.wait(java.base at 11/Object.java:328)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1361)
> >    - waiting to re-lock in wait() <0x00000000cf4015a8> (a
> > java.awt.EventQueue$1AWTInvocationLock)
> >    at java.awt.EventQueue.invokeAndWait(java.desktop at 11/EventQueue.java:1342)
> >    at javax.swing.SwingUtilities.invokeAndWait(java.desktop at 11/SwingUtilities.java:1480)
> >    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter.update(java.desktop at 11/BasePainter.java:579)
> >    - locked <0x00000000cd9a85d8> (a
> > net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter)
> >    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:173)
> >    at java.util.Observable.notifyObservers(java.base at 11/Observable.java:129)
> >    at net.sourceforge.jnlp.splashscreen.impls.defaultsplashscreen2012.BasePainter$WaterLevelThread.run(java.desktop at 11/BasePainter.java:452)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-2" #33 daemon prio=5 os_prio=0 cpu=70,09ms
> > elapsed=26,88s tid=0x00007f942c078000 nid=0x160e waiting on condition
> > [0x00007f940b4e7000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "TimerQueue" #37 daemon prio=5 os_prio=0 cpu=0,11ms elapsed=26,37s
> > tid=0x00007f942c15b000 nid=0x1613 waiting on condition
> > [0x00007f940b5fa000]
> >   java.lang.Thread.State: WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cf319e08> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >    at java.util.concurrent.locks.LockSupport.park(java.base at 11/LockSupport.java:194)
> >    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11/AbstractQueuedSynchronizer.java:2081)
> >    at java.util.concurrent.DelayQueue.take(java.base at 11/DelayQueue.java:217)
> >    at javax.swing.TimerQueue.run(java.desktop at 11/TimerQueue.java:171)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-3" #42 daemon prio=5 os_prio=0 cpu=14,09ms
> > elapsed=22,49s tid=0x00007f942c1d0000 nid=0x1618 waiting on condition
> > [0x00007f9407bfa000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-4" #43 daemon prio=5 os_prio=0 cpu=15,41ms
> > elapsed=22,48s tid=0x00007f942c1ce800 nid=0x1619 waiting on condition
> > [0x00007f9407cfb000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-5" #44 daemon prio=5 os_prio=0 cpu=14,30ms
> > elapsed=22,48s tid=0x00007f942c195800 nid=0x161a waiting on condition
> > [0x00007f9407af9000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-6" #45 daemon prio=5 os_prio=0 cpu=10,18ms
> > elapsed=22,48s tid=0x00007f942c191000 nid=0x161b waiting on condition
> > [0x00007f94079f8000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-7" #46 daemon prio=5 os_prio=0 cpu=10,95ms
> > elapsed=22,48s tid=0x00007f942c192000 nid=0x161c waiting on condition
> > [0x00007f94078f7000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-8" #47 daemon prio=5 os_prio=0 cpu=14,35ms
> > elapsed=22,47s tid=0x00007f942c193000 nid=0x161d waiting on condition
> > [0x00007f94077f6000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-9" #50 daemon prio=5 os_prio=0 cpu=14,10ms
> > elapsed=22,46s tid=0x00007f942c1c7800 nid=0x1620 waiting on condition
> > [0x00007f94074f3000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-10" #51 daemon prio=5 os_prio=0 cpu=11,33ms
> > elapsed=22,45s tid=0x00007f942c1c9000 nid=0x1621 waiting on condition
> > [0x00007f94073f2000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-11" #52 daemon prio=5 os_prio=0 cpu=10,87ms
> > elapsed=22,45s tid=0x00007f942c1ca800 nid=0x1622 waiting on condition
> > [0x00007f94072f1000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-12" #53 daemon prio=5 os_prio=0 cpu=10,86ms
> > elapsed=22,44s tid=0x00007f942c1cc800 nid=0x1623 waiting on condition
> > [0x00007f94071f0000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-13" #56 daemon prio=5 os_prio=0 cpu=10,73ms
> > elapsed=22,44s tid=0x00007f942c166800 nid=0x1626 waiting on condition
> > [0x00007f94070ef000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-14" #57 daemon prio=5 os_prio=0 cpu=14,54ms
> > elapsed=22,43s tid=0x00007f942c168000 nid=0x1627 waiting on condition
> > [0x00007f9406fee000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-15" #61 daemon prio=5 os_prio=0 cpu=17,19ms
> > elapsed=22,43s tid=0x00007f942c16a000 nid=0x1628 waiting on condition
> > [0x00007f9406eed000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-16" #62 daemon prio=5 os_prio=0 cpu=20,58ms
> > elapsed=22,42s tid=0x00007f942c16c000 nid=0x162c waiting on condition
> > [0x00007f94076f5000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-17" #64 daemon prio=5 os_prio=0 cpu=16,99ms
> > elapsed=22,40s tid=0x00007f942c16d800 nid=0x162e waiting on condition
> > [0x00007f9406dec000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-18" #66 daemon prio=5 os_prio=0 cpu=17,81ms
> > elapsed=22,40s tid=0x00007f942c16e800 nid=0x162f waiting on condition
> > [0x00007f94075f4000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-19" #68 daemon prio=5 os_prio=0 cpu=17,89ms
> > elapsed=22,40s tid=0x00007f942c16f800 nid=0x1630 waiting on condition
> > [0x00007f9406ceb000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-20" #69 daemon prio=5 os_prio=0 cpu=17,17ms
> > elapsed=22,39s tid=0x00007f942c170800 nid=0x1631 waiting on condition
> > [0x00007f94069e8000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-21" #72 daemon prio=5 os_prio=0 cpu=17,50ms
> > elapsed=22,38s tid=0x00007f942c1d8000 nid=0x1636 waiting on condition
> > [0x00007f9406bea000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-22" #76 daemon prio=5 os_prio=0 cpu=17,57ms
> > elapsed=22,37s tid=0x00007f942c1d2000 nid=0x163a waiting on condition
> > [0x00007f9406ae9000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "itwpool-1-itwthread-23" #77 daemon prio=5 os_prio=0 cpu=16,68ms
> > elapsed=22,37s tid=0x00007f942c1d3800 nid=0x163b waiting on condition
> > [0x00007f94061e0000]
> >   java.lang.Thread.State: TIMED_WAITING (parking)
> >    at jdk.internal.misc.Unsafe.park(java.base at 11/Native Method)
> >    - parking to wait for  <0x00000000cd726dc0> (a
> > java.util.concurrent.SynchronousQueue$TransferStack)
> >    at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11/LockSupport.java:234)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11/SynchronousQueue.java:462)
> >    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11/SynchronousQueue.java:361)
> >    at java.util.concurrent.SynchronousQueue.poll(java.base at 11/SynchronousQueue.java:937)
> >    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11/ThreadPoolExecutor.java:1053)
> >    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11/ThreadPoolExecutor.java:1114)
> >    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11/ThreadPoolExecutor.java:628)
> >    at java.lang.Thread.run(java.base at 11/Thread.java:834)
> > 
> > "VM Thread" os_prio=0 cpu=49,56ms elapsed=28,25s
> > tid=0x00007f94b019b800 nid=0x15e7 runnable
> > 
> > "GC Thread#0" os_prio=0 cpu=32,03ms elapsed=28,26s
> > tid=0x00007f94b0040000 nid=0x15e2 runnable
> > 
> > "GC Thread#1" os_prio=0 cpu=15,07ms elapsed=27,82s
> > tid=0x00007f9480001000 nid=0x15fb runnable
> > 
> > "GC Thread#2" os_prio=0 cpu=19,50ms elapsed=27,82s
> > tid=0x00007f9480002800 nid=0x15fc runnable
> > 
> > "GC Thread#3" os_prio=0 cpu=26,67ms elapsed=27,82s
> > tid=0x00007f9480004000 nid=0x15fd runnable
> > 
> > "G1 Main Marker" os_prio=0 cpu=0,45ms elapsed=28,26s
> > tid=0x00007f94b005b800 nid=0x15e3 runnable
> > 
> > "G1 Conc#0" os_prio=0 cpu=11,37ms elapsed=28,26s
> > tid=0x00007f94b005d800 nid=0x15e4 runnable
> > 
> > "G1 Refine#0" os_prio=0 cpu=2,30ms elapsed=28,26s
> > tid=0x00007f94b013a800 nid=0x15e5 runnable
> > 
> > "G1 Refine#1" os_prio=0 cpu=0,06ms elapsed=27,81s
> > tid=0x00007f9488001000 nid=0x15fe runnable
> > 
> > "G1 Young RemSet Sampling" os_prio=0 cpu=9,54ms elapsed=28,25s
> > tid=0x00007f94b013c800 nid=0x15e6 runnable
> > "VM Periodic Task Thread" os_prio=0 cpu=19,95ms elapsed=28,16s
> > tid=0x00007f94b02db000 nid=0x15f1 waiting on condition
> > 
> > JNI global refs: 88, weak refs: 487
> > 
> > Heap
> > garbage-first heap   total 262144K, used 108573K [0x00000000c0000000,
> > 0x0000000100000000)
> >  region size 1024K, 99 young (101376K), 5 survivors (5120K)
> > Metaspace       used 32074K, capacity 32873K, committed 33280K,
> > reserved 1079296K
> >  class space    used 3388K, capacity 3743K, committed 3840K, reserved 1048576K
> 
> 
> 
> -- 
> -- 
> Laurent Bourg?s
> 
> 
> -- 
> -- 
> Laurent Bourg?s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180906/ca301c1f/attachment-0001.html>

From bourges.laurent at gmail.com  Thu Sep  6 16:02:42 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 6 Sep 2018 18:02:42 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
In-Reply-To: <A191B547-5C02-482E-B53E-CBC41097393E@oracle.com>
References: <CAKjRUT622E2zkPvoOr=LKdNMxRxD8BUuhSwCpk1GDMEthC-2Ag@mail.gmail.com>
 <8D4E9052-4F4E-402C-B7DF-6CFE2039DDCF@oracle.com>
 <CAKjRUT4X0YA2DUH1VH8-JrVAQH=pqNW1+veBtkK83=-=+pppXg@mail.gmail.com>
 <CAKjRUT7t7D2txuDC6Lh9G5YXqKp=-ufZ4RP4AE9YduaPNRtPZw@mail.gmail.com>
 <CAKjRUT7z6EH657tkhLMBfagC_z2EfyALnc1FLZHkUOD_WU8pog@mail.gmail.com>
 <A191B547-5C02-482E-B53E-CBC41097393E@oracle.com>
Message-ID: <CAKjRUT7rwXzxguakT-JCc82Fx1OYO2SjspbROaf0cUD6Vi2O=A@mail.gmail.com>

Hi Krishna,

Le jeu. 6 sept. 2018 ? 16:08, Krishna Addepalli <
krishna.addepalli at oracle.com> a ?crit :

> Hi Laurent,
>
> Thanks for providing the test case. I was able to reproduce the issue.
> Glad to know that you found a workaround, as this issue is a bit tricky to
> fix.
>
Great.

Meanwhile, I?m looking into fixing this issue, and your test case greatly
> helps me toward finding the fix faster.
>

I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but I
got no clues, very tricky.

Good luck,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180906/791c22b9/attachment.html>

From ebakke at ultorg.com  Thu Sep  6 19:43:36 2018
From: ebakke at ultorg.com (Eirik Bakke)
Date: Thu, 6 Sep 2018 19:43:36 +0000
Subject: <AWT Dev> "Invalid Image variant" exception from AWT when using
 MultiResolutionImage (bug in SunGraphics2D.drawHiDPIImage?)
Message-ID: <BN6PR20MB12049FE445E7E38F8BB70B49A1010@BN6PR20MB1204.namprd20.prod.outlook.com>

Hi, AWT-dev.

I tried to get HiDPI icons working on my Swing application on Windows 10 today on OpenJDK 10.0.2, and ran into what seems to be an AWT bug. See the exhibit at https://github.com/eirikbakke/InvalidImageVariantBugExhibit/blob/master/src/invalidimagevariant/InvalidImageVariantBugExhibit.java

Loading two differently sized images via Toolkit.getImage() and putting them into a BaseMultiResolutionImage yields an "IllegalArgumentException: Invalid Image variant" exception from SurfaceManager.getManager when the MultiResolutionImage is used as an icon in a JButton and the JFrame is dragged onto my 200%-scaling HiDPI screen. See the full stack trace pasted at the end of this email.

The bug seems to be due to a race condition, where SunGraphics2D.drawHiDPIImage may return null even when the image is in fact a MultiResolutionImage, if the underlying image alternatives have not yet been fully loaded by the time the first paint is attempted.

Waiting for the image to load using MediaTracker.waitForAll() "fixes" the problem for the simplest case. This is not always an option in client code, however; there are other MultiResolutionImage instances being created behind the scenes for instance when a JButton is disabled and its icon needs to be greyed-out.

Note that there is a timing aspect to this bug, so not all configurations might expose it. The bug did not appear when I disconnected my external monitor and _just_ used the HiDPI laptop one (not sure if this is a timing issue or something else).

Also note: On MacOS, Toolkit.getImage() and friends have had the ability to automatically detect and load HiDPI images with a "@2x" suffix in their file name (JDK-8011059) . Am I correct that there is no equivalent mechanism on Windows?

-- Eirik

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Invalid Image variant
  at java.desktop/sun.awt.image.SurfaceManager.getManager(SurfaceManager.java:82)
  at java.desktop/sun.java2d.SurfaceData.getSourceSurfaceData(SurfaceData.java:218)
  at java.desktop/sun.java2d.pipe.DrawImage.renderImageScale(DrawImage.java:635)
  at java.desktop/sun.java2d.pipe.DrawImage.tryCopyOrScale(DrawImage.java:319)
  at java.desktop/sun.java2d.pipe.DrawImage.transformImage(DrawImage.java:258)
  at java.desktop/sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:76)
  at java.desktop/sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:1027)
  at java.desktop/sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3415)
  at java.desktop/sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3391)
  at java.desktop/javax.swing.ImageIcon.paintIcon(ImageIcon.java:425)
  at java.desktop/javax.swing.plaf.basic.BasicButtonUI.paintIcon(BasicButtonUI.java:358)
  at java.desktop/javax.swing.plaf.basic.BasicButtonUI.paint(BasicButtonUI.java:275)
  at java.desktop/com.sun.java.swing.plaf.windows.WindowsButtonUI.paint(WindowsButtonUI.java:167)
  at java.desktop/javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
  at java.desktop/javax.swing.JComponent.paintComponent(JComponent.java:797)
  at java.desktop/javax.swing.JComponent.paint(JComponent.java:1074)
  at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
  at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
  at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
  at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
  at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
  at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
  at java.desktop/javax.swing.JLayeredPane.paint(JLayeredPane.java:590)
  at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
  at java.desktop/javax.swing.JComponent.paintToOffscreen(JComponent.java:5262)
  at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(RepaintManager.java:1633)
  at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1608)
  at java.desktop/javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1546)
  at java.desktop/javax.swing.RepaintManager.paint(RepaintManager.java:1313)
  at java.desktop/javax.swing.JComponent.paint(JComponent.java:1060)
  at java.desktop/java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
  at java.desktop/sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:78)
  at java.desktop/sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:115)
  at java.desktop/java.awt.Container.paint(Container.java:2000)
  at java.desktop/java.awt.Window.paint(Window.java:3940)
  at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:868)
  at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:840)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
  at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:840)
  at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:815)
  at java.desktop/javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:764)
  at java.desktop/javax.swing.RepaintManager.access$1200(RepaintManager.java:69)
  at java.desktop/javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1880)
  at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
  at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
  at java.desktop/java.awt.EventQueue.access$600(EventQueue.java:97)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
  at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
  at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
  at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
  at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
  at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
  at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180906/0ce1b00f/attachment-0001.html>

From manajit.halder at oracle.com  Fri Sep  7 11:22:37 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 7 Sep 2018 16:52:37 +0530
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
 <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
Message-ID: <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>

Hi Dmitry,

Thanks for the test scenarios. I have run all the AWT, Swing and JCK 
automatic (open and closed) test cases along with manual test cases 
related to Modal Dialog and ordering to ensure that fix doesn't cause 
any regression. These JCK interactive test were run 
"api/java_awt/interactive/ModalDialogTests.html", 
"api/java_awt/interactive/FileDialogTests.html", 
"api/java_awt/interactive/PageDialogTest.html" and 
"api/java_awt/interactive/WindowTest.html" (tests toFront and toBack 
between a window and a Frame).

For example, manual test 
"open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" 
tests the scenario specified by you. Also there are many automatic test 
cases in "open/test/jdk/java/awt/Modal/ToBack" and 
"open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios 
related to Modal Dialog and Frame/Window ordering.

Please let me know if you have any other test scenarios to be tested.

Thanks,
Manajit

On 05/09/18 4:47 PM, Dmitry Markov wrote:
> Hi Manajit,
>
> Thank you for the clarification.
>
> Actually I worry about the case when a window is blocked by another 
> window or a modal dialog. We call orderAboveSiblings() for the blocker 
> window in several places, (e.g. inside setVisible(), 
> checkBlockingAndOrder(), etc.) and I guess some of these call might 
> fail with the new implementation of orderAboveSiblings(), (i.e. the 
> modal dialog might be placed behind the blocked window).
>
> For example, let?s say we have the window which is blocked by the 
> modal dialog. What will be the position of the dialog (above or behind 
> the blocked window) once the window is activated? Please note: there 
> are several ways to activate the window: mouse click, toFront() call, 
> etc. Can you verify that these scenarios still work properly on the 
> build with your fix, please?
>
> Also it would be good to execute related AWT/Swing jtreg tests to 
> ensure that nothing is broken.
>
> Thanks,
> Dmitry
>
>> On 4 Sep 2018, at 18:54, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi Dmitry,
>>
>> Thanks for your reply. Please see my reply inline.
>>
>> Thanks,
>> Manajit
>>
>>
>> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>>> Hi Manajit,
>>>
>>> The current implementation assumes that orderAboveSiblings() places 
>>> the window in front of other windows located at the same level. The 
>>> proposed fix introduces new behaviour: if the window does not have 
>>> an owner and child windows it won?t be ordered, (i.e. in certain 
>>> conditions the window may be obscured by other windows even after 
>>> orderAboveSibling() execution). Most likely such approach will break 
>>> existed functionality - some windows will be incorrectly placed 
>>> behind other windows.
>> ??? If I am not wrong windows (other than Window.Type.POPUP) are 
>> already ordered in setVisible method at line no 632 while creation. 
>> While debugging I observed that orderFront is called twice when the 
>> window is displayed for the first time (in method setVisible and in 
>> method orderAboveSiblings). Now when Key press COMMAND + ` is pressed 
>> the current window receives windowDidBecomeMain notification and 
>> which calls orderFront and also COMMAND + ` tries to order the window 
>> above. Two time ordering the window when COMMAND + ` is pressed is 
>> causing problem in case of multiple windows.
>>>
>>> I am sorry, but the relationship between the original problem 
>>> described in the bug, (i.e. cycling through windows issue) and 
>>> implementation of orderAboveSiblings() is NOT clear. Can you explain 
>>> this?
>> ??? This issue is a regression of JDK-8169589 introduced in JDK 
>> release 8u131. 8169589 introduced new window ordering model and which 
>> has introduced the cycling through window issue.
>>>
>>> Thanks,
>>> Dmitry
>>>
>>>> On 31 Aug 2018, at 07:55, Manajit Halder <manajit.halder at oracle.com 
>>>> <mailto:manajit.halder at oracle.com>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Please review the fix for JDK12.
>>>>
>>>> 

Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8206392
>>>>
>>>> <https://bugs.openjdk.java.net/browse/JDK-8206392>
Webrev: 

>>>> http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>>>
>>>> Fix: 

>>>> ??? Window ordering is not required if the window doesn't own any 
>>>> other windows.
>>>>
>>>> Regards,
>>>> Manajit
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180907/0bf4daac/attachment.html>

From kevin.rushforth at oracle.com  Fri Sep  7 20:22:53 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 7 Sep 2018 13:22:53 -0700
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <e87d0b73-693c-40fa-af44-1529dd9343d4@default>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
 <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
 <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>
 <e87d0b73-693c-40fa-af44-1529dd9343d4@default>
Message-ID: <38a5b001-dd1e-4105-1359-d5d5c8d0e619@oracle.com>

I tested various combinations of Swing / FX interop and it all looks 
fine to me. I only glanced through the AWT code changes, though, but I 
didn't spot anything amiss.

-- Kevin


On 9/6/2018 4:35 AM, Pankaj Bansal wrote:
> Hello Sergey/Kevin,
>
> I have removed the backport for https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper. I did a clean build and tried few tests for Swing-FX interop. They all run fine. I have attached the link to tests if you would like to have a look. I did run the awt and swing jtreg tests also.
>
> Webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.01/
> SwingFXInteropTests:  http://cr.openjdk.java.net/~pbansal/gtk3_backport/SwingFXInteropTests/
>
> Please let me know if you would like me to do some further testing for Swing-FX interop.
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Thursday, September 6, 2018 3:29 AM
> To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux
>
> The simple testing that I did -- one each of a Swing app + JFXPanel and a JavaFX app + SwingNode -- worked for me on my local build after restoring that file. Some additional testing (necessarily limited to GTK
> 2 until the FX backport for GTK 3 is done) might be needed.
>
> -- Kevin
>
>
> On 9/5/2018 2:35 PM, Sergey Bylokhov wrote:
>> HI, Pankaj.
>> Can you please recheck that FX<-->Swing interop still works? Probably
>> there are some other than GThreadHelper issues
>>
>> On 05/09/2018 11:44, Pankaj Bansal wrote:
>>> Hello Kevin,
>>>
>>> Thanks for pointing it out. I will remove this fix for now. I hope
>>> its ok, if I create new webrev when I get some more comments here.
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>> *From:*Kevin Rushforth
>>> *Sent:* Wednesday, September 5, 2018 10:29 PM
>>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net;
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing]
>>> Conditional support for GTK 3 on Linux
>>>
>>> The backport of the following fix, which removes
>>> sun.misc.GThreadHelper, will break all FX interop applications, even
>>> if GTK2 is used:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire
>>> sun.misc.GThreadHelper
>>>
>>> The FX GTK port still uses that class, so the class needs to be left
>>> in until after the FX support for GTK 3 has been backported.
>>>
>>> -- Kevin
>>>
>>>
>>> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>>>
>>>  ??? Hi All,
>>>
>>>  ??? Please review the patch for 8u-dev backport for JDK-8145547. It
>>> adds
>>>  ??? conditional support for gtk3.
>>>
>>>  ??? The original fix does not apply cleanly as few changes were done
>>> in
>>>  ??? jdk9 before the gtk3 support was added, major once being
>>> JDK-8025815
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8014212> and
>>> JDK-8137571
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8137571>
>>>
>>>  ??? Along with the enhancement, following bug fixes have also been
>>>  ??? included in the backport webrev
>>>
>>>  ??? 1.https://bugs.openjdk.java.net/browse/JDK-8155772:
>>> gtk3_interface.c
>>>  ??? compilation error on Ubuntu 12.10
>>>
>>>  ??? 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547
>>> breaks
>>>  ??? AIX and and uses RTLD_NOLOAD incorrectly
>>>
>>>  ??? 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>>>  ??? fails for GTK3 if no GTK2 available
>>>
>>>  ??? 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>>>  ??? [AWT/Swing] Conditional support for GTK 3 on Linux
>>>
>>>  ??? 5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>>>  ??? AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>>>  ??? version when jdk.gtk.version=3
>>>
>>>  ??? 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>>>  ??? displayed nothing with the option"-server -d64 -Xmixed
>>> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>>>
>>>  ??? 7.https://bugs.openjdk.java.net/browse/JDK-8191041: Questionable
>>>  ??? Rendering of Disabled Text in Swing GTK L&F
>>>
>>>  ??? 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>>>  ??? FileDialog Modality Tests fail on Linux due to X errors
>>>
>>>  ??? 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build failure
>>> on
>>>  ??? Linux arm64
>>>
>>>  ??? 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>>>  ??? sun.misc.GThreadHelper
>>>
>>>  ??? 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree
>>> Collapse
>>>  ??? Buttons Clipped Off Under GTK
>>>
>>>  ??? 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3
>>> menus
>>>  ??? appearence similar to native.
>>>
>>>  ??? 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] crash
>>> in
>>>  ??? AWT_Desktop/Automated/Exceptions/BasicTest
>>>
>>>  ??? 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The
>>> FileChooser
>>>  ??? didn't displayed large font with GTK LAF option.
>>>
>>>  ??? 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>>>  ??? SwingNode with GTK LaF
>>>
>>>  ??? 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>>>  ??? Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>>>  ??? awt_UNIXToolkit.c:132
>>>
>>>  ??? 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris
>>> build
>>>  ??? failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>>>
>>>  ??? webrev:
>>> http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>>>
>>>  ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>
>>>  ??? JDK 9 Changeset:
>>>  ??? http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>>>
>>>  ??? I have run the related jtreg and jck tests and results are fine.
>>>
>>>  ??? Regards,
>>>
>>>  ??? Pankaj
>>>
>>


From dmitry.markov at oracle.com  Sun Sep  9 10:05:46 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Sun, 9 Sep 2018 11:05:46 +0100
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
 <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
 <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>
Message-ID: <7A51ABB6-4640-4D8B-9B76-03F2CF9FBFA8@oracle.com>

Hi Manajit,

The fix looks good to me. Can you port it to JDK 8u too, please?

Thanks,
Dmitry

> On 7 Sep 2018, at 12:22, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> Thanks for the test scenarios. I have run all the AWT, Swing and JCK automatic (open and closed) test cases along with manual test cases related to Modal Dialog and ordering to ensure that fix doesn't cause any regression. These JCK interactive test were run "api/java_awt/interactive/ModalDialogTests.html", "api/java_awt/interactive/FileDialogTests.html", "api/java_awt/interactive/PageDialogTest.html" and "api/java_awt/interactive/WindowTest.html" (tests toFront and toBack between a window and a Frame). 
> For example, manual test "open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" tests the scenario specified by you. Also there are many automatic test cases in "open/test/jdk/java/awt/Modal/ToBack" and "open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios related to Modal Dialog and Frame/Window ordering.
> 
> Please let me know if you have any other test scenarios to be tested.
> 
> Thanks,
> Manajit
> On 05/09/18 4:47 PM, Dmitry Markov wrote:
>> Hi Manajit,
>> 
>> Thank you for the clarification.
>> 
>> Actually I worry about the case when a window is blocked by another window or a modal dialog. We call orderAboveSiblings() for the blocker window in several places, (e.g. inside setVisible(), checkBlockingAndOrder(), etc.) and I guess some of these call might fail with the new implementation of orderAboveSiblings(), (i.e. the modal dialog might be placed behind the blocked window).
>> 
>> For example, let?s say we have the window which is blocked by the modal dialog. What will be the position of the dialog (above or behind the blocked window) once the window is activated? Please note: there are several ways to activate the window: mouse click, toFront() call, etc. Can you verify that these scenarios still work properly on the build with your fix, please?
>> 
>> Also it would be good to execute related AWT/Swing jtreg tests to ensure that nothing is broken.
>> 
>> Thanks,
>> Dmitry 
>> 
>>> On 4 Sep 2018, at 18:54, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> Thanks for your reply. Please see my reply inline.
>>> 
>>> Thanks,
>>> Manajit
>>> 
>>> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>>>> Hi Manajit,
>>>> 
>>>> The current implementation assumes that orderAboveSiblings() places the window in front of other windows located at the same level. The proposed fix introduces new behaviour: if the window does not have an owner and child windows it won?t be ordered, (i.e. in certain conditions the window may be obscured by other windows even after orderAboveSibling() execution). Most likely such approach will break existed functionality - some windows will be incorrectly placed behind other windows.
>>>     If I am not wrong windows (other than Window.Type.POPUP) are already ordered in setVisible method at line no 632 while creation. While debugging I observed that orderFront is called twice when the window is displayed for the first time (in method setVisible and in method orderAboveSiblings). Now when Key press COMMAND + ` is pressed the current window receives windowDidBecomeMain notification and which calls orderFront and also COMMAND + ` tries to order the window above. Two time ordering the window when COMMAND + ` is pressed is causing problem in case of multiple windows.
>>>> 
>>>> I am sorry, but the relationship between the original problem described in the bug, (i.e. cycling through windows issue) and implementation of                     orderAboveSiblings() is NOT clear. Can you explain this?
>>>     This issue is a regression of JDK-8169589 introduced in JDK release 8u131. 8169589 introduced new window ordering model and which has introduced the cycling through window issue.
>>>> 
>>>> Thanks,
>>>> Dmitry  
>>>> 
>>>>> On 31 Aug 2018, at 07:55, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Please review the fix for JDK12.
>>>>> 
>>>>> 
>>>>> 
>>>>> Bug: 
>>>>>      https://bugs.openjdk.java.net/browse/JDK-8206392 <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>>>> Webrev: 
>>>>> 
>>>>>     http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>>>> Fix: 
>>>>> 
>>>>>     Window ordering is not required if the window doesn't own any other windows.
>>>>> 
>>>>> Regards,
>>>>> Manajit
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180909/49fe7fbd/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 10 00:53:37 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 9 Sep 2018 17:53:37 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
Message-ID: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>

Hello.
Please review the fix for jdk 12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
Webrev: http://cr.openjdk.java.net/~serb/8170937/webrev.00

The logic to calculate the screen insets is changed in the 
XToolkit.java. Please take a look to the comments of the bug for more 
information.

  - Additional sanity checks are added to the "ScreenInsetsTest" test.
  - "FrameBorderCounter.java" is updated because it is used by a few 
tests which starts to fail after the fix in the multi-screen config(it 
fail in single screen config before), the reason is that it opens the 
windows to fast.

-- 
Best regards, Sergey.


From manajit.halder at oracle.com  Mon Sep 10 12:19:45 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 10 Sep 2018 17:49:45 +0530
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <7A51ABB6-4640-4D8B-9B76-03F2CF9FBFA8@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
 <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
 <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>
 <7A51ABB6-4640-4D8B-9B76-03F2CF9FBFA8@oracle.com>
Message-ID: <45a01a34-f8d5-15d2-74af-d77465e29678@oracle.com>

Hi Dmitry,

Sure, I can port it to JDK 8u, but would require your help in check-in, 
as I don't have permission to check-in JDK 8u.

Thanks,

Manajit


On 09/09/18 3:35 PM, Dmitry Markov wrote:
> Hi Manajit,
>
> The fix looks good to me. Can you port it to JDK 8u too, please?
>
> Thanks,
> Dmitry
>
>> On 7 Sep 2018, at 12:22, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi Dmitry,
>>
>> Thanks for the test scenarios. I have run all the AWT, Swing and JCK 
>> automatic (open and closed) test cases along with manual test cases 
>> related to Modal Dialog and ordering to ensure that fix doesn't cause 
>> any regression. These JCK interactive test were run 
>> "api/java_awt/interactive/ModalDialogTests.html", 
>> "api/java_awt/interactive/FileDialogTests.html", 
>> "api/java_awt/interactive/PageDialogTest.html" and 
>> "api/java_awt/interactive/WindowTest.html" (tests toFront and toBack 
>> between a window and a Frame).
>>
>> For example, manual test 
>> "open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" 
>> tests the scenario specified by you. Also there are many automatic 
>> test cases in "open/test/jdk/java/awt/Modal/ToBack" and 
>> "open/test/jdk/java/awt/Modal/ToFront" which tests different 
>> scenarios related to Modal Dialog and Frame/Window ordering.
>>
>> Please let me know if you have any other test scenarios to be tested.
>>
>> Thanks,
>> Manajit
>>
>> On 05/09/18 4:47 PM, Dmitry Markov wrote:
>>> Hi Manajit,
>>>
>>> Thank you for the clarification.
>>>
>>> Actually I worry about the case when a window is blocked by another 
>>> window or a modal dialog. We call orderAboveSiblings() for the 
>>> blocker window in several places, (e.g. inside setVisible(), 
>>> checkBlockingAndOrder(), etc.) and I guess some of these call might 
>>> fail with the new implementation of orderAboveSiblings(), (i.e. the 
>>> modal dialog might be placed behind the blocked window).
>>>
>>> For example, let?s say we have the window which is blocked by the 
>>> modal dialog. What will be the position of the dialog (above or 
>>> behind the blocked window) once the window is activated? Please 
>>> note: there are several ways to activate the window: mouse click, 
>>> toFront() call, etc. Can you verify that these scenarios still work 
>>> properly on the build with your fix, please?
>>>
>>> Also it would be good to execute related AWT/Swing jtreg tests to 
>>> ensure that nothing is broken.
>>>
>>> Thanks,
>>> Dmitry
>>>
>>>> On 4 Sep 2018, at 18:54, Manajit Halder <manajit.halder at oracle.com 
>>>> <mailto:manajit.halder at oracle.com>> wrote:
>>>>
>>>> Hi Dmitry,
>>>>
>>>> Thanks for your reply. Please see my reply inline.
>>>>
>>>> Thanks,
>>>> Manajit
>>>>
>>>>
>>>> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>>>>> Hi Manajit,
>>>>>
>>>>> The current implementation assumes that orderAboveSiblings() 
>>>>> places the window in front of other windows located at the same 
>>>>> level. The proposed fix introduces new behaviour: if the window 
>>>>> does not have an owner and child windows it won?t be ordered, 
>>>>> (i.e. in certain conditions the window may be obscured by other 
>>>>> windows even after orderAboveSibling() execution). Most likely 
>>>>> such approach will break existed functionality - some windows will 
>>>>> be incorrectly placed behind other windows.
>>>> ??? If I am not wrong windows (other than Window.Type.POPUP) are 
>>>> already ordered in setVisible method at line no 632 while creation. 
>>>> While debugging I observed that orderFront is called twice when the 
>>>> window is displayed for the first time (in method setVisible and in 
>>>> method orderAboveSiblings). Now when Key press COMMAND + ` is 
>>>> pressed the current window receives windowDidBecomeMain 
>>>> notification and which calls orderFront and also COMMAND + ` tries 
>>>> to order the window above. Two time ordering the window when 
>>>> COMMAND + ` is pressed is causing problem in case of multiple windows.
>>>>>
>>>>> I am sorry, but the relationship between the original problem 
>>>>> described in the bug, (i.e. cycling through windows issue) and 
>>>>> implementation of orderAboveSiblings() is NOT clear. Can you 
>>>>> explain this?
>>>> ??? This issue is a regression of JDK-8169589 introduced in JDK 
>>>> release 8u131. 8169589 introduced new window ordering model and 
>>>> which has introduced the cycling through window issue.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>
>>>>>> On 31 Aug 2018, at 07:55, Manajit Halder 
>>>>>> <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the fix for JDK12.
>>>>>>
>>>>>> 

Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206392
>>>>>>
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8206392>
Webrev: 

>>>>>> http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ 
>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>>>>>
>>>>>> Fix: 

>>>>>> ??? Window ordering is not required if the window doesn't own any 
>>>>>> other windows.
>>>>>>
>>>>>> Regards,
>>>>>> Manajit
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180910/b032998c/attachment.html>

From dmitry.markov at oracle.com  Mon Sep 10 12:36:24 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 10 Sep 2018 13:36:24 +0100
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <45a01a34-f8d5-15d2-74af-d77465e29678@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
 <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
 <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>
 <7A51ABB6-4640-4D8B-9B76-03F2CF9FBFA8@oracle.com>
 <45a01a34-f8d5-15d2-74af-d77465e29678@oracle.com>
Message-ID: <50CCCC00-6102-4227-BA3B-95ED2F2AA03A@oracle.com>

Hi Manajit,

No problem, I will sponsor your commit to JDK 8u once it is ready and approved.

Thanks,
Dmitry 

> On 10 Sep 2018, at 13:19, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> Sure, I can port it to JDK 8u, but would require your help in check-in, as I don't have permission to check-in JDK 8u.
> Thanks,
> 
> Manajit
> 
> 
> On 09/09/18 3:35 PM, Dmitry Markov wrote:
>> Hi Manajit,
>> 
>> The fix looks good to me. Can you port it to JDK 8u too, please?
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 7 Sep 2018, at 12:22, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> Thanks for the test scenarios. I have run all the AWT, Swing and JCK automatic (open and closed) test cases along with manual test cases related to Modal Dialog and ordering to ensure that fix doesn't cause any regression. These JCK interactive test were run "api/java_awt/interactive/ModalDialogTests.html", "api/java_awt/interactive/FileDialogTests.html", "api/java_awt/interactive/PageDialogTest.html" and "api/java_awt/interactive/WindowTest.html" (tests toFront and toBack between a window and a Frame). 
>>> For example, manual test "open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" tests the scenario specified by you. Also there are many automatic test cases in "open/test/jdk/java/awt/Modal/ToBack" and "open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios related to Modal Dialog and Frame/Window ordering.
>>> 
>>> Please let me know if you have any other test scenarios to be tested.
>>> 
>>> Thanks,
>>> Manajit
>>> On 05/09/18 4:47 PM, Dmitry Markov wrote:
>>>> Hi Manajit,
>>>> 
>>>> Thank you for the clarification.
>>>> 
>>>> Actually I worry about the case when a window is blocked by another window or a modal dialog. We call orderAboveSiblings() for the blocker                     window in several places, (e.g. inside setVisible(), checkBlockingAndOrder(), etc.) and I guess some of these call might fail with the new implementation of orderAboveSiblings(), (i.e. the modal dialog might be placed behind the blocked window).
>>>> 
>>>> For example, let?s say we have the window which is blocked by the modal dialog. What will be the position of the dialog (above or behind the blocked window) once the window is activated? Please note: there are several ways to activate the window: mouse click, toFront() call, etc. Can you verify that these scenarios still work properly on the build with your fix, please?
>>>> 
>>>> Also it would be good to execute related AWT/Swing jtreg tests to ensure that nothing is broken.
>>>> 
>>>> Thanks,
>>>> Dmitry 
>>>> 
>>>>> On 4 Sep 2018, at 18:54, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>>>> 
>>>>> Hi Dmitry,
>>>>> 
>>>>> Thanks for your reply. Please see my reply inline.
>>>>> 
>>>>> Thanks,
>>>>> Manajit
>>>>> 
>>>>> On 01/09/18 12:02 AM, Dmitry Markov wrote:
>>>>>> Hi Manajit,
>>>>>> 
>>>>>> The current implementation assumes that orderAboveSiblings() places the window in front of other windows located at the same level. The proposed fix introduces new behaviour: if the window does not have an owner and child windows it won?t be ordered, (i.e. in certain conditions the window may be obscured by other windows even after orderAboveSibling() execution). Most likely such approach will break existed functionality - some windows will be incorrectly placed behind other windows.
>>>>>     If I am not wrong windows (other than Window.Type.POPUP) are already ordered in setVisible method at line no 632 while creation. While debugging I observed that orderFront is called twice when the window is displayed for the first time (in method setVisible and in method orderAboveSiblings). Now when Key press COMMAND + ` is pressed the current window receives windowDidBecomeMain notification and which calls orderFront and also COMMAND + ` tries to order the window above. Two time ordering the window when COMMAND + ` is pressed is causing problem in case of multiple windows.
>>>>>> 
>>>>>> I am sorry, but the relationship between the original problem described in the bug, (i.e. cycling through windows issue) and implementation of orderAboveSiblings() is NOT clear. Can you explain this?
>>>>>     This issue is a regression of JDK-8169589 introduced in JDK release 8u131. 8169589 introduced new window ordering model and which has introduced the cycling through window issue.
>>>>>> 
>>>>>> Thanks,
>>>>>> Dmitry  
>>>>>> 
>>>>>>> On 31 Aug 2018, at 07:55, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Please review the fix for JDK12.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Bug: 
>>>>>>>      https://bugs.openjdk.java.net/browse/JDK-8206392 <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8206392>
>>>>>>> Webrev: 
>>>>>>> 
>>>>>>>     http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/>
>>>>>>> Fix: 
>>>>>>> 
>>>>>>>     Window ordering is not required if the window doesn't own any other windows.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180910/b5ddb5fb/attachment-0001.html>

From philip.race at oracle.com  Mon Sep 10 20:20:32 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 10 Sep 2018 13:20:32 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
Message-ID: <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>

Looks good to me.
But should we consider a switch that allows people to still get the 
long, slow, ideal answer ?

-phil.

On 9/9/2018 5:53 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 12.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
> Webrev: http://cr.openjdk.java.net/~serb/8170937/webrev.00
>
> The logic to calculate the screen insets is changed in the 
> XToolkit.java. Please take a look to the comments of the bug for more 
> information.
>
> ?- Additional sanity checks are added to the "ScreenInsetsTest" test.
> ?- "FrameBorderCounter.java" is updated because it is used by a few 
> tests which starts to fail after the fix in the multi-screen config(it 
> fail in single screen config before), the reason is that it opens the 
> windows to fast.
>


From Sergey.Bylokhov at oracle.com  Mon Sep 10 22:13:11 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Sep 2018 15:13:11 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
Message-ID: <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>

Hi, Phil.
On 10/09/2018 13:20, Phil Race wrote:
> But should we consider a switch that allows people to still get the 
> long, slow, ideal answer ?

Yes it is possible to add a non-public/unsupported property(only as a 
workaround for possible bugs):
http://cr.openjdk.java.net/~serb/8170937/webrev.02
But at some point(jdk12/13?) we can drop it.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Sep 10 22:32:08 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 10 Sep 2018 15:32:08 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
 <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
Message-ID: <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>

Looks good. Maybe update this comment before you push ?

 ?921????? * This method is unused because of two reasons:

".. unused by default ..." ?

-phil.

On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> On 10/09/2018 13:20, Phil Race wrote:
>> But should we consider a switch that allows people to still get the 
>> long, slow, ideal answer ?
>
> Yes it is possible to add a non-public/unsupported property(only as a 
> workaround for possible bugs):
> http://cr.openjdk.java.net/~serb/8170937/webrev.02
> But at some point(jdk12/13?) we can drop it.
>
>


From alexey.ivanov at oracle.com  Tue Sep 11 19:16:45 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 11 Sep 2018 20:16:45 +0100
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
 <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
 <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>
Message-ID: <1e0f34ca-cc21-8767-1ab2-ebbeae585127@oracle.com>

Hi Sergey,

Looks good.

However, some comments need to be corrected:

844????? * produce wrong result.
produces?

 ?853????? *? When two screens are overlap and the first contain a 
dock(*****), then
 ?854????? *? _NET_WORKAREA may start at point x1,y1 and ends at point 
x2,y2.
When two screens overlap and the first contains a dock(*****), then
_NET_WORKAREA may start at point x1,y1 and end at point x2,y2.

 ?926????? *??? calculated, but the system panels are not necessary 
contain these
 ?927????? *??? hints(Gnome 3 for example).
?the system panels do not necessarily contain?


Regards,
Alexey

On 10/09/2018 23:32, Phil Race wrote:
> Looks good. Maybe update this comment before you push ?
>
> ?921????? * This method is unused because of two reasons:
>
> ".. unused by default ..." ?
>
> -phil.
>
> On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> On 10/09/2018 13:20, Phil Race wrote:
>>> But should we consider a switch that allows people to still get the 
>>> long, slow, ideal answer ?
>>
>> Yes it is possible to add a non-public/unsupported property(only as a 
>> workaround for possible bugs):
>> http://cr.openjdk.java.net/~serb/8170937/webrev.02
>> But at some point(jdk12/13?) we can drop it.
>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Sep 11 21:54:52 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Sep 2018 14:54:52 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <1e0f34ca-cc21-8767-1ab2-ebbeae585127@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
 <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
 <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>
 <1e0f34ca-cc21-8767-1ab2-ebbeae585127@oracle.com>
Message-ID: <1fd447be-e657-d855-7b88-9445bb8437cc@oracle.com>

Hi, Phil and Alexey.
Thank you for review.

For the record the latest version:
http://cr.openjdk.java.net/~serb/8170937/webrev.03

On 11/09/2018 12:16, Alexey Ivanov wrote:
> Hi Sergey,
> 
> Looks good.
> 
> However, some comments need to be corrected:
> 
> 844????? * produce wrong result.
> produces?
> 
>  ?853????? *? When two screens are overlap and the first contain a 
> dock(*****), then
>  ?854????? *? _NET_WORKAREA may start at point x1,y1 and ends at point 
> x2,y2.
> When two screens overlap and the first contains a dock(*****), then
> _NET_WORKAREA may start at point x1,y1 and end at point x2,y2.
> 
>  ?926????? *??? calculated, but the system panels are not necessary 
> contain these
>  ?927????? *??? hints(Gnome 3 for example).
> ?the system panels do not necessarily contain?
> 
> 
> Regards,
> Alexey
> 
> On 10/09/2018 23:32, Phil Race wrote:
>> Looks good. Maybe update this comment before you push ?
>>
>> ?921????? * This method is unused because of two reasons:
>>
>> ".. unused by default ..." ?
>>
>> -phil.
>>
>> On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:
>>> Hi, Phil.
>>> On 10/09/2018 13:20, Phil Race wrote:
>>>> But should we consider a switch that allows people to still get the 
>>>> long, slow, ideal answer ?
>>>
>>> Yes it is possible to add a non-public/unsupported property(only as a 
>>> workaround for possible bugs):
>>> http://cr.openjdk.java.net/~serb/8170937/webrev.02
>>> But at some point(jdk12/13?) we can drop it.
>>>
>>>
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Sep 11 23:08:10 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 11 Sep 2018 16:08:10 -0700
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <1fd447be-e657-d855-7b88-9445bb8437cc@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
 <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
 <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>
 <1e0f34ca-cc21-8767-1ab2-ebbeae585127@oracle.com>
 <1fd447be-e657-d855-7b88-9445bb8437cc@oracle.com>
Message-ID: <5B984ADA.6060506@oracle.com>

OK !

-phil.

On 9/11/18, 2:54 PM, Sergey Bylokhov wrote:
> Hi, Phil and Alexey.
> Thank you for review.
>
> For the record the latest version:
> http://cr.openjdk.java.net/~serb/8170937/webrev.03
>
> On 11/09/2018 12:16, Alexey Ivanov wrote:
>> Hi Sergey,
>>
>> Looks good.
>>
>> However, some comments need to be corrected:
>>
>> 844      * produce wrong result.
>> produces?
>>
>>   853      *  When two screens are overlap and the first contain a 
>> dock(*****), then
>>   854      *  _NET_WORKAREA may start at point x1,y1 and ends at 
>> point x2,y2.
>> When two screens overlap and the first contains a dock(*****), then
>> _NET_WORKAREA may start at point x1,y1 and end at point x2,y2.
>>
>>   926      *    calculated, but the system panels are not necessary 
>> contain these
>>   927      *    hints(Gnome 3 for example).
>> ?the system panels do not necessarily contain?
>>
>>
>> Regards,
>> Alexey
>>
>> On 10/09/2018 23:32, Phil Race wrote:
>>> Looks good. Maybe update this comment before you push ?
>>>
>>>  921      * This method is unused because of two reasons:
>>>
>>> ".. unused by default ..." ?
>>>
>>> -phil.
>>>
>>> On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:
>>>> Hi, Phil.
>>>> On 10/09/2018 13:20, Phil Race wrote:
>>>>> But should we consider a switch that allows people to still get 
>>>>> the long, slow, ideal answer ?
>>>>
>>>> Yes it is possible to add a non-public/unsupported property(only as 
>>>> a workaround for possible bugs):
>>>> http://cr.openjdk.java.net/~serb/8170937/webrev.02
>>>> But at some point(jdk12/13?) we can drop it.
>>>>
>>>>
>>>
>>
>
>

From alexey.ivanov at oracle.com  Wed Sep 12 11:09:54 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 12 Sep 2018 12:09:54 +0100
Subject: <AWT Dev> [12] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <5B984ADA.6060506@oracle.com>
References: <bca92e02-4ac6-3b89-1df2-fd7595d394ec@oracle.com>
 <276e488e-4ec5-d7be-3cc7-014a9bc6e311@oracle.com>
 <db26d8d4-479f-f76d-91bb-c0a140dbcee8@oracle.com>
 <a3a16cfc-1d8f-3741-9aa8-5fba99c79899@oracle.com>
 <1e0f34ca-cc21-8767-1ab2-ebbeae585127@oracle.com>
 <1fd447be-e657-d855-7b88-9445bb8437cc@oracle.com>
 <5B984ADA.6060506@oracle.com>
Message-ID: <0632b42d-47dd-8d46-8081-4cb8021d1a2f@oracle.com>

Still looks fine.

--
Alexey

On 12/09/2018 00:08, Philip Race wrote:
> OK !
>
> -phil.
>
> On 9/11/18, 2:54 PM, Sergey Bylokhov wrote:
>> Hi, Phil and Alexey.
>> Thank you for review.
>>
>> For the record the latest version:
>> http://cr.openjdk.java.net/~serb/8170937/webrev.03
>>
>> On 11/09/2018 12:16, Alexey Ivanov wrote:
>>> Hi Sergey,
>>>
>>> Looks good.
>>>
>>> However, some comments need to be corrected:
>>>
>>> 844????? * produce wrong result.
>>> produces?
>>>
>>> ? 853????? *? When two screens are overlap and the first contain a 
>>> dock(*****), then
>>> ? 854????? *? _NET_WORKAREA may start at point x1,y1 and ends at 
>>> point x2,y2.
>>> When two screens overlap and the first contains a dock(*****), then
>>> _NET_WORKAREA may start at point x1,y1 and end at point x2,y2.
>>>
>>> ? 926????? *??? calculated, but the system panels are not necessary 
>>> contain these
>>> ? 927????? *??? hints(Gnome 3 for example).
>>> ?the system panels do not necessarily contain?
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 10/09/2018 23:32, Phil Race wrote:
>>>> Looks good. Maybe update this comment before you push ?
>>>>
>>>> ?921????? * This method is unused because of two reasons:
>>>>
>>>> ".. unused by default ..." ?
>>>>
>>>> -phil.
>>>>
>>>> On 9/10/2018 3:13 PM, Sergey Bylokhov wrote:
>>>>> Hi, Phil.
>>>>> On 10/09/2018 13:20, Phil Race wrote:
>>>>>> But should we consider a switch that allows people to still get 
>>>>>> the long, slow, ideal answer ?
>>>>>
>>>>> Yes it is possible to add a non-public/unsupported property(only 
>>>>> as a workaround for possible bugs):
>>>>> http://cr.openjdk.java.net/~serb/8170937/webrev.02
>>>>> But at some point(jdk12/13?) we can drop it.
>>>>>
>>>>>
>>>>
>>>
>>
>>


From pankaj.b.bansal at oracle.com  Wed Sep 12 12:29:10 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 12 Sep 2018 05:29:10 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <38a5b001-dd1e-4105-1359-d5d5c8d0e619@oracle.com>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
 <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
 <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>
 <e87d0b73-693c-40fa-af44-1529dd9343d4@default>
 <38a5b001-dd1e-4105-1359-d5d5c8d0e619@oracle.com>
Message-ID: <728fa992-87f3-43c3-a9cb-952b67b524b8@default>

Hi, 

I have found a small mistake in gtk_interface.c. I had used wrong name of gtk3 lib at line 56. I have correct the same in webrev.02. 
It is just a typo and should not have any effect on functionality. All should work the same as 01 version. 

Webrev:
http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.02/

Regards,
Pankaj


-----Original Message-----
From: Kevin Rushforth 
Sent: Saturday, September 8, 2018 1:53 AM
To: Pankaj Bansal; Sergey Bylokhov; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

I tested various combinations of Swing / FX interop and it all looks fine to me. I only glanced through the AWT code changes, though, but I didn't spot anything amiss.

-- Kevin


On 9/6/2018 4:35 AM, Pankaj Bansal wrote:
> Hello Sergey/Kevin,
>
> I have removed the backport for https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper. I did a clean build and tried few tests for Swing-FX interop. They all run fine. I have attached the link to tests if you would like to have a look. I did run the awt and swing jtreg tests also.
>
> Webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.01/
> SwingFXInteropTests:  
> http://cr.openjdk.java.net/~pbansal/gtk3_backport/SwingFXInteropTests/
>
> Please let me know if you would like me to do some further testing for Swing-FX interop.
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Thursday, September 6, 2018 3:29 AM
> To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net; 
> swing-dev at openjdk.java.net
> Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: 
> [AWT/Swing] Conditional support for GTK 3 on Linux
>
> The simple testing that I did -- one each of a Swing app + JFXPanel 
> and a JavaFX app + SwingNode -- worked for me on my local build after 
> restoring that file. Some additional testing (necessarily limited to 
> GTK
> 2 until the FX backport for GTK 3 is done) might be needed.
>
> -- Kevin
>
>
> On 9/5/2018 2:35 PM, Sergey Bylokhov wrote:
>> HI, Pankaj.
>> Can you please recheck that FX<-->Swing interop still works? Probably 
>> there are some other than GThreadHelper issues
>>
>> On 05/09/2018 11:44, Pankaj Bansal wrote:
>>> Hello Kevin,
>>>
>>> Thanks for pointing it out. I will remove this fix for now. I hope 
>>> its ok, if I create new webrev when I get some more comments here.
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>> *From:*Kevin Rushforth
>>> *Sent:* Wednesday, September 5, 2018 10:29 PM
>>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net; 
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing] 
>>> Conditional support for GTK 3 on Linux
>>>
>>> The backport of the following fix, which removes 
>>> sun.misc.GThreadHelper, will break all FX interop applications, even 
>>> if GTK2 is used:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire 
>>> sun.misc.GThreadHelper
>>>
>>> The FX GTK port still uses that class, so the class needs to be left 
>>> in until after the FX support for GTK 3 has been backported.
>>>
>>> -- Kevin
>>>
>>>
>>> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>>>
>>>  ??? Hi All,
>>>
>>>  ??? Please review the patch for 8u-dev backport for JDK-8145547. It 
>>> adds
>>>  ??? conditional support for gtk3.
>>>
>>>  ??? The original fix does not apply cleanly as few changes were 
>>> done in
>>>  ??? jdk9 before the gtk3 support was added, major once being
>>> JDK-8025815
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8014212> and
>>> JDK-8137571
>>>  ??? <https://bugs.openjdk.java.net/browse/JDK-8137571>
>>>
>>>  ??? Along with the enhancement, following bug fixes have also been
>>>  ??? included in the backport webrev
>>>
>>>  ??? 1.https://bugs.openjdk.java.net/browse/JDK-8155772:
>>> gtk3_interface.c
>>>  ??? compilation error on Ubuntu 12.10
>>>
>>>  ??? 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547 
>>> breaks
>>>  ??? AIX and and uses RTLD_NOLOAD incorrectly
>>>
>>>  ??? 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>>>  ??? fails for GTK3 if no GTK2 available
>>>
>>>  ??? 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>>>  ??? [AWT/Swing] Conditional support for GTK 3 on Linux
>>>
>>>  ??? 5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>>>  ??? AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>>>  ??? version when jdk.gtk.version=3
>>>
>>>  ??? 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>>>  ??? displayed nothing with the option"-server -d64 -Xmixed 
>>> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>>>
>>>  ??? 7.https://bugs.openjdk.java.net/browse/JDK-8191041: 
>>> Questionable
>>>  ??? Rendering of Disabled Text in Swing GTK L&F
>>>
>>>  ??? 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>>>  ??? FileDialog Modality Tests fail on Linux due to X errors
>>>
>>>  ??? 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build 
>>> failure on
>>>  ??? Linux arm64
>>>
>>>  ??? 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>>>  ??? sun.misc.GThreadHelper
>>>
>>>  ??? 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree 
>>> Collapse
>>>  ??? Buttons Clipped Off Under GTK
>>>
>>>  ??? 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3 
>>> menus
>>>  ??? appearence similar to native.
>>>
>>>  ??? 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT] 
>>> crash in
>>>  ??? AWT_Desktop/Automated/Exceptions/BasicTest
>>>
>>>  ??? 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The 
>>> FileChooser
>>>  ??? didn't displayed large font with GTK LAF option.
>>>
>>>  ??? 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>>>  ??? SwingNode with GTK LaF
>>>
>>>  ??? 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>>>  ??? Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>>>  ??? awt_UNIXToolkit.c:132
>>>
>>>  ??? 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris 
>>> build
>>>  ??? failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>>>
>>>  ??? webrev:
>>> http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>>>
>>>  ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>
>>>  ??? JDK 9 Changeset:
>>>  ??? http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>>>
>>>  ??? I have run the related jtreg and jck tests and results are fine.
>>>
>>>  ??? Regards,
>>>
>>>  ??? Pankaj
>>>
>>


From kevin.rushforth at oracle.com  Wed Sep 12 14:48:45 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 12 Sep 2018 07:48:45 -0700
Subject: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing]
 Conditional support for GTK 3 on Linux
In-Reply-To: <728fa992-87f3-43c3-a9cb-952b67b524b8@default>
References: <6513cb44-ff8a-4a0b-bf6d-91d0103e4071@default>
 <4f2dfdf9-0198-5dba-4ab0-7a900d9d72b5@oracle.com>
 <7f658900-c5d7-4426-a64d-b9eb228120ad@default>
 <8ef28f76-655d-f498-9bf4-b645d1f59102@oracle.com>
 <f16d924e-bda1-8a07-b7a5-c9e2ff547822@oracle.com>
 <e87d0b73-693c-40fa-af44-1529dd9343d4@default>
 <38a5b001-dd1e-4105-1359-d5d5c8d0e619@oracle.com>
 <728fa992-87f3-43c3-a9cb-952b67b524b8@default>
Message-ID: <ae235937-4f92-381c-7572-4014917a6954@oracle.com>

Looks fine. Btw, you have a trailing whitespace in gtk2_interface.c that 
you need to fix before you push (jcheck will tell you about that).

-- Kevin


On 9/12/2018 5:29 AM, Pankaj Bansal wrote:
> Hi,
>
> I have found a small mistake in gtk_interface.c. I had used wrong name of gtk3 lib at line 56. I have correct the same in webrev.02.
> It is just a typo and should not have any effect on functionality. All should work the same as 01 version.
>
> Webrev:
> http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.02/
>
> Regards,
> Pankaj
>
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Saturday, September 8, 2018 1:53 AM
> To: Pankaj Bansal; Sergey Bylokhov; awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux
>
> I tested various combinations of Swing / FX interop and it all looks fine to me. I only glanced through the AWT code changes, though, but I didn't spot anything amiss.
>
> -- Kevin
>
>
> On 9/6/2018 4:35 AM, Pankaj Bansal wrote:
>> Hello Sergey/Kevin,
>>
>> I have removed the backport for https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper. I did a clean build and tried few tests for Swing-FX interop. They all run fine. I have attached the link to tests if you would like to have a look. I did run the awt and swing jtreg tests also.
>>
>> Webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.01/
>> SwingFXInteropTests:
>> http://cr.openjdk.java.net/~pbansal/gtk3_backport/SwingFXInteropTests/
>>
>> Please let me know if you would like me to do some further testing for Swing-FX interop.
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Kevin Rushforth
>> Sent: Thursday, September 6, 2018 3:29 AM
>> To: Sergey Bylokhov; Pankaj Bansal; awt-dev at openjdk.java.net;
>> swing-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> <Swing Dev> [8u-backport] JDK 8145547:
>> [AWT/Swing] Conditional support for GTK 3 on Linux
>>
>> The simple testing that I did -- one each of a Swing app + JFXPanel
>> and a JavaFX app + SwingNode -- worked for me on my local build after
>> restoring that file. Some additional testing (necessarily limited to
>> GTK
>> 2 until the FX backport for GTK 3 is done) might be needed.
>>
>> -- Kevin
>>
>>
>> On 9/5/2018 2:35 PM, Sergey Bylokhov wrote:
>>> HI, Pankaj.
>>> Can you please recheck that FX<-->Swing interop still works? Probably
>>> there are some other than GThreadHelper issues
>>>
>>> On 05/09/2018 11:44, Pankaj Bansal wrote:
>>>> Hello Kevin,
>>>>
>>>> Thanks for pointing it out. I will remove this fix for now. I hope
>>>> its ok, if I create new webrev when I get some more comments here.
>>>>
>>>> Regards,
>>>>
>>>> Pankaj Bansal
>>>>
>>>> *From:*Kevin Rushforth
>>>> *Sent:* Wednesday, September 5, 2018 10:29 PM
>>>> *To:* Pankaj Bansal; awt-dev at openjdk.java.net;
>>>> swing-dev at openjdk.java.net
>>>> *Subject:* Re: <AWT Dev> [8u-backport] JDK 8145547: [AWT/Swing]
>>>> Conditional support for GTK 3 on Linux
>>>>
>>>> The backport of the following fix, which removes
>>>> sun.misc.GThreadHelper, will break all FX interop applications, even
>>>> if GTK2 is used:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire
>>>> sun.misc.GThreadHelper
>>>>
>>>> The FX GTK port still uses that class, so the class needs to be left
>>>> in until after the FX support for GTK 3 has been backported.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 9/5/2018 12:56 AM, Pankaj Bansal wrote:
>>>>
>>>>   ??? Hi All,
>>>>
>>>>   ??? Please review the patch for 8u-dev backport for JDK-8145547. It
>>>> adds
>>>>   ??? conditional support for gtk3.
>>>>
>>>>   ??? The original fix does not apply cleanly as few changes were
>>>> done in
>>>>   ??? jdk9 before the gtk3 support was added, major once being
>>>> JDK-8025815
>>>>   ??? <https://bugs.openjdk.java.net/browse/JDK-8025815>, JDK-8014212
>>>>   ??? <https://bugs.openjdk.java.net/browse/JDK-8014212> and
>>>> JDK-8137571
>>>>   ??? <https://bugs.openjdk.java.net/browse/JDK-8137571>
>>>>
>>>>   ??? Along with the enhancement, following bug fixes have also been
>>>>   ??? included in the backport webrev
>>>>
>>>>   ??? 1.https://bugs.openjdk.java.net/browse/JDK-8155772:
>>>> gtk3_interface.c
>>>>   ??? compilation error on Ubuntu 12.10
>>>>
>>>>   ??? 2.https://bugs.openjdk.java.net/browse/JDK-8156020: 8145547
>>>> breaks
>>>>   ??? AIX and and uses RTLD_NOLOAD incorrectly
>>>>
>>>>   ??? 3.https://bugs.openjdk.java.net/browse/JDK-8156121: Fail forward"
>>>>   ??? fails for GTK3 if no GTK2 available
>>>>
>>>>   ??? 4.https://bugs.openjdk.java.net/browse/JDK-8156128: Tests for
>>>>   ??? [AWT/Swing] Conditional support for GTK 3 on Linux
>>>>
>>>>   ??? 5.https://bugs.openjdk.java.net/browse/JDK-8157827:
>>>>   ??? AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK
>>>>   ??? version when jdk.gtk.version=3
>>>>
>>>>   ??? 6.https://bugs.openjdk.java.net/browse/JDK-8160160: The menu
>>>>   ??? displayed nothing with the option"-server -d64 -Xmixed
>>>> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
>>>>
>>>>   ??? 7.https://bugs.openjdk.java.net/browse/JDK-8191041:
>>>> Questionable
>>>>   ??? Rendering of Disabled Text in Swing GTK L&F
>>>>
>>>>   ??? 8.https://bugs.openjdk.java.net/browse/JDK-8203003: Several
>>>>   ??? FileDialog Modality Tests fail on Linux due to X errors
>>>>
>>>>   ??? 9.https://bugs.openjdk.java.net/browse/JDK-8155784: Build
>>>> failure on
>>>>   ??? Linux arm64
>>>>
>>>>   ??? 10.https://bugs.openjdk.java.net/browse/JDK-8154546: Retire
>>>>   ??? sun.misc.GThreadHelper
>>>>
>>>>   ??? 11.https://bugs.openjdk.java.net/browse/JDK-8152968: JTree
>>>> Collapse
>>>>   ??? Buttons Clipped Off Under GTK
>>>>
>>>>   ??? 12.https://bugs.openjdk.java.net/browse/JDK-8160448: Make GTK3
>>>> menus
>>>>   ??? appearence similar to native.
>>>>
>>>>   ??? 13.https://bugs.openjdk.java.net/browse/JDK-8155613: [PIT]
>>>> crash in
>>>>   ??? AWT_Desktop/Automated/Exceptions/BasicTest
>>>>
>>>>   ??? 14.https://bugs.openjdk.java.net/browse/JDK-8160054: The
>>>> FileChooser
>>>>   ??? didn't displayed large font with GTK LAF option.
>>>>
>>>>   ??? 15.https://bugs.openjdk.java.net/browse/JDK-8164321: Crash of
>>>>   ??? SwingNode with GTK LaF
>>>>
>>>>   ??? 16.https://bugs.openjdk.java.net/browse/JDK-8161740: [parfait]
>>>>   ??? Memory leak in Java_sun_awt_UNIXToolkit_load_1gtk_1icon of
>>>>   ??? awt_UNIXToolkit.c:132
>>>>
>>>>   ??? 17.https://bugs.openjdk.java.net/browse/JDK-8168077: Solaris
>>>> build
>>>>   ??? failed: gtk2_interface.h typedef redeclared: GThreadFunctions
>>>>
>>>>   ??? webrev:
>>>> http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.00/>
>>>>
>>>>   ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8145547
>>>>
>>>>   ??? JDK 9 Changeset:
>>>>   ??? http://hg.openjdk.java.net/jdk9/client/jdk/rev/6d60dfa5e3f8
>>>>
>>>>   ??? I have run the related jtreg and jck tests and results are fine.
>>>>
>>>>   ??? Regards,
>>>>
>>>>   ??? Pankaj
>>>>


From krishna.addepalli at oracle.com  Thu Sep 13 19:25:40 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 13 Sep 2018 19:25:40 +0000 (UTC)
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
Message-ID: <f43916b3-285b-4054-8b32-a282f3306296@default>

Hi All, 

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681

Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/

 

Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.

The proposed solution is to have the user/developer define an environment variable "JAVA_ACCESSBRIDGE_LOGFILE" and filling with the path to the log file.

The JavaAccessBridge will read the variable, and write to the file in the path provided. 
Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180913/c082818d/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 13 21:43:10 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 13 Sep 2018 14:43:10 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
Message-ID: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>

Hello.
Please review fix for jdk12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8210693

The client code has a "com.sun.awt.SecurityWarning" class which at some 
point in the past, JDK 6u10, was used as a kind of "public" API.

During development of jdk9 it was considered that this API is not 
supported and may be removed in the future: JDK-8051640.
In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) 
and can be dropped in 12.

In the fix these things were removed:
  - com/sun/awt/SecurityWarning.java
  - The test for SecurityWarning class
  - Test groups, because SecurityWarning is the latest class in 
"com/sun/awt" package
  - The reference to "com/sun/awt" in the "default.policy"

(cc) core-libs-dev:
I am not sure who is responsible to review the change in "default.policy".


-- 
Best regards, Sergey.

From stuart.marks at oracle.com  Thu Sep 13 23:52:16 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 13 Sep 2018 16:52:16 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
Message-ID: <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>

I'd guess that security-dev would have reviewers for the change to 
default.policy. Cc'd.

s'marks

On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk12.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
> 
> The client code has a "com.sun.awt.SecurityWarning" class which at some point in 
> the past, JDK 6u10, was used as a kind of "public" API.
> 
> During development of jdk9 it was considered that this API is not supported and 
> may be removed in the future: JDK-8051640.
> In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) and can 
> be dropped in 12.
> 
> In the fix these things were removed:
>  ?- com/sun/awt/SecurityWarning.java
>  ?- The test for SecurityWarning class
>  ?- Test groups, because SecurityWarning is the latest class in "com/sun/awt" 
> package
>  ?- The reference to "com/sun/awt" in the "default.policy"
> 
> (cc) core-libs-dev:
> I am not sure who is responsible to review the change in "default.policy".
> 
> 

From mandy.chung at oracle.com  Fri Sep 14 02:20:17 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 13 Sep 2018 19:20:17 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
Message-ID: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>


On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk12.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>

Thus change looks okay to me.? This class is not exported
and so I have updated the CSR of "Implementation" scope rather
than JDK.

Mandy

> The client code has a "com.sun.awt.SecurityWarning" class which at 
> some point in the past, JDK 6u10, was used as a kind of "public" API.
>
> During development of jdk9 it was considered that this API is not 
> supported and may be removed in the future: JDK-8051640.
> In jdk11 this class was marked as "forRemoval = true" (see 
> JDK-8205588) and can be dropped in 12.
>
> In the fix these things were removed:
> ?- com/sun/awt/SecurityWarning.java
> ?- The test for SecurityWarning class
> ?- Test groups, because SecurityWarning is the latest class in 
> "com/sun/awt" package
> ?- The reference to "com/sun/awt" in the "default.policy"
>
> (cc) core-libs-dev:
> I am not sure who is responsible to review the change in 
> "default.policy".
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180913/17321d15/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 14 06:08:03 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 14 Sep 2018 11:38:03 +0530
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <f43916b3-285b-4054-8b32-a282f3306296@default>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
Message-ID: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>

One thing, since you are passing va_list as the last parameter, 
shouldn't all fprintf be actually vfprintf?

Regards
Prasanta
On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>
> Please review an enhancement for supporting the logging of Java Access 
> Bridge, so that customers/users facing problems with Accessibility can 
> turn on/off logging to debug problems with this feature.
>
> The proposed solution is to have the user/developer define an 
> environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling with 
> the path to the log file.
>
> The JavaAccessBridge will read the variable, and write to the file in 
> the path provided.
> Note that the implementation is simplistic, and doesnot have any way 
> to handle multiple applications, since it is a debug only feature.
>
> Thanks,
>
> Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/8034efb6/attachment-0001.html>

From krishna.addepalli at oracle.com  Fri Sep 14 08:52:42 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 14 Sep 2018 01:52:42 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392:
 [macosx] Cycling through windows (JFrames) does not work with keyboard
 shortcut
In-Reply-To: <50CCCC00-6102-4227-BA3B-95ED2F2AA03A@oracle.com>
References: <5d647889-373f-eee1-8ef1-bf3e9217defe@oracle.com>
 <D7CF190A-D580-49F6-9E6E-FE65014E18C8@oracle.com>
 <12f851bc-f72d-8383-fa62-f89beb1bf4b5@oracle.com>
 <12E4132D-5CAA-4D33-B9FB-D25F3221C2C5@oracle.com>
 <59cb8b03-7f95-4744-1cf0-0f926cb6c6e5@oracle.com>
 <7A51ABB6-4640-4D8B-9B76-03F2CF9FBFA8@oracle.com>
 <45a01a34-f8d5-15d2-74af-d77465e29678@oracle.com>
 <50CCCC00-6102-4227-BA3B-95ED2F2AA03A@oracle.com>
Message-ID: <432e34f8-fc80-4f6d-9d72-2e4a7110b2b3@default>

Looks fine to me!

?

Thanks,

Krishna

?

From: Dmitry Markov 
Sent: Monday, September 10, 2018 6:06 PM
To: Manajit Halder <manajit.halder at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

?

Hi Manajit,

?

No problem, I will sponsor your commit to JDK 8u once it is ready and approved.

?

Thanks,

Dmitry?





On 10 Sep 2018, at 13:19, Manajit Halder <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

?

Hi Dmitry,

Sure, I can port it to JDK 8u, but would require your help in check-in, as I don't have permission to check-in JDK 8u.

Thanks,

Manajit

?

On 09/09/18 3:35 PM, Dmitry Markov wrote:

Hi Manajit, 

?

The fix looks good to me. Can you port it to JDK 8u too, please?

?

Thanks,

Dmitry





On 7 Sep 2018, at 12:22, Manajit Halder <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

?

Hi Dmitry,

Thanks for the test scenarios. I have run all the AWT, Swing and JCK automatic (open and closed) test cases along with manual test cases related to Modal Dialog and ordering to ensure that fix doesn't cause any regression. These JCK interactive test were run "api/java_awt/interactive/ModalDialogTests.html", "api/java_awt/interactive/FileDialogTests.html", "api/java_awt/interactive/PageDialogTest.html" and "api/java_awt/interactive/WindowTest.html" (tests toFront and toBack between a window and a Frame). 

For example, manual test "open/test/jdk/java/awt/Modal/WsDisabledStyle/CloseBlocker/CloseBlocker.java" tests the scenario specified by you. Also there are many automatic test cases in "open/test/jdk/java/awt/Modal/ToBack" and "open/test/jdk/java/awt/Modal/ToFront" which tests different scenarios related to Modal Dialog and Frame/Window ordering.

Please let me know if you have any other test scenarios to be tested.

Thanks,
Manajit

On 05/09/18 4:47 PM, Dmitry Markov wrote:

Hi Manajit, 

?

Thank you for the clarification.

?

Actually I worry about the case when a window is blocked by another window or a modal dialog. We call orderAboveSiblings() for the blocker window in several places, (e.g. inside setVisible(), checkBlockingAndOrder(), etc.) and I guess some of these call might fail with the new implementation of orderAboveSiblings(), (i.e. the modal dialog might be placed behind the blocked window).

?

For example, let?s say we have the window which is blocked by the modal dialog. What will be the position of the dialog (above or behind the blocked window) once the window is activated? Please note: there are several ways to activate the window: mouse click, toFront() call, etc. Can you verify that these scenarios still work properly on the build with your fix, please?

?

Also it would be good to execute related AWT/Swing jtreg tests to ensure that nothing is broken.

?

Thanks,

Dmitry?





On 4 Sep 2018, at 18:54, Manajit Halder <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

?

Hi Dmitry,

Thanks for your reply. Please see my reply inline.

Thanks,
Manajit

?

On 01/09/18 12:02 AM, Dmitry Markov wrote:

Hi Manajit, 

?

The current implementation assumes that orderAboveSiblings() places the window in front of other windows located at the same level. The proposed fix introduces new behaviour: if the window does not have an owner and child windows it won?t be ordered, (i.e. in certain conditions the window may be obscured by other windows even after orderAboveSibling() execution). Most likely such approach will break existed functionality - some windows will be incorrectly placed behind other windows.

??? If I am not wrong windows (other than Window.Type.POPUP) are already ordered in setVisible method at line no 632 while creation. While debugging I observed that orderFront is called twice when the window is displayed for the first time (in method setVisible and in method orderAboveSiblings). Now when Key press COMMAND + ` is pressed the current window receives windowDidBecomeMain notification and which calls orderFront and also COMMAND + ` tries to order the window above. Two time ordering the window when COMMAND + ` is pressed is causing problem in case of multiple windows.



?

I am sorry, but the relationship between the original problem described in the bug, (i.e. cycling through windows issue) and implementation of orderAboveSiblings() is NOT clear. Can you explain this?

??? This issue is a regression of JDK-8169589 introduced in JDK release 8u131. 8169589 introduced new window ordering model and which has introduced the cycling through window issue.



?

Thanks,

Dmitry ?





On 31 Aug 2018, at 07:55, Manajit Halder <HYPERLINK "mailto:manajit.halder at oracle.com"manajit.halder at oracle.com> wrote:

?

Hi All,

Please review the fix for JDK12.



Bug: 
???? https://bugs.openjdk.java.net/browse/JDK-8206392


Webrev: 

??? HYPERLINK "http://cr.openjdk.java.net/%7Emhalder/8206392/webrev.00/"http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/

Fix: 

??? Window ordering is not required if the window doesn't own any other windows.

Regards,
Manajit 

?

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/9d5aafa8/attachment.html>

From krishna.addepalli at oracle.com  Fri Sep 14 09:15:17 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 14 Sep 2018 02:15:17 -0700 (PDT)
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
Message-ID: <cfdb7ac2-a519-483b-b561-e66005afef4e@default>

Thanks for the review Prasanta. Although there is not much difference between using fprintf and vfprintf, I have changed all the calls to vfprintf.

Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 11:38 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

One thing, since you are passing va_list as the last parameter, shouldn't all fprintf be actually vfprintf?

Regards
Prasanta

On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:

Hi All, 

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/

 

Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.

The proposed solution is to have the user/developer define an environment variable "JAVA_ACCESSBRIDGE_LOGFILE" and filling with the path to the log file.

The JavaAccessBridge will read the variable, and write to the file in the path provided. 
Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.

 

Thanks,

Krishna

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/d2d56cd7/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 14 09:53:25 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 14 Sep 2018 15:23:25 +0530
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
Message-ID: <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>

ok. The formatting is screwed up, needs to be rectified. Also l194, 
there should be a space before {

Regards
Prasantaa
On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:
>
> Thanks for the review Prasanta. Although there is not much difference 
> between using fprintf and vfprintf, I have changed all the calls to 
> vfprintf.
>
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/>
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, September 14, 2018 11:38 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge 
> logging and debug flags dynamically controlled
>
> One thing, since you are passing va_list as the last parameter, 
> shouldn't all fprintf be actually vfprintf?
>
> Regards
> Prasanta
>
> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>
>     Please review an enhancement for supporting the logging of Java
>     Access Bridge, so that customers/users facing problems with
>     Accessibility can turn on/off logging to debug problems with this
>     feature.
>
>     The proposed solution is to have the user/developer define an
>     environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling
>     with the path to the log file.
>
>     The JavaAccessBridge will read the variable, and write to the file
>     in the path provided.
>     Note that the implementation is simplistic, and doesnot have any
>     way to handle multiple applications, since it is a debug only feature.
>
>     Thanks,
>
>     Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/3e8c3416/attachment.html>

From krishna.addepalli at oracle.com  Fri Sep 14 10:35:35 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 14 Sep 2018 03:35:35 -0700 (PDT)
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
Message-ID: <cd619c50-2c26-41c4-98ad-1b15536ba093@default>

Thanks for the comments. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/

 

--Krishna

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 3:23 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

ok. The formatting is screwed up, needs to be rectified. Also l194, there should be a space before {

Regards
Prasantaa

On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. Although there is not much difference between using fprintf and vfprintf, I have changed all the calls to vfprintf.

Here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 11:38 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

One thing, since you are passing va_list as the last parameter, shouldn't all fprintf be actually vfprintf?

Regards
Prasanta

On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:

Hi All, 

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/

 

Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.

The proposed solution is to have the user/developer define an environment variable "JAVA_ACCESSBRIDGE_LOGFILE" and filling with the path to the log file.

The JavaAccessBridge will read the variable, and write to the file in the path provided. 
Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.

 

Thanks,

Krishna

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/65850df7/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 14 12:18:28 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 14 Sep 2018 17:48:28 +0530
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
 <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
Message-ID: <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>

one question: why nullptr is used? I see we used NULL in other places in 
this file, why cant we use the same?

Regards
Prasanta
On 14-Sep-18 4:05 PM, Krishna Addepalli wrote:
>
> Thanks for the comments. Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev02/>
>
> --Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, September 14, 2018 3:23 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge 
> logging and debug flags dynamically controlled
>
> ok. The formatting is screwed up, needs to be rectified. Also l194, 
> there should be a space before {
>
> Regards
> Prasantaa
>
> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:
>
>     Thanks for the review Prasanta. Although there is not much
>     difference between using fprintf and vfprintf, I have changed all
>     the calls to vfprintf.
>
>     Here is the new webrev:
>     http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/>
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Friday, September 14, 2018 11:38 AM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>     <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge
>     logging and debug flags dynamically controlled
>
>     One thing, since you are passing va_list as the last parameter,
>     shouldn't all fprintf be actually vfprintf?
>
>     Regards
>     Prasanta
>
>     On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>
>         Hi All,
>
>         Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>
>         Webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>
>         Please review an enhancement for supporting the logging of
>         Java Access Bridge, so that customers/users facing problems
>         with Accessibility can turn on/off logging to debug problems
>         with this feature.
>
>         The proposed solution is to have the user/developer define an
>         environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling
>         with the path to the log file.
>
>         The JavaAccessBridge will read the variable, and write to the
>         file in the path provided.
>         Note that the implementation is simplistic, and doesnot have
>         any way to handle multiple applications, since it is a debug
>         only feature.
>
>         Thanks,
>
>         Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/3adaf523/attachment.html>

From krishna.addepalli at oracle.com  Fri Sep 14 15:03:44 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 14 Sep 2018 08:03:44 -0700 (PDT)
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
 <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
 <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
Message-ID: <373333c9-648d-4df4-923c-c402a039d040@default>

Nullptr is the recommended way in modern c++. I thought of changing the other places as well, but wanted to keep the changes minimal, so left them as is.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 5:48 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

one question: why nullptr is used? I see we used NULL in other places in this file, why cant we use the same?

Regards
Prasanta

On 14-Sep-18 4:05 PM, Krishna Addepalli wrote:

Thanks for the comments. Here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/

 

--Krishna

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 3:23 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

ok. The formatting is screwed up, needs to be rectified. Also l194, there should be a space before {

Regards
Prasantaa

On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. Although there is not much difference between using fprintf and vfprintf, I have changed all the calls to vfprintf.

Here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Friday, September 14, 2018 11:38 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

 

One thing, since you are passing va_list as the last parameter, shouldn't all fprintf be actually vfprintf?

Regards
Prasanta

On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:

Hi All, 

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/

 

Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.

The proposed solution is to have the user/developer define an environment variable "JAVA_ACCESSBRIDGE_LOGFILE" and filling with the path to the log file.

The JavaAccessBridge will read the variable, and write to the file in the path provided. 
Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.

 

Thanks,

Krishna

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/7f7e3830/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Fri Sep 14 15:21:25 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 14 Sep 2018 20:51:25 +0530
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <373333c9-648d-4df4-923c-c402a039d040@default>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
 <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
 <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
 <373333c9-648d-4df4-923c-c402a039d040@default>
Message-ID: <b7ad6a48-1579-dc87-a749-871daaee1f12@oracle.com>

Then I guess you need to do a mach5 run to ensure it compiles with all 
compilers.

Regards
Prasanta
On 14-Sep-18 8:33 PM, Krishna Addepalli wrote:
>
> Nullptr is the recommended way in modern c++. I thought of changing 
> the other places as well, but wanted to keep the changes minimal, so 
> left them as is.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, September 14, 2018 5:48 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge 
> logging and debug flags dynamically controlled
>
> one question: why nullptr is used? I see we used NULL in other places 
> in this file, why cant we use the same?
>
> Regards
> Prasanta
>
> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote:
>
>     Thanks for the comments. Here is the new webrev:
>     http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev02/>
>
>     --Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Friday, September 14, 2018 3:23 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>     <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge
>     logging and debug flags dynamically controlled
>
>     ok. The formatting is screwed up, needs to be rectified. Also
>     l194, there should be a space before {
>
>     Regards
>     Prasantaa
>
>     On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:
>
>         Thanks for the review Prasanta. Although there is not much
>         difference between using fprintf and vfprintf, I have changed
>         all the calls to vfprintf.
>
>         Here is the new webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/>
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Friday, September 14, 2018 11:38 AM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>         *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access
>         Bridge logging and debug flags dynamically controlled
>
>         One thing, since you are passing va_list as the last
>         parameter, shouldn't all fprintf be actually vfprintf?
>
>         Regards
>         Prasanta
>
>         On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>
>             Hi All,
>
>             Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>
>             Webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>
>             Please review an enhancement for supporting the logging of
>             Java Access Bridge, so that customers/users facing
>             problems with Accessibility can turn on/off logging to
>             debug problems with this feature.
>
>             The proposed solution is to have the user/developer define
>             an environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and
>             filling with the path to the log file.
>
>             The JavaAccessBridge will read the variable, and write to
>             the file in the path provided.
>             Note that the implementation is simplistic, and doesnot
>             have any way to handle multiple applications, since it is
>             a debug only feature.
>
>             Thanks,
>
>             Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180914/674951c3/attachment.html>

From sean.mullan at oracle.com  Fri Sep 14 18:41:58 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Sep 2018 14:41:58 -0400
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
Message-ID: <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>

On 9/13/18 7:52 PM, Stuart Marks wrote:
> I'd guess that security-dev would have reviewers for the change to 
> default.policy. Cc'd.

The default.policy file change looks like this is not specifically 
related to this change because the jdk.desktop module no longer exists. 
I guess it is ok to include it with this change but I think someone else 
(maybe Phil Race) should double-check that is ok.

--Sean
> 
> s'marks
> 
> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>
>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>
>> During development of jdk9 it was considered that this API is not 
>> supported and may be removed in the future: JDK-8051640.
>> In jdk11 this class was marked as "forRemoval = true" (see 
>> JDK-8205588) and can be dropped in 12.
>>
>> In the fix these things were removed:
>> ??- com/sun/awt/SecurityWarning.java
>> ??- The test for SecurityWarning class
>> ??- Test groups, because SecurityWarning is the latest class in 
>> "com/sun/awt" package
>> ??- The reference to "com/sun/awt" in the "default.policy"
>>
>> (cc) core-libs-dev:
>> I am not sure who is responsible to review the change in 
>> "default.policy".
>>
>>

From krishna.addepalli at oracle.com  Fri Sep 14 18:49:53 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sat, 15 Sep 2018 00:19:53 +0530
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <b7ad6a48-1579-dc87-a749-871daaee1f12@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
 <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
 <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
 <373333c9-648d-4df4-923c-c402a039d040@default>
 <b7ad6a48-1579-dc87-a749-871daaee1f12@oracle.com>
Message-ID: <93E84CA0-9FFD-4732-9FE5-AF3A4A8EBA98@oracle.com>

But this code is windows specific. So, it shouldn?t even be compiling on other platforms / compilers.

> On 14-Sep-2018, at 8:51 PM, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> Then I guess you need to do a mach5 run to ensure it compiles with all compilers.
> 
> Regards
> Prasanta
> On 14-Sep-18 8:33 PM, Krishna Addepalli wrote:
>> Nullptr is the recommended way in modern c++. I thought of changing the other places as well, but wanted to keep the changes minimal, so left them as is.
>>  
>> Thanks,
>> Krishna
>>  
>> From: Prasanta Sadhukhan 
>> Sent: Friday, September 14, 2018 5:48 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com> <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled
>>  
>> one question: why nullptr is used? I see we used NULL in other places in this file, why cant we use the same?
>> 
>> Regards
>> Prasanta
>> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote:
>> Thanks for the comments. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev02/>
>>  
>> --Krishna
>> From: Prasanta Sadhukhan 
>> Sent: Friday, September 14, 2018 3:23 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com> <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled
>>  
>> ok. The formatting is screwed up, needs to be rectified. Also l194, there should be a space before {
>> 
>> Regards
>> Prasantaa
>> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:
>> Thanks for the review Prasanta. Although there is not much difference between using fprintf and vfprintf, I have changed all the calls to vfprintf.
>> Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/>
>>  
>> Krishna
>>  
>> From: Prasanta Sadhukhan 
>> Sent: Friday, September 14, 2018 11:38 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com> <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled
>>  
>> One thing, since you are passing va_list as the last parameter, shouldn't all fprintf be actually vfprintf?
>> 
>> Regards
>> Prasanta
>> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>> Hi All, 
>>  
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 <https://bugs.openjdk.java.net/browse/JDK-8196681>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>>  
>> Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.
>> The proposed solution is to have the user/developer define an environment variable ?JAVA_ACCESSBRIDGE_LOGFILE? and filling with the path to the log file.
>> The JavaAccessBridge will read the variable, and write to the file in the path provided. 
>> Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.
>>  
>> Thanks,
>> Krishna
>>  
>>  
>>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180915/7efd2d2a/attachment-0001.html>

From philip.race at oracle.com  Sat Sep 15 20:59:22 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 15 Sep 2018 13:59:22 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
 <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>
Message-ID: <5B9D72AA.9060507@oracle.com>

Were people mis-reading this as java.desktop ?

Yes, its fine,  this was added under 
https://bugs.openjdk.java.net/browse/JDK-8055206
and we should have removed that when jdk.desktop was backed out
under https://bugs.openjdk.java.net/browse/JDK-8173409

-phil.

On 9/14/18, 11:41 AM, Sean Mullan wrote:
> On 9/13/18 7:52 PM, Stuart Marks wrote:
>> I'd guess that security-dev would have reviewers for the change to 
>> default.policy. Cc'd.
>
> The default.policy file change looks like this is not specifically 
> related to this change because the jdk.desktop module no longer 
> exists. I guess it is ok to include it with this change but I think 
> someone else (maybe Phil Race) should double-check that is ok.
>
> --Sean
>>
>> s'marks
>>
>> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review fix for jdk12.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>>
>>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>>
>>> During development of jdk9 it was considered that this API is not 
>>> supported and may be removed in the future: JDK-8051640.
>>> In jdk11 this class was marked as "forRemoval = true" (see 
>>> JDK-8205588) and can be dropped in 12.
>>>
>>> In the fix these things were removed:
>>>   - com/sun/awt/SecurityWarning.java
>>>   - The test for SecurityWarning class
>>>   - Test groups, because SecurityWarning is the latest class in 
>>> "com/sun/awt" package
>>>   - The reference to "com/sun/awt" in the "default.policy"
>>>
>>> (cc) core-libs-dev:
>>> I am not sure who is responsible to review the change in 
>>> "default.policy".
>>>
>>>

From philip.race at oracle.com  Sat Sep 15 21:00:48 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 15 Sep 2018 14:00:48 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
Message-ID: <5B9D7300.8080207@oracle.com>

It was exported  in the past .. and it was publicly documented ..

http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html

.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.

+1

-phil.

On 9/13/18, 7:20 PM, mandy chung wrote:
>
> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>
>
> Thus change looks okay to me.  This class is not exported
> and so I have updated the CSR of "Implementation" scope rather
> than JDK.
>
> Mandy
>
>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>
>> During development of jdk9 it was considered that this API is not 
>> supported and may be removed in the future: JDK-8051640.
>> In jdk11 this class was marked as "forRemoval = true" (see 
>> JDK-8205588) and can be dropped in 12.
>>
>> In the fix these things were removed:
>>  - com/sun/awt/SecurityWarning.java
>>  - The test for SecurityWarning class
>>  - Test groups, because SecurityWarning is the latest class in 
>> "com/sun/awt" package
>>  - The reference to "com/sun/awt" in the "default.policy"
>>
>> (cc) core-libs-dev:
>> I am not sure who is responsible to review the change in 
>> "default.policy".
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180915/eaae46de/attachment.html>

From Alan.Bateman at oracle.com  Sun Sep 16 07:48:57 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Sep 2018 08:48:57 +0100
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <5B9D7300.8080207@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
 <5B9D7300.8080207@oracle.com>
Message-ID: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>

On 15/09/2018 22:00, Philip Race wrote:
> It was exported? in the past .. and it was publicly documented ..
>
> http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
>
> .. so I think Sergey was correct in his "JDK" scope.
> Implementation would be for something entirely internal.
I think Sergey's changes are okay.

The main issue with com.sun.awt API is that it tried to be both an 
exported and internal/unsupported API at the same time (it's javadoc 
reads "This class is an implementation detail and only meant for limited 
use outside of the core platform"). This doesn't work for modules. In 
addition the design principles in JEP 200 make it clear that standard 
modules should not export a non-standard package to all modules. If 
there has been extensive use of this API then I could imagine it being 
refactored and moved into a JDK-specific module but there was little 
evidence of usage. So where we ended up in JDK 9 is that the API is not 
exported. This means, as Mandy hinted, you can't compile against this 
API (at least not without --add-exports to the compiler). Existing code 
using this API will continue to run on JDK 9, 10, 11 or until the 
java.desktop module is fully encapsulated or the SecurityWarning class 
is removed. Sergey got there first.

-Alan

From prasanta.sadhukhan at oracle.com  Mon Sep 17 09:02:42 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 17 Sep 2018 14:32:42 +0530
Subject: <AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of yen
	symbol
Message-ID: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>

Hi All,

Please review a fix for an issue where
when "yen" symbol is entered from a keyboard using Romaji keyboard 
layout using "backslash" character, it was showing a "backslash" character
rather than "yen" symbol.

This is a regression of JDK-8068283 
<https://bugs.openjdk.java.net/browse/JDK-8068283> where the check to 
control JNI invocation of 
"sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from
"if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
to
if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))

Now, in this case for "yen" symbol, the utf16Length is 2 so 
InputMethodEvent is not generated, rather a KeyEvent is generated for 
"\" character.
This check was again modified for JDK-8132503 
<https://bugs.openjdk.java.net/browse/JDK-8132503> where the check for 
unichar belongs to certain unicode block is introduced

/(utf8Length > 1) && [self 
isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]/

Now, there although utf8Length is 2 the check for codepoint is complex 
or not does not take into account "unicode" currency symbols.
It only takes into account CJK symbols and punctuations and "Halfwidth 
and Fullwidth Forms' Unicode block.

Proposed fix also add "currency" symbol unicode 
[[https://www.fileformat.info/info/unicode/category/Sc/list.htm]
in the mix so that we can have InputmethodEvent generated for currency 
symbols.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191178
webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180917/7862f54f/attachment.html>

From mandy.chung at oracle.com  Mon Sep 17 15:31:47 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 17 Sep 2018 08:31:47 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
 <5B9D7300.8080207@oracle.com>
 <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>
Message-ID: <933c7bc3-5ba3-bb63-2df8-20de1a877115@oracle.com>



On 9/16/18 12:48 AM, Alan Bateman wrote:
> On 15/09/2018 22:00, Philip Race wrote:
>> It was exported? in the past .. and it was publicly documented ..
>>
>> http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html 
>>
>>
>> .. so I think Sergey was correct in his "JDK" scope.
>> Implementation would be for something entirely internal.
> I think Sergey's changes are okay.
>
> The main issue with com.sun.awt API is that it tried to be both an 
> exported and internal/unsupported API at the same time (it's javadoc 
> reads "This class is an implementation detail and only meant for 
> limited use outside of the core platform"). This doesn't work for 
> modules. In addition the design principles in JEP 200 make it clear 
> that standard modules should not export a non-standard package to all 
> modules. If there has been extensive use of this API then I could 
> imagine it being refactored and moved into a JDK-specific module but 
> there was little evidence of usage. So where we ended up in JDK 9 is 
> that the API is not exported. This means, as Mandy hinted, you can't 
> compile against this API (at least not without --add-exports to the 
> compiler). Existing code using this API will continue to run on JDK 9, 
> 10, 11 or until the java.desktop module is fully encapsulated or the 
> SecurityWarning class is removed. Sergey got there first.
>

Yes.? Since it was decided not to export com.sun.awt API (JDK-8051640), 
they are no longer supported.? Is there a CSR filed officially declaring 
com.sun.awt APIs are no longer supported? Since it's already deprecated 
for removal, it may be worth to have a release note for JDK-8205588 if 
we didn't officially declare it unsupported.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180917/2c0e8730/attachment.html>

From dmitry.markov at oracle.com  Mon Sep 17 15:52:59 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 17 Sep 2018 16:52:59 +0100
Subject: <AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of
 yen symbol
In-Reply-To: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>
References: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>
Message-ID: <19045414-FD4D-4E54-B68A-DB6428E9F435@oracle.com>

Hi Prasanta,

I think it would be wise to generate InputMethodEvent for ?Fullwidth currency symbols?, as well.

Thanks,
Dmitry 

> On 17 Sep 2018, at 10:02, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> Hi All,
> 
> Please review a fix for an issue where
> when "yen" symbol is entered from a keyboard using Romaji keyboard layout using "backslash" character, it was showing a "backslash" character 
> rather than "yen" symbol.
> 
> This is a regression of JDK-8068283 <https://bugs.openjdk.java.net/browse/JDK-8068283> where the check to control JNI invocation of "sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from 
> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
> to 
> if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))
> 
> Now, in this case for "yen" symbol, the utf16Length is 2 so InputMethodEvent is not generated, rather a KeyEvent is generated for "\" character.
> This check was again modified for JDK-8132503 <https://bugs.openjdk.java.net/browse/JDK-8132503> where the check for unichar belongs to certain unicode block is introduced
> 
> (utf8Length > 1) && [self isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]
> 
> Now, there although utf8Length is 2 the check for codepoint is complex or not does not take into account "unicode" currency symbols. 
> It only takes into account CJK symbols and punctuations and "Halfwidth and Fullwidth Forms' Unicode block.
> 
> Proposed fix also add "currency" symbol unicode [[https://www.fileformat.info/info/unicode/category/Sc/list.htm <https://www.fileformat.info/info/unicode/category/Sc/list.htm>]
> in the mix so that we can have InputmethodEvent generated for currency symbols.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191178 <https://bugs.openjdk.java.net/browse/JDK-8191178>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/ <http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/>
> 
> Regards
> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180917/06a624a5/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Sep 17 16:01:40 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 17 Sep 2018 21:31:40 +0530
Subject: <AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of
 yen symbol
In-Reply-To: <19045414-FD4D-4E54-B68A-DB6428E9F435@oracle.com>
References: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>
 <19045414-FD4D-4E54-B68A-DB6428E9F435@oracle.com>
Message-ID: <f723accd-11e7-7a7c-7477-56e4c23ed527@oracle.com>

Hi Dmitry,

I guess fullwidth currency symbols are
U+FF04 <https://www.fileformat.info/info/unicode/char/ff04/index.htm> 
FULLWIDTH DOLLAR SIGN
U+FFE1 <https://www.fileformat.info/info/unicode/char/ffe1/index.htm> 
FULLWIDTH POUND SIGN
U+FFE5 <https://www.fileformat.info/info/unicode/char/ffe5/index.htm> 
FULLWIDTH YEN SIGN
etc which are already part of this check

(codePoint >= 0xFF00) && (codePoint <= 0xFFEF)

right?

Regards
Prasanta
On 17-Sep-18 9:22 PM, Dmitry Markov wrote:
> Hi Prasanta,
>
> I think it would be wise to generate InputMethodEvent for ?Fullwidth 
> currency symbols?, as well.
>
> Thanks,
> Dmitry
>
>> On 17 Sep 2018, at 10:02, Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com 
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Please review a fix for an issue where
>> when "yen" symbol is entered from a keyboard using Romaji keyboard 
>> layout using "backslash" character, it was showing a "backslash" 
>> character
>> rather than "yen" symbol.
>>
>> This is a regression of JDK-8068283 
>> <https://bugs.openjdk.java.net/browse/JDK-8068283> where the check to 
>> control JNI invocation of 
>> "sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from
>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
>> to
>> if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))
>>
>> Now, in this case for "yen" symbol, the utf16Length is 2 so 
>> InputMethodEvent is not generated, rather a KeyEvent is generated for 
>> "\" character.
>> This check was again modified for JDK-8132503 
>> <https://bugs.openjdk.java.net/browse/JDK-8132503> where the check 
>> for unichar belongs to certain unicode block is introduced
>>
>> /(utf8Length > 1) && [self 
>> isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]/
>>
>> Now, there although utf8Length is 2 the check for codepoint is 
>> complex or not does not take into account "unicode" currency symbols.
>> It only takes into account CJK symbols and punctuations and 
>> "Halfwidth and Fullwidth Forms' Unicode block.
>>
>> Proposed fix also add "currency" symbol unicode 
>> [[https://www.fileformat.info/info/unicode/category/Sc/list.htm]
>> in the mix so that we can have InputmethodEvent generated for 
>> currency symbols.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191178
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/
>>
>> Regards
>> Prasanta
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180917/6b82e3f2/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 17 18:12:45 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Sep 2018 11:12:45 -0700
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <f43916b3-285b-4054-8b32-a282f3306296@default>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
Message-ID: <6aeb82ab-eba4-0891-f8a6-5dc134d94fe3@oracle.com>

Hi, Krishna.
Can you please recheck how this logging will work when jab code will 
print something in parallel. As far as I understand 
libwindowsaccessbridge is loaded by the JAWS and libjavaaccessbridge by 
java, is it possibly that the log file will be garbled because of two 
libraries will print in parallel?

On 13/09/2018 12:25, Krishna Addepalli wrote:
> Hi All,
> 
> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
> 
> Please review an enhancement for supporting the logging of Java Access 
> Bridge, so that customers/users facing problems with Accessibility can 
> turn on/off logging to debug problems with this feature.
> 
> The proposed solution is to have the user/developer define an 
> environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling with the 
> path to the log file.
> 
> The JavaAccessBridge will read the variable, and write to the file in 
> the path provided.
> Note that the implementation is simplistic, and doesnot have any way to 
> handle multiple applications, since it is a debug only feature.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Mon Sep 17 21:43:39 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 17 Sep 2018 14:43:39 -0700
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <6aeb82ab-eba4-0891-f8a6-5dc134d94fe3@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <6aeb82ab-eba4-0891-f8a6-5dc134d94fe3@oracle.com>
Message-ID: <A2809A3B-DF44-467A-BB1D-F664D7783CAC@oracle.com>

Hi Sergey,

Since the bug was about supporting Java Access Bridge Debugging, I have enabled logging only for Java Access Bridge. So, any log statements form Windows Access bridge are ignored.

Do you think we should enable logging for Windows Access Bridge as well?

Thanks,
Krishna

> On 17-Sep-2018, at 11:12 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Krishna.
> Can you please recheck how this logging will work when jab code will print something in parallel. As far as I understand libwindowsaccessbridge is loaded by the JAWS and libjavaaccessbridge by java, is it possibly that the log file will be garbled because of two libraries will print in parallel?
> 
> On 13/09/2018 12:25, Krishna Addepalli wrote:
>> Hi All,
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>> Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.
>> The proposed solution is to have the user/developer define an environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling with the path to the log file.
>> The JavaAccessBridge will read the variable, and write to the file in the path provided.
>> Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.
>> Thanks,
>> Krishna
> 
> 
> -- 
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Sep 17 21:52:36 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Sep 2018 14:52:36 -0700
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <A2809A3B-DF44-467A-BB1D-F664D7783CAC@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <6aeb82ab-eba4-0891-f8a6-5dc134d94fe3@oracle.com>
 <A2809A3B-DF44-467A-BB1D-F664D7783CAC@oracle.com>
Message-ID: <6a762280-2ea0-a2f5-0cd1-2999f49a4ed0@oracle.com>

Hi, Krishna.
The "Java Access Bridge" as a product includes 
WindowsAccessBridge-xx.dll and JavaAccessBridge-xx.dll.

On 17/09/2018 14:43, Krishna Addepalli wrote:
> Hi Sergey,
> 
> Since the bug was about supporting Java Access Bridge Debugging, I have enabled logging only for Java Access Bridge. So, any log statements form Windows Access bridge are ignored.
> 
> Do you think we should enable logging for Windows Access Bridge as well?
> 
> Thanks,
> Krishna
> 
>> On 17-Sep-2018, at 11:12 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Hi, Krishna.
>> Can you please recheck how this logging will work when jab code will print something in parallel. As far as I understand libwindowsaccessbridge is loaded by the JAWS and libjavaaccessbridge by java, is it possibly that the log file will be garbled because of two libraries will print in parallel?
>>
>> On 13/09/2018 12:25, Krishna Addepalli wrote:
>>> Hi All,
>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>>> Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off logging to debug problems with this feature.
>>> The proposed solution is to have the user/developer define an environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling with the path to the log file.
>>> The JavaAccessBridge will read the variable, and write to the file in the path provided.
>>> Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature.
>>> Thanks,
>>> Krishna
>>
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 17 21:56:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Sep 2018 14:56:25 -0700
Subject: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge logging and
 debug flags dynamically controlled
In-Reply-To: <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
References: <f43916b3-285b-4054-8b32-a282f3306296@default>
 <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com>
 <cfdb7ac2-a519-483b-b561-e66005afef4e@default>
 <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com>
 <cd619c50-2c26-41c4-98ad-1b15536ba093@default>
 <a8cd1081-6ff9-0d01-32a6-aacb1bdcf9d2@oracle.com>
Message-ID: <a07b3295-177d-0db7-1718-dfdc093fa088@oracle.com>

I guess that it is a good thing to use nullptr, but I think it is better 
to follow the style used in the file, and replace NULL to nullptr in the 
whole file in some separate fix.

On 14/09/2018 05:18, Prasanta Sadhukhan wrote:
> one question: why nullptr is used? I see we used NULL in other places in 
> this file, why cant we use the same?
> 
> Regards
> Prasanta
> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote:
>>
>> Thanks for the comments. Here is the new webrev: 
>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ 
>> <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev02/>
>>
>> --Krishna
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Friday, September 14, 2018 3:23 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge 
>> logging and debug flags dynamically controlled
>>
>> ok. The formatting is screwed up, needs to be rectified. Also l194, 
>> there should be a space before {
>>
>> Regards
>> Prasantaa
>>
>> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote:
>>
>>     Thanks for the review Prasanta. Although there is not much
>>     difference between using fprintf and vfprintf, I have changed all
>>     the calls to vfprintf.
>>
>>     Here is the new webrev:
>>     http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/
>>     <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev01/>
>>
>>     Krishna
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Friday, September 14, 2018 11:38 AM
>>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>     <mailto:krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>>     <mailto:awt-dev at openjdk.java.net>
>>     *Subject:* Re: <AWT Dev> RFR: [12] JDK-8196681: Java Access Bridge
>>     logging and debug flags dynamically controlled
>>
>>     One thing, since you are passing va_list as the last parameter,
>>     shouldn't all fprintf be actually vfprintf?
>>
>>     Regards
>>     Prasanta
>>
>>     On 14-Sep-18 12:55 AM, Krishna Addepalli wrote:
>>
>>         Hi All,
>>
>>         Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681
>>
>>         Webrev:
>>         http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/
>>         <http://cr.openjdk.java.net/%7Ekaddepalli/8196681/webrev00/>
>>
>>         Please review an enhancement for supporting the logging of
>>         Java Access Bridge, so that customers/users facing problems
>>         with Accessibility can turn on/off logging to debug problems
>>         with this feature.
>>
>>         The proposed solution is to have the user/developer define an
>>         environment variable ?*JAVA_ACCESSBRIDGE_LOGFILE*? and filling
>>         with the path to the log file.
>>
>>         The JavaAccessBridge will read the variable, and write to the
>>         file in the path provided.
>>         Note that the implementation is simplistic, and doesnot have
>>         any way to handle multiple applications, since it is a debug
>>         only feature.
>>
>>         Thanks,
>>
>>         Krishna
>>
> 


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Tue Sep 18 10:32:31 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Tue, 18 Sep 2018 11:32:31 +0100
Subject: <AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of
 yen symbol
In-Reply-To: <f723accd-11e7-7a7c-7477-56e4c23ed527@oracle.com>
References: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>
 <19045414-FD4D-4E54-B68A-DB6428E9F435@oracle.com>
 <f723accd-11e7-7a7c-7477-56e4c23ed527@oracle.com>
Message-ID: <597ED021-89D1-4DEB-9722-FA6B45B81B2D@oracle.com>

That?s right. The changes look good to me.

Thanks,
Dmitry

> On 17 Sep 2018, at 17:01, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> Hi Dmitry,
> I guess fullwidth currency symbols are 
> U+FF04 <https://www.fileformat.info/info/unicode/char/ff04/index.htm> FULLWIDTH DOLLAR SIGN
> U+FFE1 <https://www.fileformat.info/info/unicode/char/ffe1/index.htm> FULLWIDTH POUND SIGN
> U+FFE5 <https://www.fileformat.info/info/unicode/char/ffe5/index.htm> FULLWIDTH YEN SIGN
> etc which are already part of this check 
> (codePoint >= 0xFF00) && (codePoint <= 0xFFEF)
> right?
> 
> Regards
> Prasanta
> On 17-Sep-18 9:22 PM, Dmitry Markov wrote:
>> Hi Prasanta,
>> 
>> I think it would be wise to generate InputMethodEvent for ?Fullwidth currency symbols?, as well.
>> 
>> Thanks,
>> Dmitry 
>> 
>>> On 17 Sep 2018, at 10:02, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review a fix for an issue where
>>> when "yen" symbol is entered from a keyboard using Romaji keyboard layout using "backslash" character, it was showing a "backslash" character 
>>> rather than "yen" symbol.
>>> 
>>> This is a regression of JDK-8068283 <https://bugs.openjdk.java.net/browse/JDK-8068283> where the check to control JNI invocation of "sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from 
>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
>>> to 
>>> if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))
>>> 
>>> Now, in this case for "yen" symbol, the utf16Length is 2 so InputMethodEvent is not generated, rather a KeyEvent is generated for "\" character.
>>> This check was again modified for JDK-8132503 <https://bugs.openjdk.java.net/browse/JDK-8132503> where the check for unichar belongs to certain unicode block is introduced
>>> 
>>> (utf8Length > 1) && [self isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]
>>> 
>>> Now, there although utf8Length is 2 the check for codepoint is complex or not does not take into account "unicode" currency symbols. 
>>> It only takes into account CJK symbols and punctuations and "Halfwidth and Fullwidth Forms' Unicode block.
>>> 
>>> Proposed fix also add "currency" symbol unicode [[https://www.fileformat.info/info/unicode/category/Sc/list.htm <https://www.fileformat.info/info/unicode/category/Sc/list.htm>]
>>> in the mix so that we can have InputmethodEvent generated for currency symbols.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191178 <https://bugs.openjdk.java.net/browse/JDK-8191178>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/ <http://cr.openjdk.java.net/%7Epsadhukhan/8191178/webrev.0/>
>>> 
>>> Regards
>>> Prasanta
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180918/42146c07/attachment-0001.html>

From manajit.halder at oracle.com  Tue Sep 18 12:45:40 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 18 Sep 2018 18:15:40 +0530
Subject: <AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of
 yen symbol
In-Reply-To: <597ED021-89D1-4DEB-9722-FA6B45B81B2D@oracle.com>
References: <120c95e2-1ca4-1607-2f18-b893a9cf0fdc@oracle.com>
 <19045414-FD4D-4E54-B68A-DB6428E9F435@oracle.com>
 <f723accd-11e7-7a7c-7477-56e4c23ed527@oracle.com>
 <597ED021-89D1-4DEB-9722-FA6B45B81B2D@oracle.com>
Message-ID: <5d602fd4-9b06-0ef4-db6f-3f8b2b9a3ea3@oracle.com>

Fix looks good to me.

Regards,
Manajit

On 18/09/18 4:02 PM, Dmitry Markov wrote:
> That?s right. The changes look good to me.
>
> Thanks,
> Dmitry
>
>> On 17 Sep 2018, at 17:01, Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com 
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> Hi Dmitry,
>>
>> I guess fullwidth currency symbols are
>> U+FF04 <https://www.fileformat.info/info/unicode/char/ff04/index.htm> 
>> FULLWIDTH DOLLAR SIGN
>> U+FFE1 <https://www.fileformat.info/info/unicode/char/ffe1/index.htm> 
>> FULLWIDTH POUND SIGN
>> U+FFE5 <https://www.fileformat.info/info/unicode/char/ffe5/index.htm> 
>> FULLWIDTH YEN SIGN
>> etc which are already part of this check
>> (codePoint >= 0xFF00) && (codePoint <= 0xFFEF)
>> right?
>>
>> Regards
>> Prasanta
>> On 17-Sep-18 9:22 PM, Dmitry Markov wrote:
>>> Hi Prasanta,
>>>
>>> I think it would be wise to generate InputMethodEvent for ?Fullwidth 
>>> currency symbols?, as well.
>>>
>>> Thanks,
>>> Dmitry
>>>
>>>> On 17 Sep 2018, at 10:02, Prasanta Sadhukhan 
>>>> <prasanta.sadhukhan at oracle.com 
>>>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue where
>>>> when "yen" symbol is entered from a keyboard using Romaji keyboard 
>>>> layout using "backslash" character, it was showing a "backslash" 
>>>> character
>>>> rather than "yen" symbol.
>>>>
>>>> This is a regression of JDK-8068283 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8068283> where the check 
>>>> to control JNI invocation of 
>>>> "sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from
>>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
>>>> to
>>>> if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))
>>>>
>>>> Now, in this case for "yen" symbol, the utf16Length is 2 so 
>>>> InputMethodEvent is not generated, rather a KeyEvent is generated 
>>>> for "\" character.
>>>> This check was again modified for JDK-8132503 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8132503> where the check 
>>>> for unichar belongs to certain unicode block is introduced
>>>>
>>>> /(utf8Length > 1) && [self 
>>>> isCodePointInUnicodeBlockNeedingIMEvent:[useString 
>>>> characterAtIndex:0]]/
>>>>
>>>> Now, there although utf8Length is 2 the check for codepoint is 
>>>> complex or not does not take into account "unicode" currency symbols.
>>>> It only takes into account CJK symbols and punctuations and 
>>>> "Halfwidth and Fullwidth Forms' Unicode block.
>>>>
>>>> Proposed fix also add "currency" symbol unicode 
>>>> [[https://www.fileformat.info/info/unicode/category/Sc/list.htm]
>>>> in the mix so that we can have InputmethodEvent generated for 
>>>> currency symbols.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191178
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180918/f28dac5f/attachment.html>

From philip.race at oracle.com  Tue Sep 18 19:50:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Sep 2018 12:50:27 -0700
Subject: <AWT Dev> RFR: 8210866: Remove HPKeysym.h from JDK sources
Message-ID: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8210880
Webrev : http://cr.openjdk.java.net/~prr/8210866/

As described in the bug, we can rely on the build platform for this file,
as we do for most X11 include files. Builds pass on our core platforms.
Since this is an X11 protocol file, I expect very few people will find they
are missing this and have to install it ..

-phil.

From Sergey.Bylokhov at oracle.com  Tue Sep 18 20:14:29 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 18 Sep 2018 13:14:29 -0700
Subject: <AWT Dev> RFR: 8210866: Remove HPKeysym.h from JDK sources
In-Reply-To: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>
References: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>
Message-ID: <f1f65761-3ca1-8886-9d7c-4d6b375fb96f@oracle.com>

Looks fine.

On 18/09/2018 12:50, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210880
> Webrev : http://cr.openjdk.java.net/~prr/8210866/
> 
> As described in the bug, we can rely on the build platform for this file,
> as we do for most X11 include files. Builds pass on our core platforms.
> Since this is an X11 protocol file, I expect very few people will find they
> are missing this and have to install it ..
> 
> -phil.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Sep 18 21:49:36 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Sep 2018 14:49:36 -0700
Subject: <AWT Dev> RFR: 8210866: Remove HPKeysym.h from JDK sources
In-Reply-To: <f1f65761-3ca1-8886-9d7c-4d6b375fb96f@oracle.com>
References: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>
 <f1f65761-3ca1-8886-9d7c-4d6b375fb96f@oracle.com>
Message-ID: <c23b2c8c-2a16-63ce-04b8-980e539a5d39@oracle.com>

Thanks,

However I also need to remove the now obsolete
comment which explained why we had our own copy ..
http://cr.openjdk.java.net/~prr/8210866.1

-phil.

On 09/18/2018 01:14 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 18/09/2018 12:50, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210880
>> Webrev : http://cr.openjdk.java.net/~prr/8210866/
>>
>> As described in the bug, we can rely on the build platform for this 
>> file,
>> as we do for most X11 include files. Builds pass on our core platforms.
>> Since this is an X11 protocol file, I expect very few people will 
>> find they
>> are missing this and have to install it ..
>>
>> -phil.
>
>


From igor.ignatyev at oracle.com  Wed Sep 19 17:18:36 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 19 Sep 2018 10:18:36 -0700
Subject: <AWT Dev> RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
Message-ID: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
> 1188 lines changed: 252 ins; 591 del; 345 mod; 

Hi all,

could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.

webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac

Thanks,
-- Igor

From Sergey.Bylokhov at oracle.com  Wed Sep 19 21:19:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Sep 2018 14:19:08 -0700
Subject: <AWT Dev> RFR: 8210866: Remove HPKeysym.h from JDK sources
In-Reply-To: <c23b2c8c-2a16-63ce-04b8-980e539a5d39@oracle.com>
References: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>
 <f1f65761-3ca1-8886-9d7c-4d6b375fb96f@oracle.com>
 <c23b2c8c-2a16-63ce-04b8-980e539a5d39@oracle.com>
Message-ID: <bdf37004-100c-d52b-e3a5-51ad6a8e3246@oracle.com>

+1

On 18/09/2018 14:49, Phil Race wrote:
> Thanks,
> 
> However I also need to remove the now obsolete
> comment which explained why we had our own copy ..
> http://cr.openjdk.java.net/~prr/8210866.1
> 
> -phil.
> 
> On 09/18/2018 01:14 PM, Sergey Bylokhov wrote:
>> Looks fine.
>>
>> On 18/09/2018 12:50, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210880
>>> Webrev : http://cr.openjdk.java.net/~prr/8210866/
>>>
>>> As described in the bug, we can rely on the build platform for this 
>>> file,
>>> as we do for most X11 include files. Builds pass on our core platforms.
>>> Since this is an X11 protocol file, I expect very few people will 
>>> find they
>>> are missing this and have to install it ..
>>>
>>> -phil.
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Sep 19 21:25:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Sep 2018 14:25:41 -0700
Subject: <AWT Dev> RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
In-Reply-To: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
References: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
Message-ID: <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>

Looks fine.

On 19/09/2018 10:18, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>> 1188 lines changed: 252 ins; 591 del; 345 mod;
> 
> Hi all,
> 
> could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
> testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac
> 
> Thanks,
> -- Igor
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 20 02:13:50 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Sep 2018 19:13:50 -0700
Subject: <AWT Dev> [8u] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
Message-ID: <4962094d-be9f-42fc-0de9-aa8f29379503@oracle.com>

Hello.
Please review backport of JDK-8170937 to jdk8u-dev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
Webrev jdk8:  http://cr.openjdk.java.net/~serb/8170937/jdk8/webrev.00/
Webrev jdk12: http://cr.openjdk.java.net/~serb/8170937/webrev.03/

Small difference in jdk12 vs jdk8 exists because of:
  - https://bugs.openjdk.java.net/browse/JDK-8041592
    AWT_Mixing was not ported to jdk8, so no changes in 
FrameBorderCounter.java
  - https://bugs.openjdk.java.net/browse/JDK-8134669
    This fix was not ported to jdk8, so its code was not changed.
  - https://bugs.openjdk.java.net/browse/JDK-8137571
    The fix for HiDPI support was not ported to jdk8, so no code related 
to "scale" was changed/added.

Overall the resulted code in jdk8 is the same as in jdk12, but without 
using of scale factors.

-- 
Best regards, Sergey.

From magnus.ihse.bursie at oracle.com  Thu Sep 20 07:05:46 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Sep 2018 09:05:46 +0200
Subject: <AWT Dev> RFR: JDK-8210944 Stop replacing -MD with -MT in
 libwindowsaccessbridge
Message-ID: <c3fc2c99-fc6d-d4a1-7edd-0abc5b38984f@oracle.com>

Currently, we are filtering out -MD and replacing it with -MT when 
building libwindowsaccessbridge. This has just been a way to replicate 
the behavior of old build system, and there's no point in doing so.

In fact, it is recommended *not* to mix -MT and -MD in dlls and 
executable, as that might lead to problems (as seen in e.g. JDK-8207139).

Bug: https://bugs.openjdk.java.net/browse/JDK-8210944
Patch inline:
diff --git a/make/lib/Lib-jdk.accessibility.gmk 
b/make/lib/Lib-jdk.accessibility.gmk
--- a/make/lib/Lib-jdk.accessibility.gmk
+++ b/make/lib/Lib-jdk.accessibility.gmk
@@ -69,7 +69,7 @@
 ???????? EXTRA_SRC := common, \
 ???????? OPTIMIZATION := LOW, \
 ???????? DISABLED_WARNINGS_microsoft := 4311 4302 4312, \
-??????? CFLAGS := $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \
+??????? CFLAGS := $(CFLAGS_JDKLIB) \
 ???????????? -DACCESSBRIDGE_ARCH_$2, \
 ???????? EXTRA_HEADER_DIRS := \
 ???????????? include/bridge \

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180920/d8dfda69/attachment.html>

From dmitry.markov at oracle.com  Thu Sep 20 10:57:06 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 20 Sep 2018 11:57:06 +0100
Subject: <AWT Dev> RFR: 8210866: Remove HPKeysym.h from JDK sources
In-Reply-To: <c23b2c8c-2a16-63ce-04b8-980e539a5d39@oracle.com>
References: <dcc6c5fc-3f40-3463-7a71-5760cc077de8@oracle.com>
 <f1f65761-3ca1-8886-9d7c-4d6b375fb96f@oracle.com>
 <c23b2c8c-2a16-63ce-04b8-980e539a5d39@oracle.com>
Message-ID: <840085EC-E76F-4AA5-9D74-B3D3A1BA8924@oracle.com>

The changes look good to me.

Thanks,
Dmitry

> On 18 Sep 2018, at 22:49, Phil Race <philip.race at oracle.com> wrote:
> 
> Thanks,
> 
> However I also need to remove the now obsolete
> comment which explained why we had our own copy ..
> http://cr.openjdk.java.net/~prr/8210866.1
> 
> -phil.
> 
> On 09/18/2018 01:14 PM, Sergey Bylokhov wrote:
>> Looks fine.
>> 
>> On 18/09/2018 12:50, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210880
>>> Webrev : http://cr.openjdk.java.net/~prr/8210866/
>>> 
>>> As described in the bug, we can rely on the build platform for this file,
>>> as we do for most X11 include files. Builds pass on our core platforms.
>>> Since this is an X11 protocol file, I expect very few people will find they
>>> are missing this and have to install it ..
>>> 
>>> -phil.
>> 
>> 
> 


From erik.joelsson at oracle.com  Thu Sep 20 16:11:00 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Sep 2018 09:11:00 -0700
Subject: <AWT Dev> RFR: JDK-8210944 Stop replacing -MD with -MT in
 libwindowsaccessbridge
In-Reply-To: <c3fc2c99-fc6d-d4a1-7edd-0abc5b38984f@oracle.com>
References: <c3fc2c99-fc6d-d4a1-7edd-0abc5b38984f@oracle.com>
Message-ID: <55078867-82e6-f635-ce21-6ea88521978d@oracle.com>

Looks good.

/Erik


On 2018-09-20 00:05, Magnus Ihse Bursie wrote:
> Currently, we are filtering out -MD and replacing it with -MT when 
> building libwindowsaccessbridge. This has just been a way to replicate 
> the behavior of old build system, and there's no point in doing so.
>
> In fact, it is recommended *not* to mix -MT and -MD in dlls and 
> executable, as that might lead to problems (as seen in e.g. JDK-8207139).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210944
> Patch inline:
> diff --git a/make/lib/Lib-jdk.accessibility.gmk 
> b/make/lib/Lib-jdk.accessibility.gmk
> --- a/make/lib/Lib-jdk.accessibility.gmk
> +++ b/make/lib/Lib-jdk.accessibility.gmk
> @@ -69,7 +69,7 @@
> ???????? EXTRA_SRC := common, \
> ???????? OPTIMIZATION := LOW, \
> ???????? DISABLED_WARNINGS_microsoft := 4311 4302 4312, \
> -??????? CFLAGS := $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \
> +??????? CFLAGS := $(CFLAGS_JDKLIB) \
> ???????????? -DACCESSBRIDGE_ARCH_$2, \
> ???????? EXTRA_HEADER_DIRS := \
> ???????????? include/bridge \
>
> /Magnus


From manajit.halder at oracle.com  Fri Sep 21 11:37:05 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 21 Sep 2018 17:07:05 +0530
Subject: <AWT Dev> <AWT dev>[12] Review request for JDK-8209123: [Macosx]
 Maximized frame is resizable on Mac but not on Windows and Ubuntu
Message-ID: <65743c3f-8f90-f167-cd56-97af8d3b5c53@oracle.com>

Hi All,

Please review the fix for JDK12.



Bug:
https://bugs.openjdk.java.net/browse/JDK-8209123

<https://bugs.openjdk.java.net/browse/JDK-8206392>
Webrev: 

http://cr.openjdk.java.net/~mhalder/8209123/webrev.00/ 
<http://cr.openjdk.java.net/%7Emhalder/8209123/webrev.00/>

Fix: 

 ??? Resizibility of Frame with state MAXIMIZED_BOTH is set to false 
when Frame is resized and when Frame state is set. Resizibility of Frame 
in other states (NORMAL and ICONIFIED) is changed if the previous state 
of the frame was MAXIMIZED_BOTH otherwise it is not changed.

Changes in method setResizable()
 ?1) if setResizable passed true, then check if frame is in 
MAXIMIZED_BOTH state, if so then set setResizable to false, otherwise 
set to true.
 ?2) if setResizable passed false, then set false without checking the 
frame MAXIMIZED_BOTH state.

Changes done in method setVisible and setWindowState where Frame state 
is set:
 ?1) Before setting any state check if resizibility was changed to 
MAXIMIZED_BOTH earlier, if so then set resizibility to false.
 ?2) When Frame state is set to MAXIMIZED_BOTH then set resizibility to 
false.

JCK and Jtreg (open and close) tests executed with the change:
 ?1) All automated AWT and Swing tests.
 ?2) All manual AWT and Swing tests related to Frame, Window, JFrame and 
JWindow.

Regards, 

Manajit



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180921/7ff35e20/attachment.html>

From alexey.ivanov at oracle.com  Fri Sep 21 11:36:59 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 21 Sep 2018 12:36:59 +0100
Subject: <AWT Dev> [8u] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <4962094d-be9f-42fc-0de9-aa8f29379503@oracle.com>
References: <4962094d-be9f-42fc-0de9-aa8f29379503@oracle.com>
Message-ID: <88d1cf03-76c7-b6d0-acc3-ceb5d2d776e1@oracle.com>

Looks good to me.

Regards,
Alexey

On 20/09/2018 03:13, Sergey Bylokhov wrote:
> Hello.
> Please review backport of JDK-8170937 to jdk8u-dev.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
> Webrev jdk8: http://cr.openjdk.java.net/~serb/8170937/jdk8/webrev.00/
> Webrev jdk12: http://cr.openjdk.java.net/~serb/8170937/webrev.03/
>
> Small difference in jdk12 vs jdk8 exists because of:
> ?- https://bugs.openjdk.java.net/browse/JDK-8041592
> ?? AWT_Mixing was not ported to jdk8, so no changes in 
> FrameBorderCounter.java
> ?- https://bugs.openjdk.java.net/browse/JDK-8134669
> ?? This fix was not ported to jdk8, so its code was not changed.
> ?- https://bugs.openjdk.java.net/browse/JDK-8137571
> ?? The fix for HiDPI support was not ported to jdk8, so no code 
> related to "scale" was changed/added.
>
> Overall the resulted code in jdk8 is the same as in jdk12, but without 
> using of scale factors.
>


From alexey.ivanov at oracle.com  Fri Sep 21 21:09:18 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 21 Sep 2018 22:09:18 +0100
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <378efc00-ae1a-4e9c-861e-e563657486ce@default>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
Message-ID: <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>

Hi Shashi,

SystemIcon.java
What is the purpose of new SystemIcon class?
It's not used anywhere but the provided test. Is this class really 
needed then?
Is it supposed to become the public API for accessing system icons?
Why can't FileSystemView be used for that purpose as it was proposed in 
Semyon's review?


FileSystemView.java
 ?259????? * Icon for a file, directory, or folder as it would be 
displayed in
 ?260????? * a system file browser for the requested size.
For getXXX, it's better to start description with ?Returns?? so it 
aligns to other similar methods.
However, I see the new method follows description of getIcon(boolean).

 ?265????? * @param size width and height of the icon in pixels to be 
scaled(valid range: 1 to 256)
Why is it ?to be scaled?? I would expect to get the icon of the 
requested size. At the same time, the icon can be scaled to the 
requested size if the requested size is not available.

270???? protected Icon getSystemIcon(File f, int size) {
Can't the method be public? It was in Semyon's review.

 ?266????? * @return an icon as it would be displayed by a native file 
chooser
An icon of the requested size (possibly scaled) as?

 ?275???????? if(size > 256 || size < 1) {
 ?276???????????? return null;
 ?277???????? }
Please add space between if and the opening parenthesis.
You can throw InvalidArgumentException in this case.
Does size of 1 make any sense?


ShellFolder.java
 ?202???? /**
 ?203????? * @param size size of the icon > 0
 ?204????? * @return The icon used to display this shell folder
 ?205????? */
Can you add a short description of the purpose of this method? ?Returns 
the icon of the specified size used to display this shell folder??
A similar description can be added to the method above it:
198???? public Image getIcon(boolean getLargeIcon) {


ShellFolder2.cpp
 ?944???????????? hres = pIcon->Extract(szBuf, index, &hIcon, 0, size);
Please use NULL instead of 0. This way it's clear you pass a null 
pointer rather an integer with value of 0.

974???? const int MAX_ICON_SIZE = 128;
I also suggest increasing MAX_ICON_SIZE to 256. Otherwise I see no point 
in allowing 256 as the maximum size at Java level as you'll never have 
icon of 256?256 even thought the system may have one.


Win32ShellFolder2.java
1007???? private static Image makeIcon(long hIcon, int bsize) {
bsize has no meaning. Prasanta also asked about the name of the parameter.
I suggest using "size" for parameter, and "iconSize" for local variable.

1031???????? int size = getLargeIcon ? 32 : 16; // large icon is 32 
pixels else 16 pixels
Create constants for these magic numbers.
http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html

1080???????????????????????????????????????? return getShell32Icon(4, 
size); // pick folder icon
1081???????????????????????????????????? } else {
1082???????????????????????????????????????? return getShell32Icon(1, 
size); // pick file icon
Also create constants for 4 and 1 as Prasanta suggested.
Creating a constant costs you nothing but makes the code more readable 
without adding comments.

1113???????????? if(hIcon <= 0) {
1116???????????????? if(hIcon <= 0) {
Please add space between if and the opening parenthesis.


Win32ShellFolderManager2.java
 ?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, 
key.startsWith("shell32LargeIcon ")?
 ?383 32 : 16);
You can use constants declared for icon size in from Win32ShellFolder2 
because they're already imported:
 ? 42 import static sun.awt.shell.Win32ShellFolder2.*;

Then the code at these lines needs to be updated too:
 ?129???????????? STANDARD_VIEW_BUTTONS[iconIndex] = (size == 16)
 ?130???????????????????? ? img
 ?131???????????????????? : new MultiResolutionIconImage(16, img);

See 
http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html


SystemIconTest.java

Could you please order the imports? Your IDE would be happy to do it for 
you.
Could you also add spaces between if and the opening parenthesis?
(Or at least be consistent with it.)

58???????????? ImageIcon icon = (ImageIcon)sysIcon.getSystemIcon(file, 
size, size);
Casts should be followed by a blank space.

67???????????? else if (icon.getIconWidth() != size) {
else is redundant as the preceding if throws an exception.


Regards,
Alexey


On 04/09/2018 10:39, Shashidhara Veerabhadraiah wrote:
>
> Hi All, Please find the updated Webrev per the discussion:
>
> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.02/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.02/>
>
> Thanks and regards,
>
> Shashi
>
> *From:*Shashidhara Veerabhadraiah
> *Sent:* Monday, July 30, 2018 1:32 PM
> *To:* Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; 
> swing-dev at openjdk.java.net; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to 
> Windows Large Icons
>
> Hi Prashanta, Thanks for your review. Below are my replies:
>
> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.01/>
>
> Thanks and regards,
> Shashi
>
> *From:*Prasanta Sadhukhan
> *Sent:* Friday, July 20, 2018 3:42 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com 
> <mailto:shashidhara.veerabhadraiah at oracle.com>>; 
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; 
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons
>
> Hi Shashi,
>
> The previous review thread is too long so probably need the original 
> reviewer to take a look.
> But here are my 2 cents
>
>   * Can you please explain how the new API is supposed to be used? It
>     says "Scaled icon for a file, directory, or folder as it would be
>     displayed in a system file browser"
>
> ??? ??? ??? ??? getSystemIcon(File f, int width, int height)
> ??? ??? ??? If the specified width, height is not available, then it 
> will be scaled to available icon size, is it? I do not think the 
> javadoc captures the essence of the api thoroughly.
> ??? ??? ??? For example, if width/height asked for is 100 and we have 
> icon of 96/96 and 128/128, then what it will return, the closest size 
> 96/96 or the next positive one 128/128.
>
> */[Shashi] Yes. It will be scaled to the requested size. For the 
> example that you mentioned, it is OS dependent. Typically it will pick 
> up the higher resolution if available and scales it down to the 
> requested level. If the higher resolution icon is not available then 
> it will pick the lower one and scales it up. Hence I just happened to 
> mention it as ?scaled icon? in the explanation./*
>
>   * As per fix of /JDK-8151385/
>     <https://bugs.openjdk.java.net/browse/JDK-8151385>,
>     /MAX_ICON_SIZE=128 /was added so even if you accept width/height
>     as 256 (by your check it will still restrict icon size to 128)...
>
> ??????? 287???????? if((width > 256 || width < 1) || (height > 256 || 
> height < 1)) {
> ??????? 288???????????? System.err.println("Warning: Icon scaling may 
> be distorted");
> ??????? 289???????????? throw new IllegalArgumentException("unexpected 
> icon scaling size");
> ??????? 290???????? }
>
> ??? ??? ??? so maybe either increase MAX_ICON_SIZE or adjust your 
> check accordingly.
>
> */[Shashi] The size I have kept is in a similar scale that is 
> available with the OS. Though there is an internal limit of 128, code 
> is present to scale it to 256 if the user wants in such a way./*
>
>   * We normally do not throw unchecked exception (RuntimeException)
>     from public API, so you should consider throwing checked exception
>     instead.
>
> */[Shashi] Fixed this./*
>
>   * Also, you need to change javadoc to have @throws instead of @exception
>
> */[Shashi] Fixed this./*
>
>   * Also, it was asked, IIUC that the public API used
>     MutliResolutionImage and uses getResolutionVariants
>     <https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html#getResolutionVariants%28%29>|()
>     to select appropriate icon image or let user select it (for case
>     mentioned above, if we are not sure ourselves)|||
>
> */[Shashi] Since the icon is scaled to the levels that was requested 
> and limits are mentioned as part of Javadoc comments. Fixed in the 
> updated Webrev./*
>
> ?scaleIconImage, scaleIcon uses lot of common code so we can have a 
> common method
>
> */[Shashi] Fixed this./*
>
>   * makeIcon(long hIcon, int bsize).. I guess parameter name bsize
>     does not convey meaning, is it "bestsize"?
>
> */[Shashi] Just an alternative and no meaning for that./*
>
> ?int size = getLargeIcon ? 32 : 16; and also in 
> Win32ShellFolderManager2. java probably you can have constants for 
> these 2 number
> ?Win32ShellFolderManager2
> ?1118???????????????????????? return getShell32Icon(4, size);
> ?1119???????????????????? } else {
> ?1120???????????????????????? return getShell32Icon(1, size);
>
> You should use constant to be more readable FILE_ICON_ID = 1; 
> FOLDER_ICON_ID = 4;
>
> */[Shashi] For the constants, I have newly added some comments 
> explaining that magic number. Adding a new constant is not worth as it 
> is used only once!!/*
>
> Regards
> Prasanta
>
> On 7/20/2018 12:02 PM, Shashidhara Veerabhadraiah wrote:
>
>     Hi All, Please review a fix for the below bug.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8182043
>
>     Webrev:
>     http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.00/>
>
>     History: This fix is derived from an earlier fix proposed under
>     this mail thread:
>     http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html.
>     Thanks to Semyon for that trial and part of this solution is
>     continued from where it was left off.
>
>     Solution details: Large system icons were not able to be extracted
>     because of sun package internal classes are not exposed anymore.
>     This change adds a new api to get access to those icons.
>
>     Thanks and regards,
>
>     Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180921/d9b1ae9a/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Fri Sep 21 21:43:09 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 21 Sep 2018 14:43:09 -0700
Subject: <AWT Dev> [12] Review Request: 8210286 Drop of sun.awt.HToolkit
 class
In-Reply-To: <26981c6e-9237-b8c8-574f-49fa0d49a46e@oracle.com>
References: <26981c6e-9237-b8c8-574f-49fa0d49a46e@oracle.com>
Message-ID: <27461e1f-49ce-77dc-fbc6-696d1501952b@oracle.com>

Any volunteers for review? =)

On 03/09/2018 16:36, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 12.
> 
> This class was used as a headless toolkit for embedded purposes.
>  ?- It was added in the JDK-7030063
>  ?- Its usage was removed in JDK-8140723 and JDK-8025673.
> 
> The usage of strings "sun.awt.HToolkit" and "javaplugin.version" in 
> GraphicsEnvironment were also dropped, because both are never use.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210286
> Webrev: http://cr.openjdk.java.net/~serb/8210286/webrev.00
> 


-- 
Best regards, Sergey.

From igor.ignatyev at oracle.com  Fri Sep 21 21:53:54 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 21 Sep 2018 14:53:54 -0700
Subject: <AWT Dev> RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
In-Reply-To: <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>
References: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
 <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>
Message-ID: <B93C7069-0EB2-45BF-8267-F3247A56E889@oracle.com>

Hi Sergey,

thanks for your review.

-- Igor

> On Sep 19, 2018, at 2:25 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 19/09/2018 10:18, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>>> 1188 lines changed: 252 ins; 591 del; 345 mod;
>> Hi all,
>> could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
>> testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac
>> Thanks,
>> -- Igor
> 
> 
> -- 
> Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Fri Sep 21 22:22:29 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 21 Sep 2018 15:22:29 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
Message-ID: <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>

Hi Alexey, Thanks for your review and below is the new Webrev.

http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.03/

?

Please see below for inline comments.

?

Thanks and regards,
Shashi

?

From: Alexey Ivanov 
Sent: Friday, September 21, 2018 2:09 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev <swing-dev at openjdk.java.net>; awt-dev <awt-dev at openjdk.java.net>
Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

?

Hi Shashi,

SystemIcon.java
What is the purpose of new SystemIcon class?
It's not used anywhere but the provided test. Is this class really needed then?
Is it supposed to become the public API for accessing system icons?
Why can't FileSystemView be used for that purpose as it was proposed in Semyon's review?
[Shashi] SystemIcon is going to be the front face to access the icons and that is the purpose of this class. The reason for choosing this is that FileSystemView class can be used internally and did not wanted to expose it externally too. Externally exposing may cause certain restriction in maintaining the classes hence the indirection.

FileSystemView.java
?259????? * Icon for a file, directory, or folder as it would be displayed in
?260????? * a system file browser for the requested size.
For getXXX, it's better to start description with "Returns." so it aligns to other similar methods.
However, I see the new method follows description of getIcon(boolean).

[Shashi] Because as you said rightly it follows the getIcon(boolean)

?265????? * @param size width and height of the icon in pixels to be scaled(valid range: 1 to 256)
Why is it "to be scaled"? I would expect to get the icon of the requested size. At the same time, the icon can be scaled to the requested size if the requested size is not available.

[Shashi] User has no restriction of mentioning any size but the platform may have a limitation of size. Since we are supporting a set of different versions of platforms, platform may limit the size of the icon to a particular size, in which case it will be scaled to the user requested size.

270???? protected Icon getSystemIcon(File f, int size) {
Can't the method be public? It was in Semyon's review.

[Shashi] Because of the indirection, this method can stay as protected. I think it is always good to be of using protected than making everything public. Also that is the advantage of adding the SystemIcon class.



?266????? * @return an icon as it would be displayed by a native file chooser
An icon of the requested size (possibly scaled) as.

?275???????? if(size > 256 || size < 1) {
?276???????????? return null;
?277???????? }
Please add space between if and the opening parenthesis.
You can throw InvalidArgumentException in this case.
Does size of 1 make any sense?

[Shashi] Done. I can only say that 0 does not make sense. Check is to see that it is not less than 1.


ShellFolder.java
?202???? /**
?203????? * @param size size of the icon > 0
?204????? * @return The icon used to display this shell folder
?205????? */
Can you add a short description of the purpose of this method? "Returns the icon of the specified size used to display this shell folder"?
A similar description can be added to the method above it:
198???? public Image getIcon(boolean getLargeIcon) {

[Shashi] Updated. Thank you.


ShellFolder2.cpp
?944???????????? hres = pIcon->Extract(szBuf, index, &hIcon, 0, size);
Please use NULL instead of 0. This way it's clear you pass a null pointer rather an integer with value of 0.

[Shashi] Updated.



974???? const int MAX_ICON_SIZE = 128;
I also suggest increasing MAX_ICON_SIZE to 256. Otherwise I see no point in allowing 256 as the maximum size at Java level as you'll never have icon of 256?256 even thought the system may have one.

[Shashi] Per me, the problem is that since we support certain older versions of the platforms, it should not cause an exception at the native level. If everyone agrees for the change then we can change that.


Win32ShellFolder2.java
1007???? private static Image makeIcon(long hIcon, int bsize) {
bsize has no meaning. Prasanta also asked about the name of the parameter.
I suggest using "size" for parameter, and "iconSize" for local variable.

[Shashi] Updated.



1031???????? int size = getLargeIcon ? 32 : 16; // large icon is 32 pixels else 16 pixels
Create constants for these magic numbers.
http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html

[Shashi] Updated.



1080???????????????????????????????????????? return getShell32Icon(4, size); // pick folder icon
1081???????????????????????????????????? } else {
1082???????????????????????????????????????? return getShell32Icon(1, size); // pick file icon
Also create constants for 4 and 1 as Prasanta suggested.
Creating a constant costs you nothing but makes the code more readable without adding comments.

[Shashi] But my view is that if we start doing for every immediate value, then creation of the object and assignment may have some implications. If it is used more than once, yes definitely create the constant. Please let me know if you think otherwise. This I follow it as a standard by practice. 



1113???????????? if(hIcon <= 0) {
1116???????????????? if(hIcon <= 0) {
Please add space between if and the opening parenthesis.

[Shashi] Updated.


Win32ShellFolderManager2.java
?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, key.startsWith("shell32LargeIcon ")?
?383???????????????????????????????????????????????????????????????? 32 : 16);
You can use constants declared for icon size in from Win32ShellFolder2 because they're already imported:
? 42 import static sun.awt.shell.Win32ShellFolder2.*;

[Shashi] Updated.



Then the code at these lines needs to be updated too:
?129???????????? STANDARD_VIEW_BUTTONS[iconIndex] = (size == 16)
?130???????????????????? ? img
?131???????????????????? : new MultiResolutionIconImage(16, img);

See http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html


SystemIconTest.java

Could you please order the imports? Your IDE would be happy to do it for you.
Could you also add spaces between if and the opening parenthesis?
(Or at least be consistent with it.)

58???????????? ImageIcon icon = (ImageIcon)sysIcon.getSystemIcon(file, size, size);
Casts should be followed by a blank space.

67???????????? else if (icon.getIconWidth() != size) {
else is redundant as the preceding if throws an exception.

[Shashi] Updated.




Regards,
Alexey



On 04/09/2018 10:39, Shashidhara Veerabhadraiah wrote:

Hi All, Please find the updated Webrev per the discussion:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.02/

?

Thanks and regards,

Shashi

?

From: Shashidhara Veerabhadraiah 
Sent: Monday, July 30, 2018 1:32 PM
To: Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

?

Hi Prashanta, Thanks for your review. Below are my replies:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.01/

?

Thanks and regards,
Shashi

?

From: Prasanta Sadhukhan 
Sent: Friday, July 20, 2018 3:42 PM
To: Shashidhara Veerabhadraiah <HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

?

Hi Shashi,

The previous review thread is too long so probably need the original reviewer to take a look.
But here are my 2 cents

Can you please explain how the new API is supposed to be used? It says "Scaled icon for a file, directory, or folder as it would be displayed in a system file browser"

??? ??? ??? ??? getSystemIcon(File f, int width, int height)
??? ??? ??? If the specified width, height is not available, then it will be scaled to available icon size, is it? I do not think the javadoc captures the essence of the api thoroughly.
??? ??? ??? For example, if width/height asked for is 100 and we have icon of 96/96 and 128/128, then what it will return, the closest size 96/96 or the next positive one 128/128.

[Shashi] Yes. It will be scaled to the requested size. For the example that you mentioned, it is OS dependent. Typically it will pick up the higher resolution if available and scales it down to the requested level. If the higher resolution icon is not available then it will pick the lower one and scales it up. Hence I just happened to mention it as 'scaled icon' in the explanation.

As per fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8151385"JDK-8151385, MAX_ICON_SIZE=128 was added so even if you accept width/height as 256 (by your check it will still restrict icon size to 128)...

??????? 287???????? if((width > 256 || width < 1) || (height > 256 || height < 1)) {
??????? 288???????????? System.err.println("Warning: Icon scaling may be distorted");
??????? 289???????????? throw new IllegalArgumentException("unexpected icon scaling size");
??????? 290???????? }

??? ??? ??? so maybe either increase MAX_ICON_SIZE or adjust your check accordingly. 

[Shashi] The size I have kept is in a similar scale that is available with the OS. Though there is an internal limit of 128, code is present to scale it to 256 if the user wants in such a way.

We normally do not throw unchecked exception (RuntimeException) from public API, so you should consider throwing checked exception instead.

[Shashi] Fixed this.

Also, you need to change javadoc to have @throws instead of @exception

[Shashi] Fixed this.

Also, it was asked, IIUC that the public API used MutliResolutionImage and uses HYPERLINK "https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html#getResolutionVariants%28%29"getResolutionVariants() to select appropriate icon image or let user select it (for case mentioned above, if we are not sure ourselves)

[Shashi] Since the icon is scaled to the levels that was requested and limits are mentioned as part of Javadoc comments. Fixed in the updated Webrev.

???????? scaleIconImage, scaleIcon uses lot of common code so we can have a common method

[Shashi] Fixed this.

makeIcon(long hIcon, int bsize).. I guess parameter name bsize does not convey meaning, is it "bestsize"?

[Shashi] Just an alternative and no meaning for that.

???????? int size = getLargeIcon ? 32 : 16; and also in Win32ShellFolderManager2. java probably you can have constants for these 2 number
???????? Win32ShellFolderManager2
???????? 1118???????????????????????? return getShell32Icon(4, size);
???????? 1119???????????????????? } else {
???????? 1120???????????????????????? return getShell32Icon(1, size);

You should use constant to be more readable FILE_ICON_ID = 1; FOLDER_ICON_ID = 4;

[Shashi] For the constants, I have newly added some comments explaining that magic number. Adding a new constant is not worth as it is used only once!!

Regards
Prasanta

On 7/20/2018 12:02 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a fix for the below bug.

?

Bug: https://bugs.openjdk.java.net/browse/JDK-8182043

?

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.00/

?

History: This fix is derived from an earlier fix proposed under this mail thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013016.html. Thanks to Semyon for that trial and part of this solution is continued from where it was left off.

?

Solution details: Large system icons were not able to be extracted because of sun package internal classes are not exposed anymore. This change adds a new api to get access to those icons.

?

Thanks and regards,

Shashi

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180921/5f72f5da/attachment-0001.html>

From krishna.addepalli at oracle.com  Fri Sep 21 22:30:58 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 21 Sep 2018 15:30:58 -0700
Subject: <AWT Dev> [12]RFR : JDK-8014503: AWT Choice implementation
 should be made consistent across platforms.
In-Reply-To: <36f40d02-c4cb-8af5-1e13-a3c3ba6a5eeb@oracle.com>
References: <a356e71e-6f9a-4f38-be69-9cd02335e23b@default>
 <15209466-11db-4269-bfb7-f69b893e3222@default>
 <6051dc45-0958-47e1-9a3e-15a33d9f8a99@default>
 <4c0f4397-c2e7-44ea-931b-141566682eb5@default>
 <167f2070-9661-47b8-8161-85fa31a8dc54@default>
 <1d5c75d2-27c5-4594-b68e-c2230b42b47a@default>
 <23e54562-2461-4f6a-818f-4cd2b0efe676@default>
 <17ddc416-4d9d-4e1c-b3df-3601905fbccd@default>
 <67531de8-9c8f-c31e-9e88-23d8483593da@oracle.com>
 <fb671548-548c-4c17-825e-ab2a04e4d003@default>
 <1ca953ed-810d-d894-9a19-15f21fd88f5d@oracle.com>
 <124fe16d-0357-4e27-9337-91292bca1e04@default>
 <36f40d02-c4cb-8af5-1e13-a3c3ba6a5eeb@oracle.com>
Message-ID: <4340EC5F-EB43-4269-B9D0-2C5EB7E98742@oracle.com>

Hi Sergey,

I have not been able to find any example of different behaviour between index based and object based logic, so I have made the changes on Mac as you suggested. Also, on Linux, I found that the Choice.java class holds a selectedIndex already, so I removed it in XChoicePeer.java, and tested it.
Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/ <http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/>

Thanks,
Krishna

> On 23-Aug-2018, at 4:34 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Krishna.
> On 20/08/2018 04:30, Krishna Addepalli wrote:
>> Yes, the behavior is not because of the fix I made. I was trying to understand the implications of the index based selection approach, and now it looks to be consistent on all the platforms.
>> On Mac, as per your suggestion, we can get the same behavior by removing the "setSelectedItem", but my question is, should I make this change or keep the index based change, since that would keep the implementation also consistent across platforms.
> 
> Can you please provide an example which will show the difference between these two solutions.
> 
> btw initially the code in setSelectedItem(..) was added to fix the opposite bug. And current fix will skips some events which are generated to fix the opposite bug, it looks strange.
> 
>> Thanks,
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, August 14, 2018 7:52 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; Ajit Ghaisas <ajit.ghaisas at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.
>> On 13/08/2018 11:06, Krishna Addepalli wrote:
>>> The fix I propose is modeled after the code in Windows, which tracks items by their selected index. The code in Mac is storing currently selected object, which could raise the question about which object to select next, when the selected object is removed/changed.
>>> With index based approach, I see that, the index remains unchanged, even if the object at that location is removed/changed, unless it causes the index to be out of bounds.
>>> This behavior is the same across Windows, Linux and Mac.
>> I guess behavior is the same, because of the shared code in
>> Choice->remove->removeNoInvalidate
>> which selects the new element if the old selected element was removed.
>> And it is not affected by the code changed in the fix.
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180921/b6272cc0/attachment.html>

From magnus.ihse.bursie at oracle.com  Mon Sep 24 08:18:28 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 24 Sep 2018 10:18:28 +0200
Subject: <AWT Dev> RFR: JDK-8211029 Have a common set of enabled warnings
 for all native libraries
Message-ID: <a0480d41-5590-49b6-bb7a-60bd120c7568@oracle.com>

With JDK-8210988, the foundation is in place for a more systematic way 
of handling warnings across all native libraries (hotspot and the JDK 
libraries alike).

With this patch, make sure we enable all warnings equally for all 
libaries. If an individual library triggers a specific warning, disable 
it in that library.

There was a single warning from clang in awt_Font.c (due to a very 
broken cast) that was not possible to turn off (unless -Wextra was 
turned off entirely), so I fixed the code instead.

I have tested that this compiles without warnings on all standard Oracle 
build platforms/toolchains. On top of that, I've also tested a variety 
of gcc's: 4.8.5, 5.5.0, 6.4.0 and 7.3.0 (the minor versions for each 
major versions shipped by Ubuntu). I've also tested clang 5.0 on linux, 
XCode 9.2 on macosx and Solaris Studio 12.6 on solaris. Even with such 
extensive testing, the nature of this fix which is to add the flags that 
turn on a broad range of suitable warnings (like -Wall), and then 
selectively disable individual warnings on individual libraries, there's 
a certain risk that some platform/toolchain combinations that used to 
compile without warnings, now start exhibiting warnings. If this should 
happen, the short-term workaround is to use "configure 
--disable-warnings-as-errors". The medium term fix is to disable the 
problematic warning in the library in question, and the long-term 
solution is (hopefully) to fix the code.

Bug: https://bugs.openjdk.java.net/browse/JDK-8211029
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8211029-common-set-of-warnings/webrev.01

/Magnus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180924/7daa1c41/attachment.html>

From dmitry.markov at oracle.com  Mon Sep 24 08:26:39 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 24 Sep 2018 09:26:39 +0100
Subject: <AWT Dev> [12] Review Request: 8210286 Drop of sun.awt.HToolkit
 class
In-Reply-To: <27461e1f-49ce-77dc-fbc6-696d1501952b@oracle.com>
References: <26981c6e-9237-b8c8-574f-49fa0d49a46e@oracle.com>
 <27461e1f-49ce-77dc-fbc6-696d1501952b@oracle.com>
Message-ID: <53C1E68B-E0E1-4D6D-9DF0-EF9C03C90E16@oracle.com>

Looks good to me.

Thanks,
Dmitry

> On 21 Sep 2018, at 22:43, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Any volunteers for review? =)
> 
> On 03/09/2018 16:36, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 12.
>> This class was used as a headless toolkit for embedded purposes.
>>  - It was added in the JDK-7030063
>>  - Its usage was removed in JDK-8140723 and JDK-8025673.
>> The usage of strings "sun.awt.HToolkit" and "javaplugin.version" in GraphicsEnvironment were also dropped, because both are never use.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210286
>> Webrev: http://cr.openjdk.java.net/~serb/8210286/webrev.00
> 
> 
> -- 
> Best regards, Sergey.


From magnus.ihse.bursie at oracle.com  Mon Sep 24 09:00:41 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 24 Sep 2018 11:00:41 +0200
Subject: <AWT Dev> RFR: JDK-8210705 Stop exporting all symbols on macosx
Message-ID: <ed275eed-6da8-a0ed-0117-52aeaf9e79cc@oracle.com>

For historical reasons, we have exported all symbols on macosx. This was 
an issue that probably arise with the very first macosx port, and the 
complication that we then used map files with a format that Xcode did 
not support.

Now we don't use mapfiles anymore, and there's no reason to keep 
exporting all symbols on macosx. Instead, we should only export the 
public symbols, just like for all other platforms.

All platform-independent code is already properly annotated with 
JNIEXPORT, but there was a few files in libosxapp that needed some 
additional JNIEXPORTs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210705
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.01

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180924/fabdd83a/attachment.html>

From erik.joelsson at oracle.com  Mon Sep 24 15:41:47 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 24 Sep 2018 08:41:47 -0700
Subject: <AWT Dev> RFR: JDK-8211029 Have a common set of enabled
 warnings for all native libraries
In-Reply-To: <a0480d41-5590-49b6-bb7a-60bd120c7568@oracle.com>
References: <a0480d41-5590-49b6-bb7a-60bd120c7568@oracle.com>
Message-ID: <75d66a33-83df-b3b8-3ba9-4c65cffccaef@oracle.com>

Looks good.

/Erik


On 2018-09-24 01:18, Magnus Ihse Bursie wrote:
> With JDK-8210988, the foundation is in place for a more systematic way 
> of handling warnings across all native libraries (hotspot and the JDK 
> libraries alike).
>
> With this patch, make sure we enable all warnings equally for all 
> libaries. If an individual library triggers a specific warning, 
> disable it in that library.
>
> There was a single warning from clang in awt_Font.c (due to a very 
> broken cast) that was not possible to turn off (unless -Wextra was 
> turned off entirely), so I fixed the code instead.
>
> I have tested that this compiles without warnings on all standard 
> Oracle build platforms/toolchains. On top of that, I've also tested a 
> variety of gcc's: 4.8.5, 5.5.0, 6.4.0 and 7.3.0 (the minor versions 
> for each major versions shipped by Ubuntu). I've also tested clang 5.0 
> on linux, XCode 9.2 on macosx and Solaris Studio 12.6 on solaris. Even 
> with such extensive testing, the nature of this fix which is to add 
> the flags that turn on a broad range of suitable warnings (like 
> -Wall), and then selectively disable individual warnings on individual 
> libraries, there's a certain risk that some platform/toolchain 
> combinations that used to compile without warnings, now start 
> exhibiting warnings. If this should happen, the short-term workaround 
> is to use "configure --disable-warnings-as-errors". The medium term 
> fix is to disable the problematic warning in the library in question, 
> and the long-term solution is (hopefully) to fix the code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211029
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8211029-common-set-of-warnings/webrev.01
>
> /Magnus
>


From erik.joelsson at oracle.com  Mon Sep 24 15:43:03 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 24 Sep 2018 08:43:03 -0700
Subject: <AWT Dev> RFR: JDK-8210705 Stop exporting all symbols on macosx
In-Reply-To: <ed275eed-6da8-a0ed-0117-52aeaf9e79cc@oracle.com>
References: <ed275eed-6da8-a0ed-0117-52aeaf9e79cc@oracle.com>
Message-ID: <b6846827-fa27-e4bf-bee3-ec38825ec277@oracle.com>

Looks good.

/Erik


On 2018-09-24 02:00, Magnus Ihse Bursie wrote:
> For historical reasons, we have exported all symbols on macosx. This 
> was an issue that probably arise with the very first macosx port, and 
> the complication that we then used map files with a format that Xcode 
> did not support.
>
> Now we don't use mapfiles anymore, and there's no reason to keep 
> exporting all symbols on macosx. Instead, we should only export the 
> public symbols, just like for all other platforms.
>
> All platform-independent code is already properly annotated with 
> JNIEXPORT, but there was a few files in libosxapp that needed some 
> additional JNIEXPORTs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210705
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.01
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Mon Sep 24 17:33:29 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 24 Sep 2018 19:33:29 +0200
Subject: <AWT Dev> RFR: JDK-8210705 Stop exporting all symbols on macosx
In-Reply-To: <b6846827-fa27-e4bf-bee3-ec38825ec277@oracle.com>
References: <ed275eed-6da8-a0ed-0117-52aeaf9e79cc@oracle.com>
 <b6846827-fa27-e4bf-bee3-ec38825ec277@oracle.com>
Message-ID: <11e67d69-3bb8-d9b5-5731-871280bd46f3@oracle.com>


On 2018-09-24 17:43, Erik Joelsson wrote:
> Looks good.
Thanks. I realized there's one more part where we still export all 
symbols on macosx, and that's the launchers. Here's an updated webrev 
that handles them too:

http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.02

/Magnus
>
> /Erik
>
>
> On 2018-09-24 02:00, Magnus Ihse Bursie wrote:
>> For historical reasons, we have exported all symbols on macosx. This 
>> was an issue that probably arise with the very first macosx port, and 
>> the complication that we then used map files with a format that Xcode 
>> did not support.
>>
>> Now we don't use mapfiles anymore, and there's no reason to keep 
>> exporting all symbols on macosx. Instead, we should only export the 
>> public symbols, just like for all other platforms.
>>
>> All platform-independent code is already properly annotated with 
>> JNIEXPORT, but there was a few files in libosxapp that needed some 
>> additional JNIEXPORTs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210705
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.01
>>
>> /Magnus
>


From erik.joelsson at oracle.com  Mon Sep 24 18:02:16 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 24 Sep 2018 11:02:16 -0700
Subject: <AWT Dev> RFR: JDK-8210705 Stop exporting all symbols on macosx
In-Reply-To: <11e67d69-3bb8-d9b5-5731-871280bd46f3@oracle.com>
References: <ed275eed-6da8-a0ed-0117-52aeaf9e79cc@oracle.com>
 <b6846827-fa27-e4bf-bee3-ec38825ec277@oracle.com>
 <11e67d69-3bb8-d9b5-5731-871280bd46f3@oracle.com>
Message-ID: <d0fdbb8c-6286-7006-1ef7-5e02fa7d0a1c@oracle.com>

Looks even better.

/Erik


On 2018-09-24 10:33, Magnus Ihse Bursie wrote:
>
> On 2018-09-24 17:43, Erik Joelsson wrote:
>> Looks good.
> Thanks. I realized there's one more part where we still export all 
> symbols on macosx, and that's the launchers. Here's an updated webrev 
> that handles them too:
>
> http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.02 
>
>
> /Magnus
>>
>> /Erik
>>
>>
>> On 2018-09-24 02:00, Magnus Ihse Bursie wrote:
>>> For historical reasons, we have exported all symbols on macosx. This 
>>> was an issue that probably arise with the very first macosx port, 
>>> and the complication that we then used map files with a format that 
>>> Xcode did not support.
>>>
>>> Now we don't use mapfiles anymore, and there's no reason to keep 
>>> exporting all symbols on macosx. Instead, we should only export the 
>>> public symbols, just like for all other platforms.
>>>
>>> All platform-independent code is already properly annotated with 
>>> JNIEXPORT, but there was a few files in libosxapp that needed some 
>>> additional JNIEXPORTs.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210705
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8210705-stop-exporting-all-symbols-on-macosx/webrev.01
>>>
>>> /Magnus
>>
>


From philip.race at oracle.com  Mon Sep 24 18:52:48 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 24 Sep 2018 11:52:48 -0700
Subject: <AWT Dev> [12] Review Request: 8210286 Drop of sun.awt.HToolkit
 class
In-Reply-To: <53C1E68B-E0E1-4D6D-9DF0-EF9C03C90E16@oracle.com>
References: <26981c6e-9237-b8c8-574f-49fa0d49a46e@oracle.com>
 <27461e1f-49ce-77dc-fbc6-696d1501952b@oracle.com>
 <53C1E68B-E0E1-4D6D-9DF0-EF9C03C90E16@oracle.com>
Message-ID: <fe50bc16-432d-66f5-e71e-39f4370ce845@oracle.com>

+1

-phil.

On 09/24/2018 01:26 AM, Dmitry Markov wrote:
> Looks good to me.
>
> Thanks,
> Dmitry
>
>> On 21 Sep 2018, at 22:43, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Any volunteers for review? =)
>>
>> On 03/09/2018 16:36, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 12.
>>> This class was used as a headless toolkit for embedded purposes.
>>>   - It was added in the JDK-7030063
>>>   - Its usage was removed in JDK-8140723 and JDK-8025673.
>>> The usage of strings "sun.awt.HToolkit" and "javaplugin.version" in GraphicsEnvironment were also dropped, because both are never use.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210286
>>> Webrev: http://cr.openjdk.java.net/~serb/8210286/webrev.00
>>
>> -- 
>> Best regards, Sergey.


From philip.race at oracle.com  Mon Sep 24 19:02:25 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 24 Sep 2018 12:02:25 -0700
Subject: <AWT Dev> [8u] Review Request: 8170937 Swing apps are slow if
 displaying from a remote source to many local displays
In-Reply-To: <4962094d-be9f-42fc-0de9-aa8f29379503@oracle.com>
References: <4962094d-be9f-42fc-0de9-aa8f29379503@oracle.com>
Message-ID: <8783780a-fb23-137d-d3b7-7d4df45da591@oracle.com>

+1

-phil.

On 09/19/2018 07:13 PM, Sergey Bylokhov wrote:
> Hello.
> Please review backport of JDK-8170937 to jdk8u-dev.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170937
> Webrev jdk8: http://cr.openjdk.java.net/~serb/8170937/jdk8/webrev.00/
> Webrev jdk12: http://cr.openjdk.java.net/~serb/8170937/webrev.03/
>
> Small difference in jdk12 vs jdk8 exists because of:
>  - https://bugs.openjdk.java.net/browse/JDK-8041592
>    AWT_Mixing was not ported to jdk8, so no changes in 
> FrameBorderCounter.java
>  - https://bugs.openjdk.java.net/browse/JDK-8134669
>    This fix was not ported to jdk8, so its code was not changed.
>  - https://bugs.openjdk.java.net/browse/JDK-8137571
>    The fix for HiDPI support was not ported to jdk8, so no code 
> related to "scale" was changed/added.
>
> Overall the resulted code in jdk8 is the same as in jdk12, but without 
> using of scale factors.
>


From alexey.ivanov at oracle.com  Mon Sep 24 21:30:29 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 24 Sep 2018 22:30:29 +0100
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
 <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
Message-ID: <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>

Hi Shashi,

Please see my comments inline:

On 21/09/2018 23:22, Shashidhara Veerabhadraiah wrote:
>
> Hi Alexey, Thanks for your review and below is the new Webrev.
>
> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.03/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.03/>
>
> Please see below for inline comments.
>
> Thanks and regards,
> Shashi
>
> *From:*Alexey Ivanov
> *Sent:* Friday, September 21, 2018 2:09 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan 
> <prasanta.sadhukhan at oracle.com>; swing-dev 
> <swing-dev at openjdk.java.net>; awt-dev <awt-dev at openjdk.java.net>
> *Subject:* Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to 
> Windows Large Icons
>
> Hi Shashi,
>
> SystemIcon.java
> What is the purpose of new SystemIcon class?
> It's not used anywhere but the provided test. Is this class really 
> needed then?
> Is it supposed to become the public API for accessing system icons?
> Why can't FileSystemView be used for that purpose as it was proposed 
> in Semyon's review?
> */[Shashi] /*SystemIcon is going to be the front face to access the 
> icons and that is the purpose of this class. The reason for choosing 
> this is that FileSystemView class can be used internally and did not 
> wanted to expose it externally too. Externally exposing may cause 
> certain restriction in maintaining the classes hence the indirection.
>

Still, I cannot understand the rationale for a new class the only 
purpose of which is to provide public access to getSystemIcon(File, int, 
int).
FileSystemView is already a public class, and it's used internally. (I 
guess it would not have existed, if it hadn't.) It has a public method 
getSystemIcon(File). As such, extending its functionality to get access 
to larger icons seems logical. This is what the new protected 
getSystemIcon(File f, int size) does.

It can be made public to facilitate access to file icons.
After all, protected method is also a contract, it cannot be changed 
without affecting backward compatibility.

It is this new protected method that performs the task of getting the 
icon from the system.

Do we really need other methods?


278???? public File createNewFolder(File containingDir) throws IOException {
279???????? return null;
280???? }
You had to implement the abstract method from FileSystemView. It's one 
more point to make system icon available right from FileSystemView.
This implementation should rather throw an exception.


60???????? protected File file;
This field is redundant, in my opinion. It would be quite expensive to 
instantiate SystemIcon object for each file. It can safely be removed, 
then only methods which take additional File parameter will be left.
(The field could be final as it cannot be changed and should not be 
changed.)

65???? public SystemIcon() {
66???????? this.file = null;
67???? }
Should rather call this(null) constructor.

112???? public Icon getSystemIcon(int width, int height) {
Are methods with width / height parameters needed? Icons are usually square.

You repeat checks if f is null, width and height checks in each and 
every method. I guess parameter validation could be extract into a 
separate method. You will avoid lots of cope duplication.

Since it's a completely new API, I suggest throwing 
IllegalArgumentException with appropriate message in the cases where a 
parameter (file, width and height) fails validation.

210???????? int size;
211???????? if(width > height) {
212???????????? size = width;
213???????? } else {
214???????????? size = height;
215???????? }
This code can be simplified to
int size = Math.max(width, height);
Concise and clear.
A helper method which validates the parameters could also return this 
value. Thus, again, avoiding code duplication among many methods in this 
class.


There are lots of tabs in this file. Tabs must be replaced with spaces.
if's are inconsistent throughout the code: some are with space, some are 
without. Please add the space everyone to align with Java Code Conventions.
Please also sort the imports and remove unused ones.


> FileSystemView.java
> ?259????? * Icon for a file, directory, or folder as it would be 
> displayed in
> ?260????? * a system file browser for the requested size.
> For getXXX, it's better to start description with ?Returns?? so it 
> aligns to other similar methods.
> However, I see the new method follows description of getIcon(boolean).
>
> */[Shashi] /*Because as you said rightly it follows the getIcon(boolean)
>

Okay.
Is it possible to update documentation to the existing getSystemIcon(File)?
Should I file a separate bug to update the documentation?

Documentation also references a non-public class ShellFolder. Should 
this reference be removed from documentation as the access to non-public 
classes is restricted? It does not add much value.

> ?265????? * @param size width and height of the icon in pixels to be 
> scaled(valid range: 1 to 256)
> Why is it ?to be scaled?? I would expect to get the icon of the 
> requested size. At the same time, the icon can be scaled to the 
> requested size if the requested size is not available.
>
> */[Shashi] /*User has no restriction of mentioning any size but the 
> platform may have a limitation of size. Since we are supporting a set 
> of different versions of platforms, platform may limit the size of the 
> icon to a particular size, in which case it will be scaled to the user 
> requested size.
>

I understand that. However, I think the suggested description does not 
convey the meaning correctly.
The method will return the icon of the requested size, won't it?
So the correct description is:
@param size width and height of the icon in pixels (valid range: 1 to 256)

The fact the returned icon may be scaled if the requested size is not 
available must be described in the method documentation as well as in 
@return line:
@return an icon of the requested size (possibly scaled) as it would be 
displayed by a native file chooser

> 270 protected Icon getSystemIcon(File f, int size) {
> Can't the method be public? It was in Semyon's review.
>
> */[Shashi] /*Because of the indirection, this method can stay as 
> protected. I think it is always good to be of using protected than 
> making everything public. Also that is the advantage of adding the 
> SystemIcon class.
>

Sorry I don't see any advantage of having SystemIcon class over making 
this method public as I outlined above.

> ?266????? * @return an icon as it would be displayed by a native file 
> chooser
> An icon of the requested size (possibly scaled) as?
>
> ?275???????? if(size > 256 || size < 1) {
> ?276???????????? return null;
> ?277???????? }
> Please add space between if and the opening parenthesis.
> You can throw InvalidArgumentException in this case.
> Does size of 1 make any sense?
>
> */[Shashi] /*Done. I can only say that 0 does not make sense. Check is 
> to see that it is not less than 1.
>

What about throwing InvalidArgumentException when size parameter is invalid?

I understand that check is to make sure size is at least 1. However, 
icon of 1 pixel size does not make any sense. Should the minimum be a 
more sensible of 4?
It's a concern for discussion.

>
>
> ShellFolder.java
> ?202???? /**
> ?203????? * @param size size of the icon > 0
> ?204????? * @return The icon used to display this shell folder
> ?205????? */
> Can you add a short description of the purpose of this method? 
> ?Returns the icon of the specified size used to display this shell 
> folder??
> A similar description can be added to the method above it:
> 198???? public Image getIcon(boolean getLargeIcon) {
>
> */[Shashi] /*Updated. Thank you.
>

Thank you for updating @return clause of the Javadoc.
My intention was to add a generic description of the method as well:
202???? /**
202????? * Returns the icon of the specified size used to display this 
shell folder.
202????? *
203????? * @param size size of the icon > 0
204????? * @return The icon used to display this shell folder
205????? */

Such description could also be added to method above getIcon(boolean 
getLargeIcon), at line 198.

Should the range of size parameter be specified? For example, 1?256 as 
in FileSystemView.

> ShellFolder2.cpp
> ?944???????????? hres = pIcon->Extract(szBuf, index, &hIcon, 0, size);
> Please use NULL instead of 0. This way it's clear you pass a null 
> pointer rather an integer with value of 0.
>
> */[Shashi] /*Updated.*//*
>
>
>
> 974???? const int MAX_ICON_SIZE = 128;
> I also suggest increasing MAX_ICON_SIZE to 256. Otherwise I see no 
> point in allowing 256 as the maximum size at Java level as you'll 
> never have icon of 256?256 even thought the system may have one.*//*
>
> */[Shashi] /*Per me, the problem is that since we support certain 
> older versions of the platforms, it should not cause an exception at 
> the native level. If everyone agrees for the change then we can change 
> that.
>

This concern was raised in the previous review too:
http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013115.html

I think it's safe to update the value of MAX_ICON_SIZE to 256. The 
oldest supported version of Windows is Windows 7 which supports 256?256 
icons.
Windows XP used icons up to 48?48, but it does not imply the API does 
not allow loading icon of larger size. Both 128 and 256 should be tested 
on Windows XP if JDK still runs on it.

>
>
> Win32ShellFolder2.java
> 1007???? private static Image makeIcon(long hIcon, int bsize) {
> bsize has no meaning. Prasanta also asked about the name of the parameter.
> I suggest using "size" for parameter, and "iconSize" for local variable.
>
> */[Shashi] /*Updated.
>
>
>
> 1031???????? int size = getLargeIcon ? 32 : 16; // large icon is 32 
> pixels else 16 pixels
> Create constants for these magic numbers.
> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html 
> <http://cr.openjdk.java.net/%7Essadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html>
>
> */[Shashi] /*Updated.
>
>
>
> 1080???????????????????????????????????????? return getShell32Icon(4, 
> size); // pick folder icon
> 1081???????????????????????????????????? } else {
> 1082???????????????????????????????????????? return getShell32Icon(1, 
> size); // pick file icon
> Also create constants for 4 and 1 as Prasanta suggested.
> Creating a constant costs you nothing but makes the code more readable 
> without adding comments.
>
> */[Shashi] /*But my view is that if we start doing for every immediate 
> value, then creation of the object and assignment may have some 
> implications. If it is used more than once, yes definitely create the 
> constant. Please let me know if you think otherwise. This I follow it 
> as a standard by practice.
>

Primitive type constants do not have any performance penalty as they're 
resolved at compile time.
There's no difference if you write getShell32Icon(FOLDER_ICON_INDEX, 
size) or getShell32Icon(4, size). Yet the former is much clearer, isn't it?

With the constants, the if expression could be replaced with the 
conditional operator:

if(hIcon <= 0) {
 ??? return getShell32Icon(isDirectory() ? FOLDER_ICON_INDEX : 
FILE_ICON_INDEX, size);
}


I agree not every number in code should be defined as a constant. Yet 
I'm for using constants in this particular piece of code.

These values are used at least twice in Win32ShellFolder2.java: lines 
1081?1085 and 1119?1123.


1138???????? Image icon = makeIcon(hIcon, 32);
Now should use LARGE_ICON_SIZE.

> 1113 if(hIcon <= 0) {
> 1116???????????????? if(hIcon <= 0) {
> Please add space between if and the opening parenthesis.
>
> */[Shashi]/*Updated.
>

1078???????????????????????????? if(hIcon <= 0) {
1081???????????????????????????????? if(hIcon <= 0) {
These (in the method above) could also be updated.

> Win32ShellFolderManager2.java
> ?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, 
> key.startsWith("shell32LargeIcon ")?
> ?383???????????????????????????????????????????????????????????????? 
> 32 : 16);
> You can use constants declared for icon size in from Win32ShellFolder2 
> because they're already imported:
> ? 42 import static sun.awt.shell.Win32ShellFolder2.*;
>
> */[Shashi] /*Updated.
>

 ?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, 
key.startsWith("shell32LargeIcon ")?
 ?383 LARGE_ICON_SIZE : SMALL_ICON_SIZE);

May I suggest updating formatting to:
 ??????????????????? return Win32ShellFolder2.getShell32Icon(i,
 ??????????????????????????? key.startsWith("shell32LargeIcon ") ? 
LARGE_ICON_SIZE : SMALL_ICON_SIZE);
or even
 ??????????????????? return Win32ShellFolder2.getShell32Icon(i,
 ??????????????????????????? key.startsWith("shell32LargeIcon ") ? 
LARGE_ICON_SIZE
 ??????????????????????????????????????????????????????????????? : 
SMALL_ICON_SIZE);
(where : aligns with ?)

>
> Then the code at these lines needs to be updated too:
> ?129???????????? STANDARD_VIEW_BUTTONS[iconIndex] = (size == 16)
> ?130???????????????????? ? img
> ?131???????????????????? : new MultiResolutionIconImage(16, img);
>
> See 
> http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html 
> <http://cr.openjdk.java.net/%7Essadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html>
>
>
> SystemIconTest.java
>
> Could you please order the imports? Your IDE would be happy to do it 
> for you.
> Could you also add spaces between if and the opening parenthesis?
> (Or at least be consistent with it.)
>
> 58???????????? ImageIcon icon = (ImageIcon)sysIcon.getSystemIcon(file, 
> size, size);
> Casts should be followed by a blank space.
>
> 67???????????? else if (icon.getIconWidth() != size) {
> else is redundant as the preceding if throws an exception.
>
> */[Shashi] /*Updated.
>

Could you please organize imports?
There are only three classes used.

41???????????? System.out.println("Windows detected: will run sytem 
icons test");
typo: system

Since the test is Windows-specific, it can be declared using @requires 
tag of JTreg:
@requires os.family == "windows"


Regards,
Alexey

>
>
>
> Regards,
> Alexey
>
> *//*
>
> On 04/09/2018 10:39, Shashidhara Veerabhadraiah wrote:
>
>     Hi All, Please find the updated Webrev per the discussion:
>
>     http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.02/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.02/>
>
>     Thanks and regards,
>
>     Shashi
>
>
>     <SNIP>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180924/306af1bd/attachment-0001.html>

From alexey.ivanov at oracle.com  Tue Sep 25 22:05:28 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 25 Sep 2018 23:05:28 +0100
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
 <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
 <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
Message-ID: <cf9c026a-1f38-8292-ef03-54dda1cae943@oracle.com>

Hi Shashi,

Would you please update the copyright year in the modified files?

Regards,
Alexey

On 24/09/2018 22:30, Alexey Ivanov wrote:
> Hi Shashi,
>
> Please see my comments inline:
>
> On 21/09/2018 23:22, Shashidhara Veerabhadraiah wrote:
>>
>> Hi Alexey, Thanks for your review and below is the new Webrev.
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.03/ 
>> <http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.03/>
>>
>> Please see below for inline comments.
>>
>> Thanks and regards,
>> Shashi
>>
>>
>> <SNIP>

From philip.race at oracle.com  Wed Sep 26 18:23:49 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 26 Sep 2018 11:23:49 -0700
Subject: <AWT Dev> RFR: 8210886: Remove references in xwindows.md to
	non-existent files.
Message-ID: <2c1a55e8-7748-700c-5303-a43dbfc77cac@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8210886
webrev: http://cr.openjdk.java.net/~prr/8210886/

the legal file xwindows.md gives attribution for several source files
from the X11 distribution which in fact are not present anywhere.
Some really ancient (1.5 ?) version of Oracle JDK had some of them
and extitil.h was removed during the JDK 9 cycle since it was unused
but that didn't stop it being listed in the legal file.

-phil.



From bourges.laurent at gmail.com  Thu Sep 27 07:26:50 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 27 Sep 2018 09:26:50 +0200
Subject: <AWT Dev> OpenJdk11-28-EA JDialog hanging
Message-ID: <CAKjRUT5wW5UVY9d3RiDWXoCW-qDj+6-uksVP-G8uPYVJKGhu7Q@mail.gmail.com>

Any progress on this bug, krishna ?

At least could you explain how SequencedEvent should be processed when
multiple AppContexts are present ?

I could help but I have no clue what's going on ... I observed multiple
several EDT, AppContexts, awt events, it is very complicated to understand
such event handling.

Cheers,
Laurent

Le jeu. 6 sept. 2018 ? 18:02, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi Krishna,
>
> Le jeu. 6 sept. 2018 ? 16:08, Krishna Addepalli <
> krishna.addepalli at oracle.com> a ?crit :
>
>> Hi Laurent,
>>
>> Thanks for providing the test case. I was able to reproduce the issue.
>> Glad to know that you found a workaround, as this issue is a bit tricky to
>> fix.
>>
> Great.
>
> Meanwhile, I?m looking into fixing this issue, and your test case greatly
>> helps me toward finding the fix faster.
>>
>
> I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but
> I got no clues, very tricky.
>
> Good luck,
> Laurent
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180927/d0261be2/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 27 08:32:27 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Sep 2018 01:32:27 -0700
Subject: <AWT Dev> RFR: 8210886: Remove references in xwindows.md to
 non-existent files.
In-Reply-To: <2c1a55e8-7748-700c-5303-a43dbfc77cac@oracle.com>
References: <2c1a55e8-7748-700c-5303-a43dbfc77cac@oracle.com>
Message-ID: <c879333f-f1c5-9c4e-3e25-8b305cab6404@oracle.com>

Looks fine.

On 26/09/2018 11:23, Phil Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8210886
> webrev: http://cr.openjdk.java.net/~prr/8210886/
> 
> the legal file xwindows.md gives attribution for several source files
> from the X11 distribution which in fact are not present anywhere.
> Some really ancient (1.5 ?) version of Oracle JDK had some of them
> and extitil.h was removed during the JDK 9 cycle since it was unused
> but that didn't stop it being listed in the legal file.
> 
> -phil.
> 
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Thu Sep 27 09:24:43 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 27 Sep 2018 14:54:43 +0530
Subject: <AWT Dev> [12] RFR JDK-8210306:Missing closing bracket in
 GridBagLayout gridwidth, gridheight description
Message-ID: <e9af80b8-c385-0ae9-873e-c3c183a43320@oracle.com>

Hi All,

Please review a doc fix for a missing closing bracket in GridBagLayout 
description
/Use //|GridBagConstraints.RELATIVE|//to specify that the component's 
display area will be from //|gridx|//to the next to the last cell in its 
row *(for */*/|gridwidth|/*/** or from //|gridy|///


diff -r d96a607e9594 
src/java.desktop/share/classes/java/awt/GridBagLayout.java
--- a/src/java.desktop/share/classes/java/awt/GridBagLayout.java Tue Sep 
18 18:32:03 2018 -0700
+++ b/src/java.desktop/share/classes/java/awt/GridBagLayout.java Thu Sep 
27 14:51:56 2018 +0530
@@ -84,7 +84,7 @@
 ? *
 ? * Use {@code GridBagConstraints.RELATIVE} to specify
 ? * that the component's display area will be from {@code gridx}
- * to the next to the last cell in its row (for {@code gridwidth}
+ * to the next to the last cell in its row (for {@code gridwidth})
 ? * or from {@code gridy} to the next to the last cell in its
 ? * column (for {@code gridheight})

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180927/9ebf480c/attachment.html>

From dmitry.markov at oracle.com  Thu Sep 27 10:09:24 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 27 Sep 2018 11:09:24 +0100
Subject: <AWT Dev> RFR: 8210886: Remove references in xwindows.md to
 non-existent files.
In-Reply-To: <2c1a55e8-7748-700c-5303-a43dbfc77cac@oracle.com>
References: <2c1a55e8-7748-700c-5303-a43dbfc77cac@oracle.com>
Message-ID: <E0EF1414-74DB-4DF3-8353-A3FB55B9CC3C@oracle.com>

Hi Phil,

The changes look good to me.

Thanks,
Dmitry 

> On 26 Sep 2018, at 19:23, Phil Race <philip.race at oracle.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8210886
> webrev: http://cr.openjdk.java.net/~prr/8210886/
> 
> the legal file xwindows.md gives attribution for several source files
> from the X11 distribution which in fact are not present anywhere.
> Some really ancient (1.5 ?) version of Oracle JDK had some of them
> and extitil.h was removed during the JDK 9 cycle since it was unused
> but that didn't stop it being listed in the legal file.
> 
> -phil.
> 
> 


From christoph.langer at sap.com  Thu Sep 27 10:34:12 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Sep 2018 10:34:12 +0000
Subject: <AWT Dev> RFR (XXS): 8211218: remove double semicolon in
 src/java.desktop/macosx/classes/sun/font/CFont.java
Message-ID: <a0b16ba78d4c40f7a00ddc69c55f5bae@sap.com>

Hi,

please review this embarrassingly trivial patch:

diff -r 2105d8064ca2 -r 677e2f308137 src/java.desktop/macosx/classes/sun/font/CFont.java
--- a/src/java.desktop/macosx/classes/sun/font/CFont.java       Thu Sep 27 14:36:33 2018 +0530
+++ b/src/java.desktop/macosx/classes/sun/font/CFont.java       Thu Sep 27 11:30:18 2018 +0100
@@ -28,7 +28,7 @@
import java.awt.Font;
import java.awt.font.FontRenderContext;
import java.awt.geom.AffineTransform;
-import java.awt.geom.GeneralPath;;
+import java.awt.geom.GeneralPath;
import java.awt.geom.Point2D;
import java.awt.geom.Rectangle2D;
import java.util.ArrayList;

It simply fixes the double semicolon after java.awt.geom.GeneralPath which causes an error in my Eclipse IDE.

Bug: https://bugs.openjdk.java.net/browse/JDK-8211218

Thank you,
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180927/fe8426c3/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 27 15:50:00 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Sep 2018 08:50:00 -0700
Subject: <AWT Dev> RFR (XXS): 8211218: remove double semicolon in
 src/java.desktop/macosx/classes/sun/font/CFont.java
In-Reply-To: <a0b16ba78d4c40f7a00ddc69c55f5bae@sap.com>
References: <a0b16ba78d4c40f7a00ddc69c55f5bae@sap.com>
Message-ID: <b8a755e8-93b6-25a6-6f01-f721300fc3f5@oracle.com>

Looks fine.

On 27/09/2018 03:34, Langer, Christoph wrote:
> Hi,
> 
> please review this embarrassingly trivial patch:
> 
> diff -r 2105d8064ca2 -r 677e2f308137 
> src/java.desktop/macosx/classes/sun/font/CFont.java
> 
> --- a/src/java.desktop/macosx/classes/sun/font/CFont.java?????? Thu Sep 
> 27 14:36:33 2018 +0530
> 
> +++ b/src/java.desktop/macosx/classes/sun/font/CFont.java?????? Thu Sep 
> 27 11:30:18 2018 +0100
> 
> @@ -28,7 +28,7 @@
> 
> import java.awt.Font;
> 
> import java.awt.font.FontRenderContext;
> 
> import java.awt.geom.AffineTransform;
> 
> -import java.awt.geom.GeneralPath;;
> 
> +import java.awt.geom.GeneralPath;
> 
> import java.awt.geom.Point2D;
> 
> import java.awt.geom.Rectangle2D;
> 
> import java.util.ArrayList;
> 
> It simply fixes the double semicolon after java.awt.geom.GeneralPath 
> which causes an error in my Eclipse IDE.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211218
> 
> Thank you,
> 
> Christoph
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 27 15:54:36 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Sep 2018 08:54:36 -0700
Subject: <AWT Dev> [12] RFR JDK-8210306:Missing closing bracket in
 GridBagLayout gridwidth, gridheight description
In-Reply-To: <e9af80b8-c385-0ae9-873e-c3c183a43320@oracle.com>
References: <e9af80b8-c385-0ae9-873e-c3c183a43320@oracle.com>
Message-ID: <394afa46-182d-08cf-dd5d-8c938d4efc3a@oracle.com>

Looks fine.

On 27/09/2018 02:24, Prasanta Sadhukhan wrote:
> Hi All,
> 
> Please review a doc fix for a missing closing bracket in GridBagLayout 
> description
> /Use //|GridBagConstraints.RELATIVE|//to specify that the component's 
> display area will be from //|gridx|//to the next to the last cell in its 
> row *(for */*/|gridwidth|/*/** or from //|gridy|///
> 
> 
> diff -r d96a607e9594 
> src/java.desktop/share/classes/java/awt/GridBagLayout.java
> --- a/src/java.desktop/share/classes/java/awt/GridBagLayout.java Tue Sep 
> 18 18:32:03 2018 -0700
> +++ b/src/java.desktop/share/classes/java/awt/GridBagLayout.java Thu Sep 
> 27 14:51:56 2018 +0530
> @@ -84,7 +84,7 @@
>  ? *
>  ? * Use {@code GridBagConstraints.RELATIVE} to specify
>  ? * that the component's display area will be from {@code gridx}
> - * to the next to the last cell in its row (for {@code gridwidth}
> + * to the next to the last cell in its row (for {@code gridwidth})
>  ? * or from {@code gridy} to the next to the last cell in its
>  ? * column (for {@code gridheight})
> 
> Regards
> Prasanta


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Fri Sep 28 08:58:43 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 28 Sep 2018 01:58:43 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large
 Icons
In-Reply-To: <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
References: <261fe40d-a8ed-4b12-9017-81fd8e9efef2@default>
 <4cc06fa7-7406-ece0-0527-46d566d701a1@oracle.com>
 <934606c2-3a79-4ae5-b041-3fa1b6a9fd99@default>
 <378efc00-ae1a-4e9c-861e-e563657486ce@default>
 <d0b98261-9ae3-19dc-7b6a-76de2e99c3c8@oracle.com>
 <b9b6bb78-3e3c-4924-92a6-026943e5b79c@default>
 <02c13573-f2ef-4275-7468-c53b54310ef0@oracle.com>
Message-ID: <a706ab54-6054-4954-a369-d35986f1a19f@default>

Hi Alexey, Thank you for your thorough review. I have updated the copyrights as well and please see below for my comments:

?

Here is the new Webrev: http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.04/

?

Thanks and regards,

Shashi

?

From: Alexey Ivanov 
Sent: Tuesday, September 25, 2018 3:00 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev <swing-dev at openjdk.java.net>; awt-dev <awt-dev at openjdk.java.net>
Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

?

Hi Shashi,

Please see my comments inline:

On 21/09/2018 23:22, Shashidhara Veerabhadraiah wrote:

Hi Alexey, Thanks for your review and below is the new Webrev.

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.03/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.03/

?

Please see below for inline comments.

?

Thanks and regards,
Shashi

?

From: Alexey Ivanov 
Sent: Friday, September 21, 2018 2:09 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; swing-dev HYPERLINK "mailto:swing-dev at openjdk.java.net"<swing-dev at openjdk.java.net>; awt-dev HYPERLINK "mailto:awt-dev at openjdk.java.net"<awt-dev at openjdk.java.net>
Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-8182043: Access to Windows Large Icons

?

Hi Shashi,

SystemIcon.java
What is the purpose of new SystemIcon class?
It's not used anywhere but the provided test. Is this class really needed then?
Is it supposed to become the public API for accessing system icons?
Why can't FileSystemView be used for that purpose as it was proposed in Semyon's review?
[Shashi] SystemIcon is going to be the front face to access the icons and that is the purpose of this class. The reason for choosing this is that FileSystemView class can be used internally and did not wanted to expose it externally too. Externally exposing may cause certain restriction in maintaining the classes hence the indirection.


Still, I cannot understand the rationale for a new class the only purpose of which is to provide public access to getSystemIcon(File, int, int).
FileSystemView is already a public class, and it's used internally. (I guess it would not have existed, if it hadn't.) It has a public method getSystemIcon(File). As such, extending its functionality to get access to larger icons seems logical. This is what the new protected getSystemIcon(File f, int size) does.

It can be made public to facilitate access to file icons.
After all, protected method is also a contract, it cannot be changed without affecting backward compatibility.

It is this new protected method that performs the task of getting the icon from the system.

Do we really need other methods?

[Shashi] I think that system icons functions as part of filesystemview class is also a kind of corrupted creation of the filesystemview class. Icons forms a different functionality compared to file system and should have been kept as a separate class in the first place.

?

Regarding the methods, am not sure does it required or not but I added them to be complete. Some variant is required to provide the original unmodified icon as the system returns and provide the scaled icon as well.




278???? public File createNewFolder(File containingDir) throws IOException {
279???????? return null;
280???? }
You had to implement the abstract method from FileSystemView. It's one more point to make system icon available right from FileSystemView.
This implementation should rather throw an exception.

[Shashi] IOException? I think it's not needed as we won't be performing any such actions. But yes I had to implement this place holder to be complete.




60???????? protected File file;
This field is redundant, in my opinion. It would be quite expensive to instantiate SystemIcon object for each file. It can safely be removed, then only methods which take additional File parameter will be left.
(The field could be final as it cannot be changed and should not be changed.)

[Shashi] Updated.



65???? public SystemIcon() {
66???????? this.file = null;
67???? }
Should rather call this(null) constructor.

[Shashi] Correct and updated.



112???? public Icon getSystemIcon(int width, int height) {
Are methods with width / height parameters needed? Icons are usually square.

[Shashi] Flexibility is ok I think. It would fall back to the same function though. Though the native does not have the function and since because of scaling we can support that. Am not sure where it can be useful but being flexible is ok I think!!



You repeat checks if f is null, width and height checks in each and every method. I guess parameter validation could be extract into a separate method. You will avoid lots of cope duplication.

[Shashi] Updated



Since it's a completely new API, I suggest throwing IllegalArgumentException with appropriate message in the cases where a parameter (file, width and height) fails validation.

[Shashi] Updated.



210???????? int size;
211???????? if(width > height) {
212???????????? size = width;
213???????? } else {
214???????????? size = height;
215???????? }
This code can be simplified to
int size = Math.max(width, height);
Concise and clear.
A helper method which validates the parameters could also return this value. Thus, again, avoiding code duplication among many methods in this class.

[Shashi] Updated.




There are lots of tabs in this file. Tabs must be replaced with spaces.
if's are inconsistent throughout the code: some are with space, some are without. Please add the space everyone to align with Java Code Conventions.
Please also sort the imports and remove unused ones.

[Shashi] Updated







FileSystemView.java
?259????? * Icon for a file, directory, or folder as it would be displayed in
?260????? * a system file browser for the requested size.
For getXXX, it's better to start description with "Returns." so it aligns to other similar methods.
However, I see the new method follows description of getIcon(boolean).

[Shashi] Because as you said rightly it follows the getIcon(boolean)


Okay.
Is it possible to update documentation to the existing getSystemIcon(File)?
Should I file a separate bug to update the documentation?

Documentation also references a non-public class ShellFolder. Should this reference be removed from documentation as the access to non-public classes is restricted? It does not add much value.

[Shashi] Updated.






?265????? * @param size width and height of the icon in pixels to be scaled(valid range: 1 to 256)
Why is it "to be scaled"? I would expect to get the icon of the requested size. At the same time, the icon can be scaled to the requested size if the requested size is not available.

[Shashi] User has no restriction of mentioning any size but the platform may have a limitation of size. Since we are supporting a set of different versions of platforms, platform may limit the size of the icon to a particular size, in which case it will be scaled to the user requested size.


I understand that. However, I think the suggested description does not convey the meaning correctly.
The method will return the icon of the requested size, won't it?
So the correct description is:
@param size width and height of the icon in pixels (valid range: 1 to 256)

The fact the returned icon may be scaled if the requested size is not available must be described in the method documentation as well as in @return line:
@return an icon of the requested size (possibly scaled) as it would be displayed by a native file chooser

[Shashi] Updated






270???? protected Icon getSystemIcon(File f, int size) {
Can't the method be public? It was in Semyon's review.

[Shashi] Because of the indirection, this method can stay as protected. I think it is always good to be of using protected than making everything public. Also that is the advantage of adding the SystemIcon class.


Sorry I don't see any advantage of having SystemIcon class over making this method public as I outlined above.




?266????? * @return an icon as it would be displayed by a native file chooser
An icon of the requested size (possibly scaled) as.

?275???????? if(size > 256 || size < 1) {
?276???????????? return null;
?277???????? }
Please add space between if and the opening parenthesis.
You can throw InvalidArgumentException in this case.
Does size of 1 make any sense?

[Shashi] Done. I can only say that 0 does not make sense. Check is to see that it is not less than 1.


What about throwing InvalidArgumentException when size parameter is invalid?

[Shashi] Updated



I understand that check is to make sure size is at least 1. However, icon of 1 pixel size does not make any sense. Should the minimum be a more sensible of 4?
It's a concern for discussion.
[Shashi] On the native side, there is no restriction so I think we can keep this open.





ShellFolder.java
?202???? /**
?203????? * @param size size of the icon > 0
?204????? * @return The icon used to display this shell folder
?205????? */
Can you add a short description of the purpose of this method? "Returns the icon of the specified size used to display this shell folder"?
A similar description can be added to the method above it:
198???? public Image getIcon(boolean getLargeIcon) {

[Shashi] Updated. Thank you.


Thank you for updating @return clause of the Javadoc.
My intention was to add a generic description of the method as well:
202???? /**
202????? * Returns the icon of the specified size used to display this shell folder.
202????? *
203????? * @param size size of the icon > 0
204????? * @return The icon used to display this shell folder
205????? */

Such description could also be added to method above getIcon(boolean getLargeIcon), at line 198.

Should the range of size parameter be specified? For example, 1-256 as in FileSystemView.
[Shashi] Updated



ShellFolder2.cpp
?944???????????? hres = pIcon->Extract(szBuf, index, &hIcon, 0, size);
Please use NULL instead of 0. This way it's clear you pass a null pointer rather an integer with value of 0.

[Shashi] Updated.



974???? const int MAX_ICON_SIZE = 128;
I also suggest increasing MAX_ICON_SIZE to 256. Otherwise I see no point in allowing 256 as the maximum size at Java level as you'll never have icon of 256?256 even thought the system may have one.

[Shashi] Per me, the problem is that since we support certain older versions of the platforms, it should not cause an exception at the native level. If everyone agrees for the change then we can change that.


This concern was raised in the previous review too:
http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013115.html

I think it's safe to update the value of MAX_ICON_SIZE to 256. The oldest supported version of Windows is Windows 7 which supports 256?256 icons.
Windows XP used icons up to 48?48, but it does not imply the API does not allow loading icon of larger size. Both 128 and 256 should be tested on Windows XP if JDK still runs on it.
[Shashi] I will raise a bug on this and work on it later. I have to see fn_GetIconInfo() and what it returns the values and based on it, it is good to update to 256 I think.





Win32ShellFolder2.java
1007???? private static Image makeIcon(long hIcon, int bsize) {
bsize has no meaning. Prasanta also asked about the name of the parameter.
I suggest using "size" for parameter, and "iconSize" for local variable.

[Shashi] Updated.



1031???????? int size = getLargeIcon ? 32 : 16; // large icon is 32 pixels else 16 pixels
Create constants for these magic numbers.
HYPERLINK "http://cr.openjdk.java.net/%7Essadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html"http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java.udiff.html

[Shashi] Updated.



1080???????????????????????????????????????? return getShell32Icon(4, size); // pick folder icon
1081???????????????????????????????????? } else {
1082???????????????????????????????????????? return getShell32Icon(1, size); // pick file icon
Also create constants for 4 and 1 as Prasanta suggested.
Creating a constant costs you nothing but makes the code more readable without adding comments.

[Shashi] But my view is that if we start doing for every immediate value, then creation of the object and assignment may have some implications. If it is used more than once, yes definitely create the constant. Please let me know if you think otherwise. This I follow it as a standard by practice. 


Primitive type constants do not have any performance penalty as they're resolved at compile time.
There's no difference if you write getShell32Icon(FOLDER_ICON_INDEX, size) or getShell32Icon(4, size). Yet the former is much clearer, isn't it?

With the constants, the if expression could be replaced with the conditional operator:

if(hIcon <= 0) {
??? return getShell32Icon(isDirectory() ? FOLDER_ICON_INDEX : FILE_ICON_INDEX, size);
}


I agree not every number in code should be defined as a constant. Yet I'm for using constants in this particular piece of code.

These values are used at least twice in Win32ShellFolder2.java: lines 1081-1085 and 1119-1123.

[Shashi] Updated.




1138???????? Image icon = makeIcon(hIcon, 32);
Now should use LARGE_ICON_SIZE. 

[Shashi] Updated






1113???????????? if(hIcon <= 0) {
1116???????????????? if(hIcon <= 0) {
Please add space between if and the opening parenthesis.

[Shashi] Updated.


1078???????????????????????????? if(hIcon <= 0) {
1081???????????????????????????????? if(hIcon <= 0) {
These (in the method above) could also be updated.




Win32ShellFolderManager2.java
?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, key.startsWith("shell32LargeIcon ")?
?383???????????????????????????????????????????????????????????????? 32 : 16);
You can use constants declared for icon size in from Win32ShellFolder2 because they're already imported:
? 42 import static sun.awt.shell.Win32ShellFolder2.*;

[Shashi] Updated.


?382???????????????????? return Win32ShellFolder2.getShell32Icon(i, key.startsWith("shell32LargeIcon ")?
?383???????????????????????????????????????????????????????????????? LARGE_ICON_SIZE : SMALL_ICON_SIZE);

May I suggest updating formatting to:
??????????????????? return Win32ShellFolder2.getShell32Icon(i,
??????????????????????????? key.startsWith("shell32LargeIcon ") ? LARGE_ICON_SIZE : SMALL_ICON_SIZE);
or even
??????????????????? return Win32ShellFolder2.getShell32Icon(i,
??????????????????????????? key.startsWith("shell32LargeIcon ") ? LARGE_ICON_SIZE
??????????????????????????????????????????????????????????????? : SMALL_ICON_SIZE);
(where : aligns with ?)
[Shashi] Updated




Then the code at these lines needs to be updated too:
?129???????????? STANDARD_VIEW_BUTTONS[iconIndex] = (size == 16)
?130???????????????????? ? img
?131???????????????????? : new MultiResolutionIconImage(16, img);

See HYPERLINK "http://cr.openjdk.java.net/%7Essadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html"http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.01/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java.udiff.html


SystemIconTest.java

Could you please order the imports? Your IDE would be happy to do it for you.
Could you also add spaces between if and the opening parenthesis?
(Or at least be consistent with it.)

58???????????? ImageIcon icon = (ImageIcon)sysIcon.getSystemIcon(file, size, size);
Casts should be followed by a blank space.

67???????????? else if (icon.getIconWidth() != size) {
else is redundant as the preceding if throws an exception.

[Shashi] Updated.


Could you please organize imports?
There are only three classes used.

41???????????? System.out.println("Windows detected: will run sytem icons test");
typo: system

Since the test is Windows-specific, it can be declared using @requires tag of JTreg:
@requires os.family == "windows"
[Shashi] Updated.

Regards,
Alexey







Regards,
Alexey




On 04/09/2018 10:39, Shashidhara Veerabhadraiah wrote:

Hi All, Please find the updated Webrev per the discussion:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8182043/webrev.02/"http://cr.openjdk.java.net/~sveerabhadra/8182043/webrev.02/

?

Thanks and regards,

Shashi


<SNIP>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180928/36cdb029/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 27030 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180928/36cdb029/winmail-0001.dat>

From fairoz.matte at oracle.com  Fri Sep 28 15:32:17 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Fri, 28 Sep 2018 08:32:17 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] RFR: 8166673: The new implementation of
 Robot.waitForIdle() may hang
Message-ID: <2e11e01b-e68e-4687-adf9-9a9e9ebe4d0f@default>

Hi,

Please review the backport of "JDK-8166673: The new implementation of Robot.waitForIdle() may hang" to 8u
Changes apply cleanly, there was a typo error in test case name "WaitForIdleSyncroizedOnString.java" it has been corrected to "WaitForIdleSynchronizedOnString.java"
As the test case doesn't have any impact on JDK8, it passes before the patch.
I have verified the issue by executing test case found in one of the duplicate issue JDK-8194862

Webrev - http://cr.openjdk.java.net/~fmatte/8166673/webrev.00/ 
JBS bug - https://bugs.openjdk.java.net/browse/JDK-8166673
JDK9 changeset - http://hg.openjdk.java.net/jdk9/client/jdk/rev/fec7a8a6a46a
JDK9 review thread - http://mail.openjdk.java.net/pipermail/awt-dev/2016-October/012114.html

Thanks,
Fairoz

From Sergey.Bylokhov at oracle.com  Fri Sep 28 19:22:09 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Sep 2018 12:22:09 -0700
Subject: <AWT Dev> [8u-backport] RFR: 8166673: The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <2e11e01b-e68e-4687-adf9-9a9e9ebe4d0f@default>
References: <2e11e01b-e68e-4687-adf9-9a9e9ebe4d0f@default>
Message-ID: <283ce843-1af1-712d-98be-3c7ef1d4893b@oracle.com>

Hi, Fairoz.

On 28/09/2018 08:32, Fairoz Matte wrote:
> As the test case doesn't have any impact on JDK8, it passes before the patch.

The tests works before the fix because in jdk8 the code which is updated 
in SunToolkit is not used by the Robot class, so it is unclear how the 
application triggers the bug.

> I have verified the issue by executing test case found in one of the duplicate issue JDK-8194862

Can you please add a stacktrace of the deadlock to the bug descripton?

> 
> Webrev - http://cr.openjdk.java.net/~fmatte/8166673/webrev.00/
> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8166673
> JDK9 changeset - http://hg.openjdk.java.net/jdk9/client/jdk/rev/fec7a8a6a46a
> JDK9 review thread - http://mail.openjdk.java.net/pipermail/awt-dev/2016-October/012114.html
> 
> Thanks,
> Fairoz
> 


-- 
Best regards, Sergey.

From fairoz.matte at oracle.com  Sat Sep 29 04:29:04 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Fri, 28 Sep 2018 21:29:04 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] RFR: 8166673: The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <283ce843-1af1-712d-98be-3c7ef1d4893b@oracle.com>
References: <2e11e01b-e68e-4687-adf9-9a9e9ebe4d0f@default>
 <283ce843-1af1-712d-98be-3c7ef1d4893b@oracle.com>
Message-ID: <dcdcfdec-3eac-4698-98f5-5d7944c3c567@default>

Hi Sergey,

Thanks for looking into this.

> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, September 29, 2018 12:52 AM
> To: Fairoz Matte <fairoz.matte at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [8u-backport] RFR: 8166673: The new
> implementation of Robot.waitForIdle() may hang
> 
> Hi, Fairoz.
> 
> On 28/09/2018 08:32, Fairoz Matte wrote:
> > As the test case doesn't have any impact on JDK8, it passes before the
> patch.
> 
> The tests works before the fix because in jdk8 the code which is updated in
> SunToolkit is not used by the Robot class, so it is unclear how the application
> triggers the bug.
> 
> > I have verified the issue by executing test case found in one of the
> > duplicate issue JDK-8194862
> 
> Can you please add a stacktrace of the deadlock to the bug descripton?
> 

I have updated bug (JDK-8194862) with stacktraces of the threads causing deadlock.

Thanks,
Fairoz

> >
> > Webrev - http://cr.openjdk.java.net/~fmatte/8166673/webrev.00/
> > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8166673
> > JDK9 changeset -
> > http://hg.openjdk.java.net/jdk9/client/jdk/rev/fec7a8a6a46a
> > JDK9 review thread -
> > http://mail.openjdk.java.net/pipermail/awt-dev/2016-
> October/012114.htm
> > l
> >
> > Thanks,
> > Fairoz
> >
> 
> 
> --
> Best regards, Sergey.

From krishna.addepalli at oracle.com  Sun Sep 30 03:18:54 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sun, 30 Sep 2018 03:18:54 +0000 (UTC)
Subject: <AWT Dev> [12]RFR: [JDK-8074824]: Resolve disabled warnings for
	libawt_xawt
Message-ID: <57768c04-a994-46f8-8322-fa89058d58c9@default>

Hi All, 

 

Please review a fix for JDK-8074824: https://bugs.openjdk.java.net/browse/JDK-8074824

Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/

 

Most of the warnings have been fixed for Linux, Mac and Windows.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180930/c522b137/attachment.html>

From javalists at cbfiddle.com  Sun Sep 30 23:43:21 2018
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 30 Sep 2018 16:43:21 -0700
Subject: <AWT Dev> questions about JDK-8181910 [macos] Support dark title
	bars on macOS
Message-ID: <5650BBDE-42C2-4F47-ABDF-BE44497B28EA@cbfiddle.com>

I gather that this change was reverted, but why does the bug report [1] not refect that?

Also, I believe the proposed change is incorrect, above and beyond its build-breaking feature.

(1) It installs the appearances NSAppearanceNameVibrantLight and NSAppearanceNameVibrantDark, which are inappropriate.

From the AppKit documentation:

Don't assign an NSAppearance <https://developer.apple.com/documentation/appkit/nsappearance?language=objc> object with this type directly to one of your views. Instead, assign a light appearance to your view, make sure its allowsVibrancy <https://developer.apple.com/documentation/appkit/nsview/1483793-allowsvibrancy?language=objc> property is set to YES <https://developer.apple.com/documentation/objectivec/yes?language=objc>, and embed the view in a visual effect view. When you do, AppKit updates your view's appearance to this type.

(2) In macOS 10.14, setting an explicit appearance will override the system-provided default. There needs to be a way to prevent AWT from setting the appearance attribute.

(3) Dynamic changes to the client property apparently will not work, because _STYLE_PROP_BITMASK is not extended with the new style bit.


[1] https://bugs.openjdk.java.net/browse/JDK-8181910
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180930/58384e47/attachment.html>