From trebari at openjdk.java.net  Tue Dec  1 02:42:56 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 1 Dec 2020 02:42:56 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v2]
In-Reply-To: <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
 <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
 <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>
Message-ID: <rWc9A4Y7eS9lrk62Xnr9YPybFdfXQ7CDABxTiMp5jOY=.b8d20c35-b5a7-4085-a586-fa3f9fff249f@github.com>

On Mon, 30 Nov 2020 17:53:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> not wrong but different account but that doesnot make the comment invalid, I guess.
>> 
>> But nobody sees it, it is hidden.
>
> Well, the comment was added on Oct 15 and it got hidden on Oct28 because the ac was not of github author/committer. I think the fix submitter should have seen the comment lying there for 2 weeks before it got hidden.

I have seen the comment, it is not visible in github but its there in mailing-list.

"It seems the effect is in WindowsLookAndFeel but you are fixing in Basic L&F. If the cause is in Basic L&F, then it
would have affected other L&F also like Metal,Nimbus, doesn't it? If MouseGrabber not removed is the problem, the I
guess MouseGrabber.uninstall() is not called. This is called in BasicLookAndFeel#uninitialize() and is overridden in
WindowsLookAndFeel. Metal does not override this so maybe that's why the issue is not seen in Metal.  Probably the
right fix is to call this MouseGrabber.uninstall() in Windows:LookAndFeel.uninitialize() same way as is done in
BasicLookAndFeel.uninitialize()"

the current fix doesn't looks correct so working on finding the correct fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From psadhukhan at openjdk.java.net  Tue Dec  1 04:56:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 1 Dec 2020 04:56:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
Message-ID: <gbrn8H4zPDM1PYfvldctoGM8YEgxu9PE7-uRnN_QFlU=.e2e2f9ff-664b-4d50-9d5f-3bc3e14fd19a@github.com>

On Tue, 24 Nov 2020 21:23:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tried to find and change tabpane background color for "selected" tab but unable to do so. 
>> Tried changing AquaLookAndFeel.tabBackgroundColor, TabbedPane.background color to no avail. Tried to set background by calling tabPane.setbackground() in AquaTabbedPaneUI.installDefaults but it sets background for non-selected tab (keeping black background for selected tab in mohave unchanged). I see it's been like that at least from jdk8GA.
>> Post to apple forum is unanswered.
>
>> When inactive, I use 0 0 0 192. As far as I can tell, this does not correspond to a named color.
>> It would be wrong to assume that Apple only uses named colors in their UIs.
>> The named colors are for application developers, not for Apple itself.
> 
> The problem here is that we do not control the color of the tab pane, it is controlled by Apple, and if we hardcore some color on our side we will get the same bugs again and again. I am sure that a similar bug will come in the dark mode if we will enable it.

If 1st fix is acceptable, then I will go ahead and bring back the fix else if we want to wait for Apple to come back, then we need to move it to JDK17. Please let me know the decision @mrserb @prrace

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Tue Dec  1 18:20:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 1 Dec 2020 18:20:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
Message-ID: <XF3OlbwNDJ09YyFSd4eGCGM4QyuSFOYYoI6O2mv8jY0=.f175f235-76a6-420f-a9dc-4d52480eae70@github.com>

On Mon, 30 Nov 2020 04:49:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.

Can you try some small sample code and create the tabpane using Cocoa then set some state to the pane(like selected) and request its font?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From psadhukhan at openjdk.java.net  Wed Dec  2 10:21:59 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 2 Dec 2020 10:21:59 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors
In-Reply-To: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
Message-ID: <-fsvDkksOm3HbLmfYTMp2QXJPE8PzXwEjlvCWkdGm_0=.1a980da5-17ce-4934-9806-2c0201c80843@github.com>

On Wed, 11 Nov 2020 08:00:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
> but support for rgba() is not present in JDK html text rendering.
> 
> Added support for rgba() to render translucent text color.

any further comments?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1158

From kizune at openjdk.java.net  Fri Dec  4 02:04:57 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 4 Dec 2020 02:04:57 GMT
Subject: <Swing Dev> Withdrawn: 8182043: Access to Windows Large Icons
In-Reply-To: <UHf3lNQxeXBR_6vXU9AYvIhpQzQ3YHOuJsTA2bDYAKo=.b0c052c0-318f-4901-9569-8b89c4ced6ad@github.com>
References: <UHf3lNQxeXBR_6vXU9AYvIhpQzQ3YHOuJsTA2bDYAKo=.b0c052c0-318f-4901-9569-8b89c4ced6ad@github.com>
Message-ID: <__ZcyC25VbRfkIVQzO_K3QYOHrIlf-dmZbmdrAly4bs=.cede44fa-8559-4740-9c09-547f962369b1@github.com>

On Mon, 28 Sep 2020 15:20:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Moving review from Mercurial. See https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016078.html for previous iteration.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/380

From serb at openjdk.java.net  Fri Dec  4 02:42:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 4 Dec 2020 02:42:57 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v3]
In-Reply-To: <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>
Message-ID: <IBOQN-ocoX9r8RQD_1YUmRN8ukPlP4LrbnJ5u7T1LFg=.f693a6e0-ef00-4cd1-87c7-2bbc7fe7a451@github.com>

On Tue, 24 Nov 2020 13:02:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
>> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
>> but support for rgba() is not present in JDK html text rendering.
>> 
>> Added support for rgba() to render translucent text color.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unneeded additional code

test/jdk/javax/swing/JLabel/TestTranslucentLabelText.java line 27:

> 25:  * @bug 8256019
> 26:  * @summary Verifies if JLabel HTML text support translucent text colors
> 27:  * @run main/manual TestTranslucentLabelText

Is it necessary to make this test manual? probably we can just draw the label to the buffered image and check resulted content?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1158

From psadhukhan at openjdk.java.net  Fri Dec  4 03:52:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 4 Dec 2020 03:52:57 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v3]
In-Reply-To: <IBOQN-ocoX9r8RQD_1YUmRN8ukPlP4LrbnJ5u7T1LFg=.f693a6e0-ef00-4cd1-87c7-2bbc7fe7a451@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>
 <IBOQN-ocoX9r8RQD_1YUmRN8ukPlP4LrbnJ5u7T1LFg=.f693a6e0-ef00-4cd1-87c7-2bbc7fe7a451@github.com>
Message-ID: <ywOTygp7Jcw00iOjo7Itq_PUk36Qqh_O8oOLXcsFZ8Q=.fe43bcfa-8398-4aef-81b6-4e48e7da9895@github.com>

On Fri, 4 Dec 2020 02:40:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unneeded additional code
>
> test/jdk/javax/swing/JLabel/TestTranslucentLabelText.java line 27:
> 
>> 25:  * @bug 8256019
>> 26:  * @summary Verifies if JLabel HTML text support translucent text colors
>> 27:  * @run main/manual TestTranslucentLabelText
> 
> Is it necessary to make this test manual? probably we can just draw the label to the buffered image and check resulted content?

I tried before making it manual but could not effectively do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1158

From psadhukhan at openjdk.java.net  Fri Dec  4 17:38:22 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 4 Dec 2020 17:38:22 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with high-DPI
 scaling and W3C_UNIT_LENGTHS
Message-ID: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>

Issue is when using a JEditorPane to render HTML views with W3C_UNIT_LENGTHS enabled, font-sizes set using CSS are much larger than the same font size outside the HTML.
It's because CSS LengthUnit uses screen resolution to calculate units so for hidpi screens, the html font size is bigger. 
Fix is to calculate the units based on the CSS absolute length mentioned in https://drafts.csswg.org/css-values-3/#absolute-lengths so hidpi scaling is not applied twice in CSS and again by Java.

-------------

Commit messages:
 - jcheck fix
 - CSS fix

Changes: https://git.openjdk.java.net/jdk/pull/1628/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1628&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231286
  Stats: 124 lines in 2 files changed: 113 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1628/head:pull/1628

PR: https://git.openjdk.java.net/jdk/pull/1628

From psadhukhan at openjdk.java.net  Mon Dec  7 13:18:18 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 7 Dec 2020 13:18:18 GMT
Subject: <Swing Dev> RFR: 8196090:
 javax/swing/JComboBox/6559152/bug6559152.java fails
Message-ID: <K5pk2-myhUdDubiVoRnido2AfVgfIxEAHeDqdmGPSWw=.3bda6193-9834-4354-adc7-055c9bceeed3@github.com>

Test seems to fail in mach5 nightly testing when ran in a group of all JComboBox tests.
Modified few tests that were run prior to running this test by moving the frame to centre of screen, adjusting the event delay time to more consistent value in sync with other test and also made this test's frame gain focus by clicking on the frame, as it seems the frame does not get focus sometime so that keyevent does not get registered causing it to fail.
Ran bunch of JComboBox test that were run prior to this tests in normal run, along with this test, in mach5 which is ok. Link in JBS.

-------------

Commit messages:
 - 8196090: javax/swing/JComboBox/6559152/bug6559152.java fails

Changes: https://git.openjdk.java.net/jdk/pull/1666/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1666&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196090
  Stats: 68 lines in 5 files changed: 33 ins; 11 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1666/head:pull/1666

PR: https://git.openjdk.java.net/jdk/pull/1666

From youngty1997 at gmail.com  Mon Dec  7 21:20:40 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 7 Dec 2020 15:20:40 -0600
Subject: <Swing Dev> JDK 16 Linux Swing segfault
Message-ID: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>

Hi,


Just sending this to report that as of right now there is somekind of 
regression in the GTK bindings code that is causing a segfault and as a 
result Netbeans (or presumably any other IDE) will not run on JDK 16 on 
Linux. This doesn't happen with Java 11. Here is the error trace that 
Netbeans spits out after segfaulting:


Current thread (0x00007f5cdc1364e0):? JavaThread "AWT-EventQueue-0" 
[_thread_in_native, id=181601, stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]

Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], sp=0x00007f5cd5e2c058,? 
free space=2040k
Native frames: (J=compiled Java code, A=aot compiled Java code, 
j=interpreted, Vv=VM code, C=native code)
C? 0x00007f5c80de40cc

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j? com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
java.desktop at 16-internal
j 
com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
java.desktop at 16-internal
j 
com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
java.desktop at 16-internal
j 
com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
java.desktop at 16-internal
j 
com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
java.desktop at 16-internal
j javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
java.desktop at 16-internal
j? javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
java.desktop at 16-internal
j? org.netbeans.swing.plaf.Startup.initialize()V+106
j? org.netbeans.swing.plaf.Startup.<init>()V+25
j 
org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
j? org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
[0x00007f5d59382780+0x000000000000022c]
J 3071 c1 
java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
[0x00007f5d59376b80+0x0000000000001b5c]
J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
[0x00007f5d59374680+0x000000000000013c]
J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
[0x00007f5d59374e60+0x00000000000005c4]
J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
[0x00007f5d5937c2a0+0x0000000000000694]
j 
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
java.desktop at 16-internal
j 
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
java.desktop at 16-internal
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
java.desktop at 16-internal
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
java.desktop at 16-internal
j? java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
v? ~StubRoutines::call_stub


Much appreciated if this could be fixed.




From philip.race at oracle.com  Mon Dec  7 21:34:14 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2020 13:34:14 -0800
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
Message-ID: <5FCE9FD6.5080304@oracle.com>

Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which has 
not been
seen on any of our supported Linux configs - what are you using ?

-phil

On 12/7/20, 1:20 PM, Ty Young wrote:
> Hi,
>
>
> Just sending this to report that as of right now there is somekind of 
> regression in the GTK bindings code that is causing a segfault and as 
> a result Netbeans (or presumably any other IDE) will not run on JDK 16 
> on Linux. This doesn't happen with Java 11. Here is the error trace 
> that Netbeans spits out after segfaulting:
>
>
> Current thread (0x00007f5cdc1364e0):  JavaThread "AWT-EventQueue-0" 
> [_thread_in_native, id=181601, 
> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>
> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
> sp=0x00007f5cd5e2c058,  free space=2040k
> Native frames: (J=compiled Java code, A=aot compiled Java code, 
> j=interpreted, Vv=VM code, C=native code)
> C  0x00007f5c80de40cc
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
> java.desktop at 16-internal
> j 
> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
> java.desktop at 16-internal
> j 
> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
> java.desktop at 16-internal
> j 
> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
> java.desktop at 16-internal
> j 
> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
> java.desktop at 16-internal
> j javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
> java.desktop at 16-internal
> j  javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
> java.desktop at 16-internal
> j  org.netbeans.swing.plaf.Startup.initialize()V+106
> j  org.netbeans.swing.plaf.Startup.<init>()V+25
> j 
> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
> j  org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
> [0x00007f5d59382780+0x000000000000022c]
> J 3071 c1 
> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
> [0x00007f5d59376b80+0x0000000000001b5c]
> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
> [0x00007f5d59374680+0x000000000000013c]
> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
> [0x00007f5d59374e60+0x00000000000005c4]
> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
> [0x00007f5d5937c2a0+0x0000000000000694]
> j 
> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
> java.desktop at 16-internal
> j 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
> java.desktop at 16-internal
> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
> java.desktop at 16-internal
> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
> java.desktop at 16-internal
> j  java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
> v  ~StubRoutines::call_stub
>
>
> Much appreciated if this could be fixed.
>
>
>

From youngty1997 at gmail.com  Mon Dec  7 21:38:44 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 7 Dec 2020 15:38:44 -0600
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <5FCE9FD6.5080304@oracle.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
Message-ID: <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>

I use Arch Linux(btw), which is a "bleeding edge" Linux distro. The 
distro mentioned in that bug report is based on Arch Linux.


On 12/7/20 3:34 PM, Philip Race wrote:
> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which has 
> not been
> seen on any of our supported Linux configs - what are you using ?
>
> -phil
>
> On 12/7/20, 1:20 PM, Ty Young wrote:
>> Hi,
>>
>>
>> Just sending this to report that as of right now there is somekind of 
>> regression in the GTK bindings code that is causing a segfault and as 
>> a result Netbeans (or presumably any other IDE) will not run on JDK 
>> 16 on Linux. This doesn't happen with Java 11. Here is the error 
>> trace that Netbeans spits out after segfaulting:
>>
>>
>> Current thread (0x00007f5cdc1364e0):? JavaThread "AWT-EventQueue-0" 
>> [_thread_in_native, id=181601, 
>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>
>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>> sp=0x00007f5cd5e2c058,? free space=2040k
>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>> j=interpreted, Vv=VM code, C=native code)
>> C? 0x00007f5c80de40cc
>>
>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>> java.desktop at 16-internal
>> j 
>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>> java.desktop at 16-internal
>> j 
>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>> java.desktop at 16-internal
>> j 
>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>> java.desktop at 16-internal
>> j 
>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>> java.desktop at 16-internal
>> j javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
>> java.desktop at 16-internal
>> j? javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>> java.desktop at 16-internal
>> j? org.netbeans.swing.plaf.Startup.initialize()V+106
>> j? org.netbeans.swing.plaf.Startup.<init>()V+25
>> j 
>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>> j? org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>> [0x00007f5d59382780+0x000000000000022c]
>> J 3071 c1 
>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>> [0x00007f5d59376b80+0x0000000000001b5c]
>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>> [0x00007f5d59374680+0x000000000000013c]
>> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>> [0x00007f5d59374e60+0x00000000000005c4]
>> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>> [0x00007f5d5937c2a0+0x0000000000000694]
>> j 
>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>> java.desktop at 16-internal
>> j 
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>> java.desktop at 16-internal
>> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
>> java.desktop at 16-internal
>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>> java.desktop at 16-internal
>> j? java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>> v? ~StubRoutines::call_stub
>>
>>
>> Much appreciated if this could be fixed.
>>
>>
>>

From philip.race at oracle.com  Mon Dec  7 21:47:11 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2020 13:47:11 -0800
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
 <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
Message-ID: <5FCEA2DF.9060208@oracle.com>

Yes. Sounds right. ALL reports of this so far are on an Arch Linux distro.
Not seen on Debian/Ubuntu or RH/OL/Centos

-phil.

On 12/7/20, 1:38 PM, Ty Young wrote:
> I use Arch Linux(btw), which is a "bleeding edge" Linux distro. The 
> distro mentioned in that bug report is based on Arch Linux.
>
>
> On 12/7/20 3:34 PM, Philip Race wrote:
>> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which has 
>> not been
>> seen on any of our supported Linux configs - what are you using ?
>>
>> -phil
>>
>> On 12/7/20, 1:20 PM, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> Just sending this to report that as of right now there is somekind 
>>> of regression in the GTK bindings code that is causing a segfault 
>>> and as a result Netbeans (or presumably any other IDE) will not run 
>>> on JDK 16 on Linux. This doesn't happen with Java 11. Here is the 
>>> error trace that Netbeans spits out after segfaulting:
>>>
>>>
>>> Current thread (0x00007f5cdc1364e0):  JavaThread "AWT-EventQueue-0" 
>>> [_thread_in_native, id=181601, 
>>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>>
>>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>>> sp=0x00007f5cd5e2c058,  free space=2040k
>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>> j=interpreted, Vv=VM code, C=native code)
>>> C  0x00007f5c80de40cc
>>>
>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>>> java.desktop at 16-internal
>>> j 
>>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>>> java.desktop at 16-internal
>>> j 
>>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>>> java.desktop at 16-internal
>>> j 
>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>>> java.desktop at 16-internal
>>> j 
>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>>> java.desktop at 16-internal
>>> j 
>>> javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
>>> java.desktop at 16-internal
>>> j  javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>>> java.desktop at 16-internal
>>> j  org.netbeans.swing.plaf.Startup.initialize()V+106
>>> j  org.netbeans.swing.plaf.Startup.<init>()V+25
>>> j 
>>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>>> j  org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>>> [0x00007f5d59382780+0x000000000000022c]
>>> J 3071 c1 
>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>>> [0x00007f5d59376b80+0x0000000000001b5c]
>>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>>> [0x00007f5d59374680+0x000000000000013c]
>>> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>>> [0x00007f5d59374e60+0x00000000000005c4]
>>> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>>> [0x00007f5d5937c2a0+0x0000000000000694]
>>> j 
>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>>> java.desktop at 16-internal
>>> j 
>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>>> java.desktop at 16-internal
>>> j 
>>> java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
>>> java.desktop at 16-internal
>>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>>> java.desktop at 16-internal
>>> j  java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>>> v  ~StubRoutines::call_stub
>>>
>>>
>>> Much appreciated if this could be fixed.
>>>
>>>
>>>

From youngty1997 at gmail.com  Tue Dec  8 01:03:16 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 7 Dec 2020 19:03:16 -0600
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <5FCEA2DF.9060208@oracle.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
 <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
 <5FCEA2DF.9060208@oracle.com>
Message-ID: <680fe063-44d6-64fe-8170-f365deaad9c2@gmail.com>

Is there an ETA on when this will be fixed?


On 12/7/20 3:47 PM, Philip Race wrote:
> Yes. Sounds right. ALL reports of this so far are on an Arch Linux 
> distro.
> Not seen on Debian/Ubuntu or RH/OL/Centos
>
> -phil.
>
> On 12/7/20, 1:38 PM, Ty Young wrote:
>> I use Arch Linux(btw), which is a "bleeding edge" Linux distro. The 
>> distro mentioned in that bug report is based on Arch Linux.
>>
>>
>> On 12/7/20 3:34 PM, Philip Race wrote:
>>> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which 
>>> has not been
>>> seen on any of our supported Linux configs - what are you using ?
>>>
>>> -phil
>>>
>>> On 12/7/20, 1:20 PM, Ty Young wrote:
>>>> Hi,
>>>>
>>>>
>>>> Just sending this to report that as of right now there is somekind 
>>>> of regression in the GTK bindings code that is causing a segfault 
>>>> and as a result Netbeans (or presumably any other IDE) will not run 
>>>> on JDK 16 on Linux. This doesn't happen with Java 11. Here is the 
>>>> error trace that Netbeans spits out after segfaulting:
>>>>
>>>>
>>>> Current thread (0x00007f5cdc1364e0):? JavaThread "AWT-EventQueue-0" 
>>>> [_thread_in_native, id=181601, 
>>>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>>>
>>>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>>>> sp=0x00007f5cd5e2c058,? free space=2040k
>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>>> j=interpreted, Vv=VM code, C=native code)
>>>> C? 0x00007f5c80de40cc
>>>>
>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>>>> java.desktop at 16-internal
>>>> j 
>>>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>>>> java.desktop at 16-internal
>>>> j 
>>>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>>>> java.desktop at 16-internal
>>>> j 
>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>>>> java.desktop at 16-internal
>>>> j 
>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>>>> java.desktop at 16-internal
>>>> j 
>>>> javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
>>>> java.desktop at 16-internal
>>>> j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>>>> java.desktop at 16-internal
>>>> j? org.netbeans.swing.plaf.Startup.initialize()V+106
>>>> j? org.netbeans.swing.plaf.Startup.<init>()V+25
>>>> j 
>>>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>>>> j? org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>>>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>>>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>>>> [0x00007f5d59382780+0x000000000000022c]
>>>> J 3071 c1 
>>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>>>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>>>> [0x00007f5d59376b80+0x0000000000001b5c]
>>>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>>>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>>>> [0x00007f5d59374680+0x000000000000013c]
>>>> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>>>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>>>> [0x00007f5d59374e60+0x00000000000005c4]
>>>> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>>>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>>>> [0x00007f5d5937c2a0+0x0000000000000694]
>>>> j 
>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>>>> java.desktop at 16-internal
>>>> j 
>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>>>> java.desktop at 16-internal
>>>> j 
>>>> java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
>>>> java.desktop at 16-internal
>>>> j 
>>>> java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>>>> java.desktop at 16-internal
>>>> j? java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>>>> v? ~StubRoutines::call_stub
>>>>
>>>>
>>>> Much appreciated if this could be fixed.
>>>>
>>>>
>>>>

From philip.race at oracle.com  Tue Dec  8 01:10:20 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2020 17:10:20 -0800
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <680fe063-44d6-64fe-8170-f365deaad9c2@gmail.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
 <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
 <5FCEA2DF.9060208@oracle.com>
 <680fe063-44d6-64fe-8170-f365deaad9c2@gmail.com>
Message-ID: <5FCED27C.8010505@oracle.com>

Whilst we appreciate the report, we would never give an ETA here. It 
isn't a support channel.
I can say that it is being investigated but since it doesn't occur on a 
supported platform it is not a high priority.

-phil.

On 12/7/20, 5:03 PM, Ty Young wrote:
> Is there an ETA on when this will be fixed?
>
>
> On 12/7/20 3:47 PM, Philip Race wrote:
>> Yes. Sounds right. ALL reports of this so far are on an Arch Linux 
>> distro.
>> Not seen on Debian/Ubuntu or RH/OL/Centos
>>
>> -phil.
>>
>> On 12/7/20, 1:38 PM, Ty Young wrote:
>>> I use Arch Linux(btw), which is a "bleeding edge" Linux distro. The 
>>> distro mentioned in that bug report is based on Arch Linux.
>>>
>>>
>>> On 12/7/20 3:34 PM, Philip Race wrote:
>>>> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which 
>>>> has not been
>>>> seen on any of our supported Linux configs - what are you using ?
>>>>
>>>> -phil
>>>>
>>>> On 12/7/20, 1:20 PM, Ty Young wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> Just sending this to report that as of right now there is somekind 
>>>>> of regression in the GTK bindings code that is causing a segfault 
>>>>> and as a result Netbeans (or presumably any other IDE) will not 
>>>>> run on JDK 16 on Linux. This doesn't happen with Java 11. Here is 
>>>>> the error trace that Netbeans spits out after segfaulting:
>>>>>
>>>>>
>>>>> Current thread (0x00007f5cdc1364e0):  JavaThread 
>>>>> "AWT-EventQueue-0" [_thread_in_native, id=181601, 
>>>>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>>>>
>>>>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>>>>> sp=0x00007f5cd5e2c058,  free space=2040k
>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>>>> j=interpreted, Vv=VM code, C=native code)
>>>>> C  0x00007f5c80de40cc
>>>>>
>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 java.desktop at 16-internal 
>>>>>
>>>>> j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>>>>> java.desktop at 16-internal
>>>>> j  org.netbeans.swing.plaf.Startup.initialize()V+106
>>>>> j  org.netbeans.swing.plaf.Startup.<init>()V+25
>>>>> j 
>>>>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>>>>> j  org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>>>>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>>>>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>>>>> [0x00007f5d59382780+0x000000000000022c]
>>>>> J 3071 c1 
>>>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>>>>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>>>>> [0x00007f5d59376b80+0x0000000000001b5c]
>>>>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>>>>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>>>>> [0x00007f5d59374680+0x000000000000013c]
>>>>> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>>>>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>>>>> [0x00007f5d59374e60+0x00000000000005c4]
>>>>> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>>>>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>>>>> [0x00007f5d5937c2a0+0x0000000000000694]
>>>>> j 
>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>>>>> java.desktop at 16-internal
>>>>> j 
>>>>> java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 java.desktop at 16-internal 
>>>>>
>>>>> j 
>>>>> java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>>>>> java.desktop at 16-internal
>>>>> j  java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>>>>> v  ~StubRoutines::call_stub
>>>>>
>>>>>
>>>>> Much appreciated if this could be fixed.
>>>>>
>>>>>
>>>>>

From youngty1997 at gmail.com  Tue Dec  8 02:41:53 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 7 Dec 2020 20:41:53 -0600
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <5FCED27C.8010505@oracle.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
 <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
 <5FCEA2DF.9060208@oracle.com>
 <680fe063-44d6-64fe-8170-f365deaad9c2@gmail.com>
 <5FCED27C.8010505@oracle.com>
Message-ID: <136eaef0-c5d7-abb8-2a9b-df81f86e36d2@gmail.com>


On 12/7/20 7:10 PM, Philip Race wrote:
> Whilst we appreciate the report, we would never give an ETA here. It 
> isn't a support channel.
> I can say that it is being investigated but since it doesn't occur on 
> a supported platform it is not a high priority.


What is a supported platform? The only information after a quick Google 
search gives:


https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms


Which only lists Oracle Enterprise Linux(Red Hat based?) and not Ubuntu.


But I digress, as noted in the previously linked bug report, this is a 
regression caused by your separation of libharfbuzz from libfontmanager 
from:


https://bugs.openjdk.java.net/browse/JDK-8249821


And you can't or won't revert it?? What's the point of a multi-platform 
UI API if you're going to break things just because you feel like it? 
You realize there isn't a singular version of Ubuntu too, right? 
Software built for the previous LTS won't necessarily work on the newest 
versions or vice versa. if you only strictly support Ubuntu 18.04 for 
example, Ubuntu 20.10 might not work and you probably won't do anything 
about it?


The bug "fix" is so seemingly unnecessary and caused way more harm than 
good with multiple people running into breakage running otherwise 
working software. Between all of the things being removed, deprecated, 
and broken across the JDK versions over the last few years, you might 
have enough content for a "killedbyoracle" website, similar to the 
existing Google one.


>
> -phil.
>
> On 12/7/20, 5:03 PM, Ty Young wrote:
>> Is there an ETA on when this will be fixed?
>>
>>
>> On 12/7/20 3:47 PM, Philip Race wrote:
>>> Yes. Sounds right. ALL reports of this so far are on an Arch Linux 
>>> distro.
>>> Not seen on Debian/Ubuntu or RH/OL/Centos
>>>
>>> -phil.
>>>
>>> On 12/7/20, 1:38 PM, Ty Young wrote:
>>>> I use Arch Linux(btw), which is a "bleeding edge" Linux distro. The 
>>>> distro mentioned in that bug report is based on Arch Linux.
>>>>
>>>>
>>>> On 12/7/20 3:34 PM, Philip Race wrote:
>>>>> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which 
>>>>> has not been
>>>>> seen on any of our supported Linux configs - what are you using ?
>>>>>
>>>>> -phil
>>>>>
>>>>> On 12/7/20, 1:20 PM, Ty Young wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> Just sending this to report that as of right now there is 
>>>>>> somekind of regression in the GTK bindings code that is causing a 
>>>>>> segfault and as a result Netbeans (or presumably any other IDE) 
>>>>>> will not run on JDK 16 on Linux. This doesn't happen with Java 
>>>>>> 11. Here is the error trace that Netbeans spits out after 
>>>>>> segfaulting:
>>>>>>
>>>>>>
>>>>>> Current thread (0x00007f5cdc1364e0):? JavaThread 
>>>>>> "AWT-EventQueue-0" [_thread_in_native, id=181601, 
>>>>>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>>>>>
>>>>>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>>>>>> sp=0x00007f5cd5e2c058,? free space=2040k
>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>>>>> j=interpreted, Vv=VM code, C=native code)
>>>>>> C? 0x00007f5c80de40cc
>>>>>>
>>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>>>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
>>>>>> java.desktop at 16-internal
>>>>>> j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>>>>>> java.desktop at 16-internal
>>>>>> j? org.netbeans.swing.plaf.Startup.initialize()V+106
>>>>>> j? org.netbeans.swing.plaf.Startup.<init>()V+25
>>>>>> j 
>>>>>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>>>>>> j? org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>>>>>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>>>>>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>>>>>> [0x00007f5d59382780+0x000000000000022c]
>>>>>> J 3071 c1 
>>>>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>>>>>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>>>>>> [0x00007f5d59376b80+0x0000000000001b5c]
>>>>>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>>>>>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>>>>>> [0x00007f5d59374680+0x000000000000013c]
>>>>>> J 3065 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>>>>>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>>>>>> [0x00007f5d59374e60+0x00000000000005c4]
>>>>>> J 3074 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>>>>>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>>>>>> [0x00007f5d5937c2a0+0x0000000000000694]
>>>>>> j 
>>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
>>>>>> java.desktop at 16-internal
>>>>>> j 
>>>>>> java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>>>>>> java.desktop at 16-internal
>>>>>> j? java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>>>>>> v? ~StubRoutines::call_stub
>>>>>>
>>>>>>
>>>>>> Much appreciated if this could be fixed.
>>>>>>
>>>>>>
>>>>>>

From philip.race at oracle.com  Tue Dec  8 03:00:54 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2020 19:00:54 -0800
Subject: <Swing Dev> JDK 16 Linux Swing segfault
In-Reply-To: <136eaef0-c5d7-abb8-2a9b-df81f86e36d2@gmail.com>
References: <994ab025-cd0c-b139-9688-c0a5c22192cd@gmail.com>
 <5FCE9FD6.5080304@oracle.com>
 <797aca79-105d-bf4b-1f1d-816c8b2ba230@gmail.com>
 <5FCEA2DF.9060208@oracle.com>
 <680fe063-44d6-64fe-8170-f365deaad9c2@gmail.com>
 <5FCED27C.8010505@oracle.com>
 <136eaef0-c5d7-abb8-2a9b-df81f86e36d2@gmail.com>
Message-ID: <5FCEEC66.9040309@oracle.com>

There is no problem seen on Ubuntu 20.10. I haven't seen any evidence to 
suggest it is due to a "newer" version
It could be a bug in Arch Linux and we really have no resources to 
proactively test every distro out there.
You are referencing a list of build platforms. Not runtime platforms.
I am saying that Oracle does not even certify Arch Linux (I personally 
had never heard of it).
So Oracle originated binaries - OpenJDK or commercial - are not 
certified against it.
You should be looking at a doc like this :
https://www.oracle.com/java/technologies/javase/products-doc-jdk11certconfig.html
or contacting the distro that provides your OpenJDK binaries.
It is unfortunate if some distro does not work but we extensively tested 
the separation on
all platforms and multiple Linux distros. No problem.
I don't think we want to revert it. Distros may want to use their own 
platform version.
Maybe Arch should do that in their JDK ?
But if you can help figure out the problem with Arch that would be great.
It looks like some difference in the runtime linking if that helps get 
you started.

-phil


On 12/7/20, 6:41 PM, Ty Young wrote:
>
> On 12/7/20 7:10 PM, Philip Race wrote:
>> Whilst we appreciate the report, we would never give an ETA here. It 
>> isn't a support channel.
>> I can say that it is being investigated but since it doesn't occur on 
>> a supported platform it is not a high priority.
>
>
> What is a supported platform? The only information after a quick 
> Google search gives:
>
>
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>
>
> Which only lists Oracle Enterprise Linux(Red Hat based?) and not Ubuntu.
>
>
> But I digress, as noted in the previously linked bug report, this is a 
> regression caused by your separation of libharfbuzz from 
> libfontmanager from:
>
>
> https://bugs.openjdk.java.net/browse/JDK-8249821
>
>
> And you can't or won't revert it?  What's the point of a 
> multi-platform UI API if you're going to break things just because you 
> feel like it? You realize there isn't a singular version of Ubuntu 
> too, right? Software built for the previous LTS won't necessarily work 
> on the newest versions or vice versa. if you only strictly support 
> Ubuntu 18.04 for example, Ubuntu 20.10 might not work and you probably 
> won't do anything about it?
>
>
> The bug "fix" is so seemingly unnecessary and caused way more harm 
> than good with multiple people running into breakage running otherwise 
> working software. Between all of the things being removed, deprecated, 
> and broken across the JDK versions over the last few years, you might 
> have enough content for a "killedbyoracle" website, similar to the 
> existing Google one.
>
>
>>
>> -phil.
>>
>> On 12/7/20, 5:03 PM, Ty Young wrote:
>>> Is there an ETA on when this will be fixed?
>>>
>>>
>>> On 12/7/20 3:47 PM, Philip Race wrote:
>>>> Yes. Sounds right. ALL reports of this so far are on an Arch Linux 
>>>> distro.
>>>> Not seen on Debian/Ubuntu or RH/OL/Centos
>>>>
>>>> -phil.
>>>>
>>>> On 12/7/20, 1:38 PM, Ty Young wrote:
>>>>> I use Arch Linux(btw), which is a "bleeding edge" Linux distro. 
>>>>> The distro mentioned in that bug report is based on Arch Linux.
>>>>>
>>>>>
>>>>> On 12/7/20 3:34 PM, Philip Race wrote:
>>>>>> Looks like https://bugs.openjdk.java.net/browse/JDK-8255790 which 
>>>>>> has not been
>>>>>> seen on any of our supported Linux configs - what are you using ?
>>>>>>
>>>>>> -phil
>>>>>>
>>>>>> On 12/7/20, 1:20 PM, Ty Young wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> Just sending this to report that as of right now there is 
>>>>>>> somekind of regression in the GTK bindings code that is causing 
>>>>>>> a segfault and as a result Netbeans (or presumably any other 
>>>>>>> IDE) will not run on JDK 16 on Linux. This doesn't happen with 
>>>>>>> Java 11. Here is the error trace that Netbeans spits out after 
>>>>>>> segfaulting:
>>>>>>>
>>>>>>>
>>>>>>> Current thread (0x00007f5cdc1364e0):  JavaThread 
>>>>>>> "AWT-EventQueue-0" [_thread_in_native, id=181601, 
>>>>>>> stack(0x00007f5cd5c2e000,0x00007f5cd5e2f000)]
>>>>>>>
>>>>>>> Stack: [0x00007f5cd5c2e000,0x00007f5cd5e2f000], 
>>>>>>> sp=0x00007f5cd5e2c058,  free space=2040k
>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>>>>>> j=interpreted, Vv=VM code, C=native code)
>>>>>>> C  0x00007f5c80de40cc
>>>>>>>
>>>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>>>>> j com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetXThickness(I)I+0 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> com.sun.java.swing.plaf.gtk.GTKStyle.<init>(Ljava/awt/Font;Lcom/sun/java/swing/plaf/gtk/GTKEngine$WidgetType;)V+24 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> com.sun.java.swing.plaf.gtk.GTKStyleFactory.getStyle(Ljavax/swing/JComponent;Ljavax/swing/plaf/synth/Region;)Ljavax/swing/plaf/synth/SynthStyle;+310 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initSystemColorDefaults(Ljavax/swing/UIDefaults;)V+53 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> com.sun.java.swing.plaf.gtk.GTKLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+33 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+66 
>>>>>>> java.desktop at 16-internal
>>>>>>> j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+34 
>>>>>>> java.desktop at 16-internal
>>>>>>> j  org.netbeans.swing.plaf.Startup.initialize()V+106
>>>>>>> j  org.netbeans.swing.plaf.Startup.<init>()V+25
>>>>>>> j 
>>>>>>> org.netbeans.swing.plaf.Startup.run(Ljava/lang/Class;ILjava/net/URL;Ljava/util/ResourceBundle;)V+44
>>>>>>> j  org.netbeans.core.CoreBridgeImpl$1$1.run()V+23
>>>>>>> J 3088 c1 java.awt.event.InvocationEvent.dispatch()V 
>>>>>>> java.desktop at 16-internal (69 bytes) @ 0x00007f5d593829ac 
>>>>>>> [0x00007f5d59382780+0x000000000000022c]
>>>>>>> J 3071 c1 
>>>>>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V 
>>>>>>> java.desktop at 16-internal (136 bytes) @ 0x00007f5d593786dc 
>>>>>>> [0x00007f5d59376b80+0x0000000000001b5c]
>>>>>>> J 3070 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; 
>>>>>>> java.desktop at 16-internal (60 bytes) @ 0x00007f5d593747bc 
>>>>>>> [0x00007f5d59374680+0x000000000000013c]
>>>>>>> J 3065 c1 
>>>>>>> java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V 
>>>>>>> java.desktop at 16-internal (80 bytes) @ 0x00007f5d59375424 
>>>>>>> [0x00007f5d59374e60+0x00000000000005c4]
>>>>>>> J 3074 c1 
>>>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(I)V 
>>>>>>> java.desktop at 16-internal (113 bytes) @ 0x00007f5d5937c934 
>>>>>>> [0x00007f5d5937c2a0+0x0000000000000694]
>>>>>>> j 
>>>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 
>>>>>>> java.desktop at 16-internal
>>>>>>> j 
>>>>>>> java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 
>>>>>>> java.desktop at 16-internal
>>>>>>> j  java.awt.EventDispatchThread.run()V+9 java.desktop at 16-internal
>>>>>>> v  ~StubRoutines::call_stub
>>>>>>>
>>>>>>>
>>>>>>> Much appreciated if this could be fixed.
>>>>>>>
>>>>>>>
>>>>>>>

From vdyakov at openjdk.java.net  Tue Dec  8 16:24:52 2020
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 8 Dec 2020 16:24:52 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors
In-Reply-To: <-fsvDkksOm3HbLmfYTMp2QXJPE8PzXwEjlvCWkdGm_0=.1a980da5-17ce-4934-9806-2c0201c80843@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <-fsvDkksOm3HbLmfYTMp2QXJPE8PzXwEjlvCWkdGm_0=.1a980da5-17ce-4934-9806-2c0201c80843@github.com>
Message-ID: <gWgRCePU8TBi_1neEIy8AHBPAuj8tphum-xK41_DkS0=.0b8b058a-f8c8-42a9-8443-6b69f7a6eb98@github.com>

On Wed, 2 Dec 2020 10:19:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
>> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
>> but support for rgba() is not present in JDK html text rendering.
>> 
>> Added support for rgba() to render translucent text color.
>
> any further comments?

@kizune please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/1158

From serb at openjdk.java.net  Wed Dec  9 02:59:33 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Dec 2020 02:59:33 GMT
Subject: <Swing Dev> RFR: 8196090:
 javax/swing/JComboBox/6559152/bug6559152.java fails
In-Reply-To: <K5pk2-myhUdDubiVoRnido2AfVgfIxEAHeDqdmGPSWw=.3bda6193-9834-4354-adc7-055c9bceeed3@github.com>
References: <K5pk2-myhUdDubiVoRnido2AfVgfIxEAHeDqdmGPSWw=.3bda6193-9834-4354-adc7-055c9bceeed3@github.com>
Message-ID: <YyudQjkmT9J9sTXNC2KCMhIAe_pKTxPvXT6UZLHhOgg=.a852d390-3a6d-4807-a658-c2a95e656634@github.com>

On Mon, 7 Dec 2020 13:13:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in mach5 nightly testing when ran in a group of all JComboBox tests.
> Modified few tests that were run prior to running this test by moving the frame to centre of screen, adjusting the event delay time to more consistent value in sync with other test and also made this test's frame gain focus by clicking on the frame, as it seems the frame does not get focus sometime so that keyevent does not get registered causing it to fail.
> Ran bunch of JComboBox test that were run prior to this tests in normal run, along with this test, in mach5 which is ok. Link in JBS.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1666

From serb at openjdk.java.net  Wed Dec  9 03:38:37 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Dec 2020 03:38:37 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>
References: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>
Message-ID: <m1KPfsee1LzjvL_Sb-37SBFOJgf2fdak25gzI0loZ2U=.f9d6bd92-c5d0-4457-b869-20bfaa46928a@github.com>

On Fri, 4 Dec 2020 17:30:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when using a JEditorPane to render HTML views with W3C_UNIT_LENGTHS enabled, font-sizes set using CSS are much larger than the same font size outside the HTML.
> It's because CSS LengthUnit uses screen resolution to calculate units so for hidpi screens, the html font size is bigger. 
> Fix is to calculate the units based on the CSS absolute length mentioned in https://drafts.csswg.org/css-values-3/#absolute-lengths so hidpi scaling is not applied twice in CSS and again by Java.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2867:

> 2865: 
> 2866:             // mapping according to the CSS2 spec
> 2867:             // https://drafts.csswg.org/css-values-3/#absolute-lengths

Are you sure that you can get the exact values of these absolute lengths without using a DPI of the screen? I mean that these values can be measured with a ruler on the screen and they must correspond to "cm" is one centimeter, and "in" is one "inch" etc.

BTW how the browsers handle that?

test/jdk/javax/swing/text/html/CSS/HtmlFontSizeTest.java line 28:

> 26:  * @key headful
> 27:  * @summary  Verifies if HTML font size too large with high-DPI scaling and W3C_UNIT_LENGTHS
> 28:  * @run main/othervm -Dsun.java2d.uiScale=1.0 HtmlFontSizeTest

Can we skip this flag and additionally check the multi screen configuration in the test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1628

From github.com+7334069+mperktold at openjdk.java.net  Wed Dec  9 14:54:36 2020
From: github.com+7334069+mperktold at openjdk.java.net (Matthias Perktold)
Date: Wed, 9 Dec 2020 14:54:36 GMT
Subject: <Swing Dev> RFR: 8231286: HTML font size too large with
 high-DPI scaling and W3C_UNIT_LENGTHS
In-Reply-To: <m1KPfsee1LzjvL_Sb-37SBFOJgf2fdak25gzI0loZ2U=.f9d6bd92-c5d0-4457-b869-20bfaa46928a@github.com>
References: <-jVAtf9GBLL4lTDyPsecYJ4kHnHj0ZK8bMEko5V4GLM=.9c04222b-ed0c-4d31-a159-0ca89661446b@github.com>
 <m1KPfsee1LzjvL_Sb-37SBFOJgf2fdak25gzI0loZ2U=.f9d6bd92-c5d0-4457-b869-20bfaa46928a@github.com>
Message-ID: <NhQX4vCtJpeRviClCLSeHA8srWv_TDH0B21MSYkLIZo=.3197c3bd-1dfb-480e-a94b-79404cfef425@github.com>

On Wed, 9 Dec 2020 03:34:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Issue is when using a JEditorPane to render HTML views with W3C_UNIT_LENGTHS enabled, font-sizes set using CSS are much larger than the same font size outside the HTML.
>> It's because CSS LengthUnit uses screen resolution to calculate units so for hidpi screens, the html font size is bigger. 
>> Fix is to calculate the units based on the CSS absolute length mentioned in https://drafts.csswg.org/css-values-3/#absolute-lengths so hidpi scaling is not applied twice in CSS and again by Java.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2867:
> 
>> 2865: 
>> 2866:             // mapping according to the CSS2 spec
>> 2867:             // https://drafts.csswg.org/css-values-3/#absolute-lengths
> 
> Are you sure that you can get the exact values of these absolute lengths without using a DPI of the screen? I mean that these values can be measured with a ruler on the screen and they must correspond to "cm" is one centimeter, and "in" is one "inch" etc.
> 
> BTW how the browsers handle that?

I opened this issue and suggested this fix because it is in line with how `px` were handled already, and fixes convertions between the various units.

> Are you sure that you can get the exact values of these absolute lengths without using a DPI of the screen?

It depends on how Java handles hi-DPI awareness in general, which I am not aware of.
Looking at the sources again, I've found `java.awt.GraphicsConfiguration#getDefaultTransform()` and `java.awt.GraphicsConfiguration#getNormalizingTransform()`, both of which are apparently related to hi-DPI awareness.

I think `getDefaultTransform` is usually used by the Runtime, and `getNormalizingTransform` is what we are looking for, acording to its JavaDoc:
> Returns an AffineTransform that can be concatenated with the default AffineTransform of a GraphicsConfiguration so that 72 units in user space equals 1 inch in device space. [...]

I was quite happy with the results without considering `getNormalizingTransform`, but maybe I was just lucky that it corresponds to the identity transformation for my setup.

> BTW how the browsers handle that?

Browsers have a `devicePixelRatio` indicating how many native device pixels form one CSS pixel (i.e. `px`).
On hi-DPI device, this value is greater than 1, e.g. 2, otherwise it is 1. It depends on the pixel density as well as on the usual viewing distance of the device.
The convertion between the various units is always a constant factor. Units such as `cm` or `in` are never precise, and thus not widely used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1628

From alitvinov at openjdk.java.net  Wed Dec  9 20:19:42 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Dec 2020 20:19:42 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed
Message-ID: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>

Hello colleagues,

Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.

ROOT CAUSE OF THE BUG:
"javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.

THE FIX:
The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".

Thank you,
Anton

-------------

Commit messages:
 - 8255880: UI of Swing components is not redrawn after their internal state changed

Changes: https://git.openjdk.java.net/jdk/pull/1722/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1722&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255880
  Stats: 200 lines in 2 files changed: 200 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1722/head:pull/1722

PR: https://git.openjdk.java.net/jdk/pull/1722

From prr at openjdk.java.net  Wed Dec  9 20:41:45 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 9 Dec 2020 20:41:45 GMT
Subject: <Swing Dev> RFR: 8256888: Client manual test problem list update
Message-ID: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>

Update the problem list.

-------------

Commit messages:
 - 8256888: Client manual test problem list update

Changes: https://git.openjdk.java.net/jdk/pull/1396/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256888
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1396.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1396/head:pull/1396

PR: https://git.openjdk.java.net/jdk/pull/1396

From serb at openjdk.java.net  Wed Dec  9 22:50:39 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Dec 2020 22:50:39 GMT
Subject: <Swing Dev> RFR: 8256019: JLabel HTML text does not support
 translucent text colors [v3]
In-Reply-To: <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>
References: <ZzkL8ZqJVoa-kuPtX_AY6LSHjHmSlaFCRubR4JcajVc=.6fbdb071-2141-4098-94c0-ba0fbf227668@github.com>
 <xqRuHMw5xsEWqTNvoWLzCL0f9a4Xyehehgglvmk6kN8=.24ce6dc3-9b80-4185-b978-d149cb2c365a@github.com>
Message-ID: <N29rY0xPmn-41BfJ70gx52mYeCmh422txLJvpmWaZ_8=.7d13fa5c-baa9-414f-b11f-3a1176300e87@github.com>

On Tue, 24 Nov 2020 13:02:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is a JLabel with a translucent foreground color properly renders plain text, but with HTML text, the alpha component is discarded and the text is rendered using an opaque color.
>> As per https://www.w3schools.com/cssref/func_rgba.asp, CSS supports rgba() to support alpha and render translucent text color
>> but support for rgba() is not present in JDK html text rendering.
>> 
>> Added support for rgba() to render translucent text color.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unneeded additional code

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1158

From serb at openjdk.java.net  Wed Dec  9 23:25:35 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 9 Dec 2020 23:25:35 GMT
Subject: <Swing Dev> RFR: 8256888: Client manual test problem list update
In-Reply-To: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
References: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
Message-ID: <yK-UISOO7NAaGjBkFk4WbkXJBTxHdbt2GcBPzxraUxs=.a0955b71-67d7-4fc1-9f0e-b94bb64c93fe@github.com>

On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the problem list.

test/jdk/ProblemList.txt line 877:

> 875: javax/swing/JTabbedPane/4666224/bug4666224.html 8144124  macosx-all
> 876: java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 8162380 generic-all
> 877: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java 8163086 macosx-all,linux-all

The failure of this test on Linux was reported on 02.2019 last time.  Since then only the problem on macOS is reported. Does the test actually fail on Linux right now?

test/jdk/ProblemList.txt line 889:

> 887: javax/swing/JTabbedPane/4209065/bug4209065.java 8251177 macosx-all
> 888: java/awt/TrayIcon/DragEventSource/DragEventSource.java 8252242 macosx-all
> 889: java/awt/FileDialog/DefaultFocusOwner/DefaultFocusOwner.java 7187728 macosx-all,linux-all,solaris-all

Al usage of Solaris-xxx in the problem list was removed by the https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046#diff-80063aaf72a19fa27f001c17fc7687086ea71b35b01f5e2b3fcd7f50d8c682fbL252

-------------

PR: https://git.openjdk.java.net/jdk/pull/1396

From prr at openjdk.java.net  Thu Dec 10 00:37:46 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Dec 2020 00:37:46 GMT
Subject: <Swing Dev> RFR: 8256888: Client manual test problem list
 update [v2]
In-Reply-To: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
References: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
Message-ID: <uJ6hJNi7mKZMK9EZTfos5z25iDQqNWpY0JsictSUYuA=.22c51a66-854a-45a6-a327-74dbd50104cf@github.com>

> Update the problem list.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8256888: Client manual test problem list update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1396/files
  - new: https://git.openjdk.java.net/jdk/pull/1396/files/df1507d9..767990eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1396.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1396/head:pull/1396

PR: https://git.openjdk.java.net/jdk/pull/1396

From prr at openjdk.java.net  Thu Dec 10 00:37:47 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Dec 2020 00:37:47 GMT
Subject: <Swing Dev> RFR: 8256888: Client manual test problem list update
In-Reply-To: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
References: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
Message-ID: <_Chji08BN84M5P0MNYGyhbxLmT547YOokIUxrXunQ88=.6340ed12-eb22-46a4-a5a4-65e00b1590b9@github.com>

On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the problem list.

I've removed the references to Solaris and the reference to Linux that was not needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1396

From serb at openjdk.java.net  Thu Dec 10 01:14:39 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 10 Dec 2020 01:14:39 GMT
Subject: <Swing Dev> RFR: 8256888: Client manual test problem list
 update [v2]
In-Reply-To: <uJ6hJNi7mKZMK9EZTfos5z25iDQqNWpY0JsictSUYuA=.22c51a66-854a-45a6-a327-74dbd50104cf@github.com>
References: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
 <uJ6hJNi7mKZMK9EZTfos5z25iDQqNWpY0JsictSUYuA=.22c51a66-854a-45a6-a327-74dbd50104cf@github.com>
Message-ID: <vhfr2ECuT41GMDbgq1Y_iUt1F7pf5QLY4Z_T94rkkn8=.6decfa18-28f8-44e1-8d7f-3b85cdb9f045@github.com>

On Thu, 10 Dec 2020 00:37:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the problem list.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256888: Client manual test problem list update

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1396

From prr at openjdk.java.net  Thu Dec 10 01:39:34 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 10 Dec 2020 01:39:34 GMT
Subject: <Swing Dev> Integrated: 8256888: Client manual test problem list
 update
In-Reply-To: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
References: <Gf4bBIIfJfInhexNdppHLBVfZQTv5Yg4LgKrLT6XvRg=.284efc42-7f91-4ab6-97f5-be6f972e592e@github.com>
Message-ID: <laqXVLmSQgfQ_eGgaZwCeRHw3viY-lS00m-4YYpF800=.21c94aae-cd89-4ac6-8f2b-148c54716ae9@github.com>

On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the problem list.

This pull request has now been integrated.

Changeset: f631a990
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f631a990
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8256888: Client manual test problem list update

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1396

From psadhukhan at openjdk.java.net  Thu Dec 10 13:35:41 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 10 Dec 2020 13:35:41 GMT
Subject: <Swing Dev> RFR: 8258040: Reenable fixed problemlisted test
Message-ID: <9PErrsBGvRZ3WhSoHN56h9QfZYP2YsGf-avrZo_ULTw=.a41f8b60-18ce-4b41-978a-54a2f01f9c97@github.com>

javax/swing/JPopupMenu/6675802/bug6675802.java was failing due to JDK-6847157 which has been subseqeuntly fixed, so this test should be removed from problemlist.
Ran several iterations of the test in mach5 which is green. Link in JBS.

-------------

Commit messages:
 - Reenable PL test

Changes: https://git.openjdk.java.net/jdk/pull/1735/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1735&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258040
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1735/head:pull/1735

PR: https://git.openjdk.java.net/jdk/pull/1735

From trebari at openjdk.java.net  Thu Dec 10 15:22:53 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 10 Dec 2020 15:22:53 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v3]
In-Reply-To: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
Message-ID: <4BCVCTQpLnOuz-g_Pu0oogTBlgzBQwH_vOBr_V8iAE0=.f0c8aa63-78ec-45d7-bfef-97460c82a33d@github.com>

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:

  reworked fix, also fixed for nimbus,motif,GTK LAF

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/65c08eda..036633b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=01-02

  Stats: 13 lines in 6 files changed: 0 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

From trebari at openjdk.java.net  Thu Dec 10 15:31:37 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 10 Dec 2020 15:31:37 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v3]
In-Reply-To: <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
Message-ID: <nCBpg9Uon4_TpbDZRTPcf4TIEUmsHd9aMLaTGrxVKxs=.88c66a74-e8ad-48ff-a25b-c2b18c2023ef@github.com>

On Wed, 14 Oct 2020 01:52:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reworked fix, also fixed for nimbus,motif,GTK LAF
>
> test/jdk/javax/swing/JPopupMenu/SetInvokerJPopupMenuTest.java line 145:
> 
>> 143:         public void setVisible( boolean state ) {
>> 144:             if( !state ) {
>> 145:                 Exception ex = new Exception();
> 
> It is unclear what is the purpose of this method?

This method is needed to reproduce the issue.
If we remove this method then the popup menu never goes off the screen after the the first mouse click.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From trebari at openjdk.java.net  Thu Dec 10 16:06:00 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 10 Dec 2020 16:06:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
Message-ID: <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:

  changed mode of files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/036633b4..f07a1729

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=600&range=02-03

  Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

From trebari at openjdk.java.net  Thu Dec 10 16:06:00 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 10 Dec 2020 16:06:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <rWc9A4Y7eS9lrk62Xnr9YPybFdfXQ7CDABxTiMp5jOY=.b8d20c35-b5a7-4085-a586-fa3f9fff249f@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
 <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
 <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>
 <rWc9A4Y7eS9lrk62Xnr9YPybFdfXQ7CDABxTiMp5jOY=.b8d20c35-b5a7-4085-a586-fa3f9fff249f@github.com>
Message-ID: <Kp4DgDkAWDlvbHmCSsq_s_iqPY3APca_G1tiz4ltXrg=.5e05f7d8-55b2-4903-abda-d46669d76528@github.com>

On Tue, 1 Dec 2020 02:40:27 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Well, the comment was added on Oct 15 and it got hidden on Oct28 because the ac was not of github author/committer. I think the fix submitter should have seen the comment lying there for 2 weeks before it got hidden.
>
> I have seen the comment, it is not visible in github but its there in mailing-list.
> 
> "It seems the effect is in WindowsLookAndFeel but you are fixing in Basic L&F. If the cause is in Basic L&F, then it
> would have affected other L&F also like Metal,Nimbus, doesn't it? If MouseGrabber not removed is the problem, the I
> guess MouseGrabber.uninstall() is not called. This is called in BasicLookAndFeel#uninitialize() and is overridden in
> WindowsLookAndFeel. Metal does not override this so maybe that's why the issue is not seen in Metal.  Probably the
> right fix is to call this MouseGrabber.uninstall() in Windows:LookAndFeel.uninitialize() same way as is done in
> BasicLookAndFeel.uninitialize()"
> 
> the current fix doesn't looks correct so working on finding the correct fix.

In case of the first attempt to bring down the popup menu the event was consumed by following code of BasicPopupMenuUI 
                     boolean consumeEvent =
                        UIManager.getBoolean("PopupMenu.consumeEventOnClose");
                    // Consume the event so that normal processing stops.
                    if(consumeEvent && !(src instanceof MenuElement)) {
                        me.consume();
                    }
The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and GTK LAF and this issue is seen in all these LookAndFeels.
For Metal LAF this variable is never set to true so it uses of BasicLookAndFeel which is set to FALSE
This issue is not seen on MetalLAF.

So changed  PopupMenu.consumeEventOnClose to FALSE for Windows, Motif, Nimbus, and GTK LAF and
 it fixes the issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From psadhukhan at openjdk.java.net  Fri Dec 11 04:57:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Dec 2020 04:57:56 GMT
Subject: <Swing Dev> Integrated: 8196090:
 javax/swing/JComboBox/6559152/bug6559152.java fails
In-Reply-To: <K5pk2-myhUdDubiVoRnido2AfVgfIxEAHeDqdmGPSWw=.3bda6193-9834-4354-adc7-055c9bceeed3@github.com>
References: <K5pk2-myhUdDubiVoRnido2AfVgfIxEAHeDqdmGPSWw=.3bda6193-9834-4354-adc7-055c9bceeed3@github.com>
Message-ID: <O3kdB1TjWLfkOXyEBDyAaR_Xr6kNdls1-W-U6beNro8=.3e713cf6-24a3-4df9-8a10-310e69c4f3bf@github.com>

On Mon, 7 Dec 2020 13:13:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in mach5 nightly testing when ran in a group of all JComboBox tests.
> Modified few tests that were run prior to running this test by moving the frame to centre of screen, adjusting the event delay time to more consistent value in sync with other test and also made this test's frame gain focus by clicking on the frame, as it seems the frame does not get focus sometime so that keyevent does not get registered causing it to fail.
> Ran bunch of JComboBox test that were run prior to this tests in normal run, along with this test, in mach5 which is ok. Link in JBS.

This pull request has now been integrated.

Changeset: b90b7f50
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b90b7f50
Stats:     68 lines in 5 files changed: 33 ins; 11 del; 24 mod

8196090: javax/swing/JComboBox/6559152/bug6559152.java fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1666

From serb at openjdk.java.net  Fri Dec 11 08:09:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 11 Dec 2020 08:09:03 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
Message-ID: <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>

On Wed, 2 Dec 2020 19:23:28 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258006: Replaces while cycles with iterator with enhanced for in java.desktop

The bug is filed:
https://bugs.openjdk.java.net/browse/JDK-8258006

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From github.com+741251+turbanoff at openjdk.java.net  Fri Dec 11 08:09:03 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 11 Dec 2020 08:09:03 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator with
 enhanced for in java.desktop
Message-ID: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>

8258006: Replaces while cycles with iterator with enhanced for in java.desktop

-------------

Commit messages:
 - [PATCH] Replaces while cycles with iterator with enhanced for in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/1574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258006
  Stats: 167 lines in 25 files changed: 0 ins; 99 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1574/head:pull/1574

PR: https://git.openjdk.java.net/jdk/pull/1574

From psadhukhan at openjdk.java.net  Fri Dec 11 10:21:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 11 Dec 2020 10:21:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <Kp4DgDkAWDlvbHmCSsq_s_iqPY3APca_G1tiz4ltXrg=.5e05f7d8-55b2-4903-abda-d46669d76528@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
 <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
 <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>
 <rWc9A4Y7eS9lrk62Xnr9YPybFdfXQ7CDABxTiMp5jOY=.b8d20c35-b5a7-4085-a586-fa3f9fff249f@github.com>
 <Kp4DgDkAWDlvbHmCSsq_s_iqPY3APca_G1tiz4ltXrg=.5e05f7d8-55b2-4903-abda-d46669d76528@github.com>
Message-ID: <c-OxxOqykn6KYvRDz8Uf6CzHH5gCkSMsuFmVqsC1dOc=.66bcf8df-6c15-4e01-abe3-b5cecd65560b@github.com>

On Thu, 10 Dec 2020 16:00:28 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> I have seen the comment, it is not visible in github but its there in mailing-list.
>> 
>> "It seems the effect is in WindowsLookAndFeel but you are fixing in Basic L&F. If the cause is in Basic L&F, then it
>> would have affected other L&F also like Metal,Nimbus, doesn't it? If MouseGrabber not removed is the problem, the I
>> guess MouseGrabber.uninstall() is not called. This is called in BasicLookAndFeel#uninitialize() and is overridden in
>> WindowsLookAndFeel. Metal does not override this so maybe that's why the issue is not seen in Metal.  Probably the
>> right fix is to call this MouseGrabber.uninstall() in Windows:LookAndFeel.uninitialize() same way as is done in
>> BasicLookAndFeel.uninitialize()"
>> 
>> the current fix doesn't looks correct so working on finding the correct fix.
>
> In case of the first attempt to bring down the popup menu the event was consumed by following code of BasicPopupMenuUI 
>                      boolean consumeEvent =
>                         UIManager.getBoolean("PopupMenu.consumeEventOnClose");
>                     // Consume the event so that normal processing stops.
>                     if(consumeEvent && !(src instanceof MenuElement)) {
>                         me.consume();
>                     }
> The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and GTK LAF and this issue is seen in all these LookAndFeels.
> For Metal LAF this variable is never set to true so it uses of BasicLookAndFeel which is set to FALSE
> This issue is not seen on MetalLAF.
> 
> So changed  PopupMenu.consumeEventOnClose to FALSE for Windows, Motif, Nimbus, and GTK LAF and
>  it fixes the issue.

Any idea why commenting popup.setInvoker(jtb); line in the test works even without the fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From prr at openjdk.java.net  Fri Dec 11 19:23:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Dec 2020 19:23:55 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed
In-Reply-To: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
Message-ID: <Bx9lbglyGrqGAsBqwGS7qPZ_UCjG7AzQxPe7gtFBhZo=.d6adebb5-9d76-4cba-a10a-803306f4d206@github.com>

On Wed, 9 Dec 2020 20:14:01 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello colleagues,
> 
> Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.
> 
> ROOT CAUSE OF THE BUG:
> "javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.
> 
> THE FIX:
> The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".
> 
> Thank you,
> Anton

The fix looks reasonable although I am surprised such an issue has existed for what I suppose is a long time.
One nit about the test regarding the requires.
It can't require solaris because there is no solaris support in JDK 16.
So unless you think this test will fail on other platforms (I hope not) it may be best to just remove this line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1722

From trebari at openjdk.java.net  Sat Dec 12 12:47:56 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Sat, 12 Dec 2020 12:47:56 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <c-OxxOqykn6KYvRDz8Uf6CzHH5gCkSMsuFmVqsC1dOc=.66bcf8df-6c15-4e01-abe3-b5cecd65560b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
 <EyZceoRBKmp4IOfIwSnRsDS9aI1Nl8UNWLZmIXVouOw=.18bc37ca-e093-4b50-b3d7-44374c1d76b2@github.com>
 <sDdPHJvv1ho7TWT6W8shIa8DZMJX940sPcHPrQoCRGo=.4bda0a66-99c3-4b4b-886a-fc4de645c46f@github.com>
 <xqjdFHtMGRipN_MU3WgYAURNApoZw16-f9-hexRN1YE=.2221e2f7-6283-4d11-8287-c5aeaf03b9b8@github.com>
 <DVUZhMVf3_lmQ6QCXXzWdysP66v-soh06u6kkBEFS-k=.f55767c7-5cd4-4327-80c4-b2c0c9ef9b97@github.com>
 <rWc9A4Y7eS9lrk62Xnr9YPybFdfXQ7CDABxTiMp5jOY=.b8d20c35-b5a7-4085-a586-fa3f9fff249f@github.com>
 <Kp4DgDkAWDlvbHmCSsq_s_iqPY3APca_G1tiz4ltXrg=.5e05f7d8-55b2-4903-abda-d46669d76528@github.com>
 <c-OxxOqykn6KYvRDz8Uf6CzHH5gCkSMsuFmVqsC1dOc=.66bcf8df-6c15-4e01-abe3-b5cecd65560b@github.com>
Message-ID: <fllsCeF5jQMbGsi-k-XRrV5DnbA0viZmpkVhKKqsCNA=.d8e68b6d-7e0b-4c83-ba20-a2f271823d02@github.com>

On Fri, 11 Dec 2020 10:18:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In case of the first attempt to bring down the popup menu the event was consumed by following code of BasicPopupMenuUI 
>>                      boolean consumeEvent =
>>                         UIManager.getBoolean("PopupMenu.consumeEventOnClose");
>>                     // Consume the event so that normal processing stops.
>>                     if(consumeEvent && !(src instanceof MenuElement)) {
>>                         me.consume();
>>                     }
>> The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and GTK LAF and this issue is seen in all these LookAndFeels.
>> For Metal LAF this variable is never set to true so it uses of BasicLookAndFeel which is set to FALSE
>> This issue is not seen on MetalLAF.
>> 
>> So changed  PopupMenu.consumeEventOnClose to FALSE for Windows, Motif, Nimbus, and GTK LAF and
>>  it fixes the issue.
>
> Any idea why commenting popup.setInvoker(jtb); line in the test works even without the fix?

In case of commenting popup.setInvoker(jtb); 
the following line of code in BasicPopupMenuUI is never called

boolean consumeEvent =UIManager.getBoolean("PopupMenu.consumeEventOnClose");
// Consume the event so that normal processing stops.
if(consumeEvent && !(src instanceof MenuElement)) {
me.consume();
}

So the event is not consumed here by me.consume() and the the issue is not seen.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From prr at openjdk.java.net  Sat Dec 12 23:07:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 12 Dec 2020 23:07:56 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
Message-ID: <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>

On Wed, 9 Dec 2020 23:50:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8258006: Replaces while cycles with iterator with enhanced for in java.desktop
>
> The bug is filed:
> https://bugs.openjdk.java.net/browse/JDK-8258006

Whilst this looks "reasonable" I am not impressed by the complete lack of description of 
1) why this is being proposed
2) what are the benefits
3) what testing has been done
etc etc.
The bug repoert is even more content free. It also deserves a meaningful description

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From prr at openjdk.java.net  Sat Dec 12 23:12:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 12 Dec 2020 23:12:56 GMT
Subject: <Swing Dev> RFR: 8258040: Reenable fixed problemlisted test
In-Reply-To: <9PErrsBGvRZ3WhSoHN56h9QfZYP2YsGf-avrZo_ULTw=.a41f8b60-18ce-4b41-978a-54a2f01f9c97@github.com>
References: <9PErrsBGvRZ3WhSoHN56h9QfZYP2YsGf-avrZo_ULTw=.a41f8b60-18ce-4b41-978a-54a2f01f9c97@github.com>
Message-ID: <Qb3Oqs2x9PgQuHu1ay3EjCyD9MTZQmZje2uiUw2KKjA=.edc1a7a6-c8d4-491f-bdc6-dd14fcbf5ded@github.com>

On Thu, 10 Dec 2020 13:29:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JPopupMenu/6675802/bug6675802.java was failing due to JDK-6847157 which has been subseqeuntly fixed, so this test should be removed from problemlist.
> Ran several iterations of the test in mach5 which is green. Link in JBS.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1735

From prr at openjdk.java.net  Sat Dec 12 23:35:58 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 12 Dec 2020 23:35:58 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <XF3OlbwNDJ09YyFSd4eGCGM4QyuSFOYYoI6O2mv8jY0=.f175f235-76a6-420f-a9dc-4d52480eae70@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
 <XF3OlbwNDJ09YyFSd4eGCGM4QyuSFOYYoI6O2mv8jY0=.f175f235-76a6-420f-a9dc-4d52480eae70@github.com>
Message-ID: <EXOY-yq8mqmZjjjd1fJuQfqSold_cWWRG2RgyN6cAxE=.326b7a26-865a-43cb-a893-7d93ec2f77e9@github.com>

On Tue, 1 Dec 2020 18:18:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.
>
>> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.
> 
> Can you try some small sample code and create the tabpane using Cocoa then set some state to the pane(like selected) and request its font?

Where exactly is this forum post ?
The current version of the fix isn't obviously hard-coding it. The source looks to be
NSColor selectedControlColor

how is that hard-coded ?

 Why isn't that sensitive to dark vs light theme ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From prr at openjdk.java.net  Sat Dec 12 23:37:57 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 12 Dec 2020 23:37:57 GMT
Subject: <Swing Dev> RFR: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <3h0puHJzh5Vgc-9wmgtsBjlqoW3mjnBcZxb88rtavMk=.58b41239-b47a-4f69-8864-cec09a36263b@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
 <txGuRtIYpXNUaUnXreWwb_PcA1Gi_AxdFTj5FCUzeYw=.d2f718c4-ef8e-4989-a969-4578e2b491c6@github.com>
 <isNErhKDLJBI-PWLJiflvotmP4i1aAim6Akcma5pxUM=.f192f9b3-c697-4190-ad30-39ff1318ba27@github.com>
 <aC_pugW0FZ_jnGWVtAewJWXHB7BjZzXG1CgSNKYjwJY=.bd7c44d9-5a8f-48ab-87e2-424025ecfea1@github.com>
 <OUWXWrZ9y6qKGnC2IYfbWmJDTCOJqsM3DfOrLfxUNYU=.0541ed89-1e70-440f-93fd-1b1f0586b6fa@github.com>
 <3h0puHJzh5Vgc-9wmgtsBjlqoW3mjnBcZxb88rtavMk=.58b41239-b47a-4f69-8864-cec09a36263b@github.com>
Message-ID: <bMRLAHOxn2_ZFAY9717H3OvQrWbeLDT0WEcVWHrWtTg=.194c59ce-af64-490e-adea-5040f6ea7171@github.com>

On Mon, 2 Nov 2020 12:16:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I meant to limit the font size in the tab-pane.
>> 
>> ok, just for clarification, you mean this should be fixed as product bug not test issue? We should limit the font size in AquaJTabbedPaneUI, so that the text is not truncated?
>
>> > I meant to limit the font size in the tab-pane.
>> 
>> ok, just for clarification, you mean this should be fixed as product bug not test issue? We should limit the font size in AquaJTabbedPaneUI, so that the text is not truncated?
> 
> Yes something like that in the JDK itself, I remember that menu items in the menubar on windows behave in a similar way, ignore the font size bigger some value.

If this fix is going to be done differently and isn't coming soon, can you withdraw the PR until it is ready

-------------

PR: https://git.openjdk.java.net/jdk/pull/984

From alitvinov at openjdk.java.net  Sun Dec 13 23:56:12 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Sun, 13 Dec 2020 23:56:12 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed [v2]
In-Reply-To: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
Message-ID: <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>

> Hello colleagues,
> 
> Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.
> 
> ROOT CAUSE OF THE BUG:
> "javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.
> 
> THE FIX:
> The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".
> 
> Thank you,
> Anton

Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:

  Removal of required platform restriction from the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1722/files
  - new: https://git.openjdk.java.net/jdk/pull/1722/files/c0b5d202..72ebe5ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1722&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1722&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1722/head:pull/1722

PR: https://git.openjdk.java.net/jdk/pull/1722

From prr at openjdk.java.net  Mon Dec 14 00:01:57 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Dec 2020 00:01:57 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed [v2]
In-Reply-To: <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
 <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>
Message-ID: <7vc5lBHvFi8AHXe8nyEWdtCaborXly_hqa7pIOBJE_M=.7a316957-a22d-49af-8ad9-e5824deb83b6@github.com>

On Sun, 13 Dec 2020 23:56:12 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello colleagues,
>> 
>> Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.
>> 
>> ROOT CAUSE OF THE BUG:
>> "javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.
>> 
>> THE FIX:
>> The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removal of required platform restriction from the test

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1722

From alitvinov at openjdk.java.net  Mon Dec 14 00:14:56 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Dec 2020 00:14:56 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed [v2]
In-Reply-To: <7vc5lBHvFi8AHXe8nyEWdtCaborXly_hqa7pIOBJE_M=.7a316957-a22d-49af-8ad9-e5824deb83b6@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
 <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>
 <7vc5lBHvFi8AHXe8nyEWdtCaborXly_hqa7pIOBJE_M=.7a316957-a22d-49af-8ad9-e5824deb83b6@github.com>
Message-ID: <ATp33aMZ1eDn-vj5BKC-yKXryGCBKArPLxQVSqZzZGw=.2a0f9402-bed6-49b3-b856-068d29618d96@github.com>

On Sun, 13 Dec 2020 23:58:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removal of required platform restriction from the test
>
> Marked as reviewed by prr (Reviewer).

Hello Phil. Thank you for review and already approval of the 2nd version of the fix, which has just been pushed in this branch. In the second commit I removed completely "@requires" tag from the regression test by your request. I verified that this test passes on Windows OS, macOS, Linux OS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1722

From psadhukhan at openjdk.java.net  Mon Dec 14 03:39:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 03:39:55 GMT
Subject: <Swing Dev> Integrated: 8258040: Reenable fixed problemlisted test
In-Reply-To: <9PErrsBGvRZ3WhSoHN56h9QfZYP2YsGf-avrZo_ULTw=.a41f8b60-18ce-4b41-978a-54a2f01f9c97@github.com>
References: <9PErrsBGvRZ3WhSoHN56h9QfZYP2YsGf-avrZo_ULTw=.a41f8b60-18ce-4b41-978a-54a2f01f9c97@github.com>
Message-ID: <_VBXP05jLVa9BJ1txakG3aWd-J8Fo9bGvnZCzeocwfs=.f69137db-4970-486b-af38-ed126c360485@github.com>

On Thu, 10 Dec 2020 13:29:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JPopupMenu/6675802/bug6675802.java was failing due to JDK-6847157 which has been subseqeuntly fixed, so this test should be removed from problemlist.
> Ran several iterations of the test in mach5 which is green. Link in JBS.

This pull request has now been integrated.

Changeset: e1182920
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e1182920
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8258040: Reenable fixed problemlisted test

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/1735

From psadhukhan at openjdk.java.net  Mon Dec 14 03:57:58 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 03:57:58 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
Message-ID: <fIb2U7K8UUtEwRPfNT4s4FfaTIxVxNrBflLdnUmRqvM=.97b4335a-57a7-4f43-8efc-a97d3e5fe900@github.com>

On Thu, 10 Dec 2020 16:06:00 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Please review the following fix for jdk16.
>> 
>> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
>> 1 - select button
>> 2 - menu posted
>> 3 - select button
>> 4 - menu taken down
>> 
>> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
>> 
>> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
>> 
>> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
>> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
>> 
>> Added a test to test the same in all the LookAndFeels
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed mode of files

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From psadhukhan at openjdk.java.net  Mon Dec 14 04:57:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 04:57:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <EXOY-yq8mqmZjjjd1fJuQfqSold_cWWRG2RgyN6cAxE=.326b7a26-865a-43cb-a893-7d93ec2f77e9@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
 <XF3OlbwNDJ09YyFSd4eGCGM4QyuSFOYYoI6O2mv8jY0=.f175f235-76a6-420f-a9dc-4d52480eae70@github.com>
 <EXOY-yq8mqmZjjjd1fJuQfqSold_cWWRG2RgyN6cAxE=.326b7a26-865a-43cb-a893-7d93ec2f77e9@github.com>
Message-ID: <RlkIhkddEDBP9foFSktiir7RNNPUtHW32QeLPWdMJxk=.1cdbe5a3-40fb-4178-ab28-82a45b2943b8@github.com>

On Sat, 12 Dec 2020 23:32:59 GMT, Phil Race <prr at openjdk.org> wrote:

>>> Since the apple forum post is still unanswered and if we want it to be fixed for JDK16, I dont see any other alternative than to fix by what I did in the 1st iteration of this by hardcoding. I dont think we are going to enable dark mode in JDk16 so we will have time to think on that when we enable that and hopefully Apple will come back by that time and we can revisit this.
>> 
>> Can you try some small sample code and create the tabpane using Cocoa then set some state to the pane(like selected) and request its font?
>
> Where exactly is this forum post ?
> The current version of the fix isn't obviously hard-coding it. The source looks to be
> NSColor selectedControlColor
> 
> how is that hard-coded ?
> 
>  Why isn't that sensitive to dark vs light theme ?

The forumpost is here https://discussions.apple.com/thread/252067605
The hardcoded being referred was in this 1st iteration of the fix
https://openjdk.github.io/cr/?repo=jdk&pr=1182&range=00

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From psadhukhan at openjdk.java.net  Mon Dec 14 08:23:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 08:23:00 GMT
Subject: <Swing Dev> RFR: 8196092:
 javax/swing/JComboBox/8032878/bug8032878.java fails
Message-ID: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>

Test was failing if JComboBox tests was run in group in nightly mach5 testing.
Modified test to remove dependancy from Util class, added delay before frame show and move frame to centre of screen.
Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

-------------

Commit messages:
 - 8196092: javax/swing/JComboBox/8032878/bug8032878.java fails

Changes: https://git.openjdk.java.net/jdk/pull/1762/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1762&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196092
  Stats: 21 lines in 2 files changed: 11 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1762/head:pull/1762

PR: https://git.openjdk.java.net/jdk/pull/1762

From serb at openjdk.java.net  Mon Dec 14 09:53:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Dec 2020 09:53:55 GMT
Subject: <Swing Dev> RFR: 8196092:
 javax/swing/JComboBox/8032878/bug8032878.java fails
In-Reply-To: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
References: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
Message-ID: <aCQ8fms6zberyll1mf9sZw-RNhn6_GJkvmn3yQcwv4c=.9d6558ae-6242-4d50-a065-1227ae51d704@github.com>

On Mon, 14 Dec 2020 08:17:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to remove dependancy from Util class, added delay before frame show and move frame to centre of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1762

From serb at openjdk.java.net  Mon Dec 14 10:03:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 14 Dec 2020 10:03:55 GMT
Subject: <Swing Dev> RFR: 8255880: UI of Swing components is not redrawn
 after their internal state changed [v2]
In-Reply-To: <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
 <HM46m1YMLCRrjFARZDFnHMPe1u2IbwNCWBaux1qkLAg=.4ff77188-d6b4-4125-b3b3-a25bf376c5c6@github.com>
Message-ID: <7WbW8upYUUU_BQGgjmx0PAV52Wl__W_DpM38UOditrA=.6e8edbb0-3354-4f9a-b003-3e54938b4215@github.com>

On Sun, 13 Dec 2020 23:56:12 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello colleagues,
>> 
>> Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.
>> 
>> ROOT CAUSE OF THE BUG:
>> "javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.
>> 
>> THE FIX:
>> The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removal of required platform restriction from the test

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1722

From pbansal at openjdk.java.net  Mon Dec 14 10:18:54 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 14 Dec 2020 10:18:54 GMT
Subject: <Swing Dev> RFR: 8196092:
 javax/swing/JComboBox/8032878/bug8032878.java fails
In-Reply-To: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
References: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
Message-ID: <Bw3YIBP4M9cddGWvlz6qk7vK5fJUJYfP9TI8B6uJHts=.92d967d0-f9e0-4669-b2f3-bdaabcb34a2e@github.com>

On Mon, 14 Dec 2020 08:17:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to remove dependancy from Util class, added delay before frame show and move frame to centre of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1762

From psadhukhan at openjdk.java.net  Mon Dec 14 11:37:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 11:37:55 GMT
Subject: <Swing Dev> Integrated: 8196092:
 javax/swing/JComboBox/8032878/bug8032878.java fails
In-Reply-To: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
References: <YF-rtcXKJJ1WhyMHnFSgvkYDO7q_tYom8ZMMFYtD8-0=.79d94097-99e6-4baf-b663-cb7616d5cd33@github.com>
Message-ID: <0bGKRBDLKjP7_qHHhzn5H_KzLSPpO1h6wlls-kSOCtI=.c03defa1-6234-43da-ace8-1c6a91c46534@github.com>

On Mon, 14 Dec 2020 08:17:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to remove dependancy from Util class, added delay before frame show and move frame to centre of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

This pull request has now been integrated.

Changeset: 2ee795d9
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ee795d9
Stats:     21 lines in 2 files changed: 11 ins; 4 del; 6 mod

8196092: javax/swing/JComboBox/8032878/bug8032878.java fails

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/1762

From pbansal at openjdk.java.net  Mon Dec 14 12:32:55 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 14 Dec 2020 12:32:55 GMT
Subject: <Swing Dev> Withdrawn: 8251177: [macosx] The text "big" is truncated
In-Reply-To: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
References: <rNcxvoN2-u9cW0z10kB4B34p4JtOCNpVgoIcTJ15s5c=.9cb97ff7-30c4-4639-9c09-fc3d8b777628@github.com>
Message-ID: <27Y0R1PXEIP0ggb4Q8eNHU1rEBRQH8ufdCrWX0qpGs4=.d4248bca-c5c7-4086-9f11-e085aecc6e5d@github.com>

On Sun, 1 Nov 2020 17:21:58 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> The manual test creates a JTabbedPane and add tabs with text with different html styles. For the tab with text "big", a bigger text size is used and it is expected that this should result in making the tab height bigger.
> 
> For AquaLookAndFeel, inside class AquaJTabbedPaneUI and AquaTabbedPaneCopyFromBasicUI, the tabs height is constraint and there is upper/lower limit set for tab height. So the tab height is less than expected and the text looks truncated. I do not see this issue in other L&Fs.
> 
> It looks like this is done deliberately for AquaL&F and this is not a bug. but the test instructions do not specify this and result in confusion. So updating the test instructions to specify that the text "big" may be truncated in MacOS.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/984

From psadhukhan at openjdk.java.net  Mon Dec 14 12:50:03 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 14 Dec 2020 12:50:03 GMT
Subject: <Swing Dev> RFR: 8258233: Reenable another fixed problemlisted test
Message-ID: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>

javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in mach5 testing but was fixed in JDK-8198004 later on, but this test was not removed from problemList. We can remove it from problemlist now.
Tested for several iteration in mach5. Link in JBS.

-------------

Commit messages:
 - 8258233: Reenable another fixed problemlisted test

Changes: https://git.openjdk.java.net/jdk/pull/1766/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1766&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258233
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1766.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1766/head:pull/1766

PR: https://git.openjdk.java.net/jdk/pull/1766

From trebari at openjdk.java.net  Mon Dec 14 13:25:54 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 14 Dec 2020 13:25:54 GMT
Subject: <Swing Dev> RFR: 8258233: Reenable another fixed problemlisted
 test
In-Reply-To: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
References: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
Message-ID: <3D2riO2APy-Iq1jR3zZ4Ts88a5_icQ4hX6rqtBdTC9o=.9fb1ea4c-f614-4da8-b583-ec8523b9c53f@github.com>

On Mon, 14 Dec 2020 12:45:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in mach5 testing but was fixed in JDK-8198004 later on, but this test was not removed from problemList. We can remove it from problemlist now.
> Tested for several iteration in mach5. Link in JBS.

Marked as reviewed by trebari (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1766

From alitvinov at openjdk.java.net  Mon Dec 14 14:38:59 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Dec 2020 14:38:59 GMT
Subject: <Swing Dev> Integrated: 8255880: UI of Swing components is not
 redrawn after their internal state changed
In-Reply-To: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
References: <SjW0T8Zu7X3FSlP3dqJxG2uhLLtyfb4wmzen8Dd9xpc=.4798be21-9db5-4270-bb90-0d7cbc46c6a7@github.com>
Message-ID: <rnJHcYTonzbxhzW3CVLHTv7QlEz8N5G2nPd578Zd_Rc=.608ec5cf-c4fa-4d65-90ed-0776ca34308a@github.com>

On Wed, 9 Dec 2020 20:14:01 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello colleagues,
> 
> Could you please review the fix for the bug specific to Linux OS and Solaris OS, which consists in the fact that, if Swing components are changed through standard public API of these components, while the frame containing these components is in "Frame.ICONIFIED" state or in other words minimized, then, when the frame becomes deiconified the UI of the Swing components does not reflect those changes.
> 
> ROOT CAUSE OF THE BUG:
> "javax.swing.RepaintManager.addDirtyRegion0(Container, int, int, int, int)" by design prevents updating regions of containers, when the containers are inside a frame with "Frame.ICONIFIED" state. And at the same time Linux OS specific JDK code does not initiate repaint of the frame, when the frame's peer is notified about change of state from "Frame.ICONIFIED" to other state. More details are available in the bug record.
> 
> THE FIX:
> The fix adds code to the method "sun.awt.X11.XFramePeer.handlePropertyNotify(XEvent)" which calls "repaint()" for instance of "XFramePeer", if its state changed from "Frame.ICONIFIED". The fix repeats the approach already existing in macOS specific code, which is in the method "sun.lwawt.LWWindowPeer.notifyIconify(boolean)".
> 
> Thank you,
> Anton

This pull request has now been integrated.

Changeset: e8c40baf
Author:    Anton Litvinov <alitvinov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8c40baf
Stats:     199 lines in 2 files changed: 199 ins; 0 del; 0 mod

8255880: UI of Swing components is not redrawn after their internal state changed

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1722

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 14 19:50:55 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 14 Dec 2020 19:50:55 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
Message-ID: <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>

On Sat, 12 Dec 2020 23:05:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> The bug is filed:
>> https://bugs.openjdk.java.net/browse/JDK-8258006
>
> Whilst this looks "reasonable" I am not impressed by the complete lack of description of 
> 1) why this is being proposed
> 2) what are the benefits
> 3) what testing has been done
> etc etc.
> The bug repoert is even more content free. It also deserves a meaningful description

I've added few words in description.

About testing: as I can see testing is done via Github Actions. tier1 builds are ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From prr at openjdk.java.net  Mon Dec 14 20:06:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Dec 2020 20:06:55 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
 <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
Message-ID: <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>

On Mon, 14 Dec 2020 19:48:36 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I've added few words in description.
> 
> About testing: as I can see testing is done via Github Actions. tier1 builds are ok.

OK that's better But about testing. The github actions won't run a single test that touches any code with these changes
All the client tests are in tier3-> tier5.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From psadhukhan at openjdk.java.net  Tue Dec 15 09:51:10 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 15 Dec 2020 09:51:10 GMT
Subject: <Swing Dev> RFR: 8196093:
 javax/swing/JComboBox/8072767/bug8072767.java fails
Message-ID: <m39zrSzOfIBLhxKpLy67Nkr1BytH_62_2GROy6w1HTg=.9a55877d-3449-482f-941a-9e65c7bf25bb@github.com>

Test was failing if JComboBox tests was run in group in nightly mach5 testing.
Modified test to move frame to centre of screen, add delays before frame show. Also updated the test that ran just before this test move frame to center of screen.
Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

-------------

Commit messages:
 - 8196093: javax/swing/JComboBox/8072767/bug8072767.java fails

Changes: https://git.openjdk.java.net/jdk/pull/1778/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1778&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196093
  Stats: 15 lines in 3 files changed: 4 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1778.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1778/head:pull/1778

PR: https://git.openjdk.java.net/jdk/pull/1778

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 15:24:03 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 15:24:03 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop [v2]
In-Reply-To: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
Message-ID: <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>

> There are few places in code where manual `while` loop is used with `Iterator` to iterate over `Collection`.
> Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling _enhanced-for_ cycle.
> 
> See similar cleanup in C++ code - #1707

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8258006: Replace 'while' cycles with iterator with enhanced 'for' in java.desktop

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1574&range=01
  Stats: 167 lines in 25 files changed: 0 ins; 99 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1574/head:pull/1574

PR: https://git.openjdk.java.net/jdk/pull/1574

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 17:16:55 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 17:16:55 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
 <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
 <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>
Message-ID: <3D-sUIk4a6Oqx9vB2QnpDPs_lVSMnLbcm9dSGC9T0EE=.7a72a072-7cd0-4427-aa25-034592a02dd9@github.com>

On Mon, 14 Dec 2020 20:04:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> I've added few words in description.
>> 
>> About testing: as I can see testing is done via Github Actions. tier1 builds are ok.
>
>> I've added few words in description.
>> 
>> About testing: as I can see testing is done via Github Actions. tier1 builds are ok.
> 
> OK that's better But about testing. The github actions won't run a single test that touches any code with these changes
> All the client tests are in tier3-> tier5.

I've run `test-tier3`. 15 tests failed. Looks like they are not related to my changes:

    JT Harness : Tests that failed
    Tests are grouped by their final status message.
    Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Rmid process exited with status 1 after 100ms.

        java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java: synopsis: need to modify registered ActivationDesc and ActivationGroupDesc 

    Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Test1 failed: a service would not restart

        java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java: synopsis: Activatable objects cannot be restarted. 

    Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: java.rmi.activation.ActivateFailedException: activation failed; nested exception is: java.rmi.activation.ActivationException: timeout creating child process

        java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java: rmid should annotate child process output
        java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java: synopsis: rmid should not destroy group when it reports inactiveGroup 

    Execution failed: `main' threw exception: java.lang.Error: text should be 1.1

        java/beans/PropertyEditor/TestDoubleClassValue.java: Tests PropertyEditor for value of type Double
        java/beans/PropertyEditor/TestDoubleTypeValue.java: Tests PropertyEditor for value of type double 

    Execution failed: `main' threw exception: java.lang.Error: values are not equal

        java/beans/PropertyEditor/TestDoubleClassJava.java: Tests PropertyEditor for value of type Double
        java/beans/PropertyEditor/TestDoubleTypeJava.java: Tests PropertyEditor for value of type double 

    Execution failed: `main' threw exception: java.lang.Exception: failures: 1

        sanity/client/SwingSet/src/ColorChooserDemoTest.java: Verifies SwingSet3 ColorChooserDemo by performing simple interaction with all the controls that are shown in the ColorChooserDialog. 

    Execution failed: `main' threw exception: java.lang.StackOverflowError

        java/beans/XMLEncoder/Test6531597.java: Tests encoding of arrays of primitives
        java/beans/XMLEncoder/Test6989223.java: Tests Rectangle2D.Double encoding
        java/beans/XMLEncoder/java_awt_GridBagConstraints.java: Tests GridBagConstraints encoding
        java/beans/XMLEncoder/java_awt_LinearGradientPaint.java: Tests LinearGradientPaint encoding
        java/beans/XMLEncoder/java_awt_RadialGradientPaint.java: Tests RadialGradientPaint encoding
        java/beans/XMLEncoder/java_awt_geom_AffineTransform.java: Tests AffineTransform encoding

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From prr at openjdk.java.net  Tue Dec 15 20:44:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Dec 2020 20:44:55 GMT
Subject: <Swing Dev> RFR: 8196093:
 javax/swing/JComboBox/8072767/bug8072767.java fails
In-Reply-To: <m39zrSzOfIBLhxKpLy67Nkr1BytH_62_2GROy6w1HTg=.9a55877d-3449-482f-941a-9e65c7bf25bb@github.com>
References: <m39zrSzOfIBLhxKpLy67Nkr1BytH_62_2GROy6w1HTg=.9a55877d-3449-482f-941a-9e65c7bf25bb@github.com>
Message-ID: <BWuNbq3EPCYR2HUi05Rd5DnAOaaFwLIrYSvj1jROtSw=.1035ec7b-d9e5-4945-a5d4-324c5bea0ffe@github.com>

On Tue, 15 Dec 2020 09:46:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to move frame to centre of screen, add delays before frame show. Also updated the test that ran just before this test move frame to center of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1778

From prr at openjdk.java.net  Tue Dec 15 20:49:01 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Dec 2020 20:49:01 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
Message-ID: <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>

On Thu, 19 Nov 2020 03:37:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On macOS 11 (bigsur) beta, using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, 
>> Proposed fix is to use dark color in light background so I used lightGray instead of "white" which is being used now, if we are on BigSur.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   name correction

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From prr at openjdk.java.net  Tue Dec 15 20:49:01 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Dec 2020 20:49:01 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible
In-Reply-To: <RlkIhkddEDBP9foFSktiir7RNNPUtHW32QeLPWdMJxk=.1cdbe5a3-40fb-4178-ab28-82a45b2943b8@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <1tz535gufWoNJ_jO-3KwmSsOfDHQN9Cqz-lvespNJpU=.bac9344b-310c-4af4-a623-0a29b2cc4eec@github.com>
 <5EU6riZkVpPCEF4g9XxJMtyfXiFEeV5A7Dd506uBn_w=.c3f68824-7756-4049-a3e2-52156bd8f014@github.com>
 <N7p7UzkSJr16E6KhZYLGLSlhVtXNNtBUkTz-USdjVzg=.825ed7ab-81e4-428e-b1ba-ec4646536393@github.com>
 <rGXF9tOcJqQqSVEumo3gRN7jkrWLRjE_6cRJPgDWBFU=.c4be29cb-427c-4ac2-bd5d-7c2393744d03@github.com>
 <Vmq_aQuvjv30FpNqhdSXpzOvK9fPsOFw1CVoGAey6eU=.f5b9d2e6-0b9b-4bc7-96ac-43fa6200c56c@github.com>
 <VsiKqbB9re5mRsLRYwVAOSxAhkNA6EGkxN2UD0kMeoI=.6e6d2051-1d64-497d-abd8-b8197a3caa0b@github.com>
 <ZgV7g3InFMypbgbeiockjSDojhBES1E0dvs-XK4Dy0w=.1293ca34-89cb-4e22-a60f-49027b48dadd@github.com>
 <XF3OlbwNDJ09YyFSd4eGCGM4QyuSFOYYoI6O2mv8jY0=.f175f235-76a6-420f-a9dc-4d52480eae70@github.com>
 <EXOY-yq8mqmZjjjd1fJuQfqSold_cWWRG2RgyN6cAxE=.326b7a26-865a-43cb-a893-7d93ec2f77e9@github.com>
 <RlkIhkddEDBP9foFSktiir7RNNPUtHW32Qe
 LPWdMJxk=.1cdbe5a3-40fb-4178-ab28-82a45b2943b8@github.com>
Message-ID: <Knbbage2h4T-lzV3VFg-_B1tZW2ZEQdNgSx1eavf_vU=.a2019e9d-a5f7-44b6-a27c-6d520cce9972@github.com>

On Mon, 14 Dec 2020 04:55:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The forumpost is here https://discussions.apple.com/thread/252067605
> The hardcoded being referred was in this 1st iteration of the fix
> https://openjdk.github.io/cr/?repo=jdk&pr=1182&range=00

OK. So I guess this could work for either light or dark theme but since we cache the result, if you switch theme whilst JDK is running it won't help - but we would have a bunch of work to do to support that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From prr at openjdk.java.net  Tue Dec 15 21:16:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 15 Dec 2020 21:16:56 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <3D-sUIk4a6Oqx9vB2QnpDPs_lVSMnLbcm9dSGC9T0EE=.7a72a072-7cd0-4427-aa25-034592a02dd9@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
 <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
 <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>
 <3D-sUIk4a6Oqx9vB2QnpDPs_lVSMnLbcm9dSGC9T0EE=.7a72a072-7cd0-4427-aa25-034592a02dd9@github.com>
Message-ID: <Rjx4MEDuAnwVT6nvY-KWBj4NeEengF7IFQE1rQBTYJs=.98ca1f20-5bcc-4d45-8235-a98071641976@github.com>

On Tue, 15 Dec 2020 17:14:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>>> I've added few words in description.
>>> 
>>> About testing: as I can see testing is done via Github Actions. tier1 builds are ok.
>> 
>> OK that's better But about testing. The github actions won't run a single test that touches any code with these changes
>> All the client tests are in tier3-> tier5.
>
> I've run `test-tier3`. 15 tests failed. Looks like they are not related to my changes:
> 
>     JT Harness : Tests that failed
>     Tests are grouped by their final status message.
>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Rmid process exited with status 1 after 100ms.
> 
>         java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java: synopsis: need to modify registered ActivationDesc and ActivationGroupDesc 
> 
>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Test1 failed: a service would not restart
> 
>         java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java: synopsis: Activatable objects cannot be restarted. 
> 
>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: java.rmi.activation.ActivateFailedException: activation failed; nested exception is: java.rmi.activation.ActivationException: timeout creating child process
> 
>         java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java: rmid should annotate child process output
>         java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java: synopsis: rmid should not destroy group when it reports inactiveGroup 
> 
>     Execution failed: `main' threw exception: java.lang.Error: text should be 1.1
> 
>         java/beans/PropertyEditor/TestDoubleClassValue.java: Tests PropertyEditor for value of type Double
>         java/beans/PropertyEditor/TestDoubleTypeValue.java: Tests PropertyEditor for value of type double 
> 
>     Execution failed: `main' threw exception: java.lang.Error: values are not equal
> 
>         java/beans/PropertyEditor/TestDoubleClassJava.java: Tests PropertyEditor for value of type Double
>         java/beans/PropertyEditor/TestDoubleTypeJava.java: Tests PropertyEditor for value of type double 
> 
>     Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
>         sanity/client/SwingSet/src/ColorChooserDemoTest.java: Verifies SwingSet3 ColorChooserDemo by performing simple interaction with all the controls that are shown in the ColorChooserDialog. 
> 
>     Execution failed: `main' threw exception: java.lang.StackOverflowError
> 
>         java/beans/XMLEncoder/Test6531597.java: Tests encoding of arrays of primitives
>         java/beans/XMLEncoder/Test6989223.java: Tests Rectangle2D.Double encoding
>         java/beans/XMLEncoder/java_awt_GridBagConstraints.java: Tests GridBagConstraints encoding
>         java/beans/XMLEncoder/java_awt_LinearGradientPaint.java: Tests LinearGradientPaint encoding
>         java/beans/XMLEncoder/java_awt_RadialGradientPaint.java: Tests RadialGradientPaint encoding
>         java/beans/XMLEncoder/java_awt_geom_AffineTransform.java: Tests AffineTransform encoding

These tests more or less *never* fail so how are you sure it is not your changes ?
And 8 beans tests failed and you made 3 changes in beans code so I'd like to see some evidence
to show these failures are unrelated and an explanation as to why these stable tests now fail ?
I don't think they are problem listed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From trebari at openjdk.java.net  Wed Dec 16 05:57:00 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 16 Dec 2020 05:57:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <Ku_uQ7fKW6mm4r1mYQVgw8EizOyibJp51u_A68M26lY=.85d8e475-7bfe-451b-b4f1-6caca155b35b@github.com>
Message-ID: <nWgUtL6oiWS35l1WGp7DHG-ZfSluhpM0UM6RoTHQhcM=.661a0afe-0c84-4357-a550-ea2e3d4762d8@github.com>

On Wed, 14 Oct 2020 01:52:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed mode of files
>
> Changes requested by serb (Reviewer).

@mrserb please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 15:02:56 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 15:02:56 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <Rjx4MEDuAnwVT6nvY-KWBj4NeEengF7IFQE1rQBTYJs=.98ca1f20-5bcc-4d45-8235-a98071641976@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
 <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
 <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>
 <3D-sUIk4a6Oqx9vB2QnpDPs_lVSMnLbcm9dSGC9T0EE=.7a72a072-7cd0-4427-aa25-034592a02dd9@github.com>
 <Rjx4MEDuAnwVT6nvY-KWBj4NeEengF7IFQE1rQBTYJs=.98ca1f20-5bcc-4d45-8235-a98071641976@github.com>
Message-ID: <lTP1rgdKrrZ601oDVjzOBjuxrw9T5JffKldy1Q3M7t8=.2a19d3a7-3323-4ead-987b-97f94da48f26@github.com>

On Tue, 15 Dec 2020 21:14:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> I've run `test-tier3`. 15 tests failed. Looks like they are not related to my changes:
>> 
>>     JT Harness : Tests that failed
>>     Tests are grouped by their final status message.
>>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Rmid process exited with status 1 after 100ms.
>> 
>>         java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java: synopsis: need to modify registered ActivationDesc and ActivationGroupDesc 
>> 
>>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: TestFailedException: TEST FAILED: Test1 failed: a service would not restart
>> 
>>         java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java: synopsis: Activatable objects cannot be restarted. 
>> 
>>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: java.rmi.activation.ActivateFailedException: activation failed; nested exception is: java.rmi.activation.ActivationException: timeout creating child process
>> 
>>         java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java: rmid should annotate child process output
>>         java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java: synopsis: rmid should not destroy group when it reports inactiveGroup 
>> 
>>     Execution failed: `main' threw exception: java.lang.Error: text should be 1.1
>> 
>>         java/beans/PropertyEditor/TestDoubleClassValue.java: Tests PropertyEditor for value of type Double
>>         java/beans/PropertyEditor/TestDoubleTypeValue.java: Tests PropertyEditor for value of type double 
>> 
>>     Execution failed: `main' threw exception: java.lang.Error: values are not equal
>> 
>>         java/beans/PropertyEditor/TestDoubleClassJava.java: Tests PropertyEditor for value of type Double
>>         java/beans/PropertyEditor/TestDoubleTypeJava.java: Tests PropertyEditor for value of type double 
>> 
>>     Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>> 
>>         sanity/client/SwingSet/src/ColorChooserDemoTest.java: Verifies SwingSet3 ColorChooserDemo by performing simple interaction with all the controls that are shown in the ColorChooserDialog. 
>> 
>>     Execution failed: `main' threw exception: java.lang.StackOverflowError
>> 
>>         java/beans/XMLEncoder/Test6531597.java: Tests encoding of arrays of primitives
>>         java/beans/XMLEncoder/Test6989223.java: Tests Rectangle2D.Double encoding
>>         java/beans/XMLEncoder/java_awt_GridBagConstraints.java: Tests GridBagConstraints encoding
>>         java/beans/XMLEncoder/java_awt_LinearGradientPaint.java: Tests LinearGradientPaint encoding
>>         java/beans/XMLEncoder/java_awt_RadialGradientPaint.java: Tests RadialGradientPaint encoding
>>         java/beans/XMLEncoder/java_awt_geom_AffineTransform.java: Tests AffineTransform encoding
>
> These tests more or less *never* fail so how are you sure it is not your changes ?
> And 8 beans tests failed and you made 3 changes in beans code so I'd like to see some evidence
> to show these failures are unrelated and an explanation as to why these stable tests now fail ?
> I don't think they are problem listed.

Oops. I also had changes from https://bugs.openjdk.java.net/browse/JDK-4511638 in my working tree.
After I reverted them only 3 tests failed in `test-tier3`:

    JT Harness : Tests that failed
    Tests are grouped by their final status message.
    Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: java.rmi.activation.ActivateFailedException: activation failed; nested exception is: java.rmi.activation.ActivationException: timeout creating child process

        java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java: rmid does not handle group restart for latecomer objects 

    Execution failed: `main' threw exception: java.lang.Exception: failures: 1

        sanity/client/SwingSet/src/ColorChooserDemoTest.java: Verifies SwingSet3 ColorChooserDemo by performing simple interaction with all the controls that are shown in the ColorChooserDialog.
        sanity/client/SwingSet/src/SwingSet2DemoTest.java: Verifies check box menu item, radio button menu item, nested menus and themes using SwingSet2 main window. 

    Report generated on Dec 16, 2020 5:54:22 PM
    Using JT Harness 6.0; built on November 30, 2020 at 12:00:00 AM MSK with java version "1.8.0_172"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 15:17:55 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 15:17:55 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop
In-Reply-To: <lTP1rgdKrrZ601oDVjzOBjuxrw9T5JffKldy1Q3M7t8=.2a19d3a7-3323-4ead-987b-97f94da48f26@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <GrOFD7yuVAZ7S9VEVXZijfB50BHiRrGOiwBocWCHELE=.09d32bf1-a03e-45a9-ac88-d14a6a759218@github.com>
 <0-jwcFGX120HimAS6zOwyWXaE2o21SGKRZuUbzFjYc4=.47a80aed-75e9-4788-a3a9-f32c989c206a@github.com>
 <6_qWqbMNRwSTEf_rllVnAH501WChHc1LWeR_6rvE8NU=.c28161e5-5428-4bda-96b9-bbb3e845ec21@github.com>
 <uBZ2iKK16XN-1sTKzbS3i-W19O2WgHwdY9kYUtO8Ne4=.afaffcb5-dc8f-439b-8de5-86233efc6495@github.com>
 <3D-sUIk4a6Oqx9vB2QnpDPs_lVSMnLbcm9dSGC9T0EE=.7a72a072-7cd0-4427-aa25-034592a02dd9@github.com>
 <Rjx4MEDuAnwVT6nvY-KWBj4NeEengF7IFQE1rQBTYJs=.98ca1f20-5bcc-4d45-8235-a98071641976@github.com>
 <lTP1rgdKrrZ601oDVjzOBjuxrw9T5JffKldy1Q3M7t8=.2a19d3a7-3323-4ead-987b-97f94da48f26@github.com>
Message-ID: <95R1EkCgUgaaFlaDCTGOxGrJ2RFSlkBHD6iZZp6AbwQ=.30281786-4bef-43b6-8fdd-e89c40cfef28@github.com>

On Wed, 16 Dec 2020 14:59:45 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> These tests more or less *never* fail so how are you sure it is not your changes ?
>> And 8 beans tests failed and you made 3 changes in beans code so I'd like to see some evidence
>> to show these failures are unrelated and an explanation as to why these stable tests now fail ?
>> I don't think they are problem listed.
>
> Oops. I also had changes from https://bugs.openjdk.java.net/browse/JDK-4511638 in my working tree.
> After I reverted them only 3 tests failed in `test-tier3`:
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>>> jtreg:test/jdk:tier3                               1192  1189     3     0 <<
>    jtreg:test/langtools:tier3                            0     0     0     0
>    jtreg:test/jaxp:tier3                                 0     0     0     0
> ==============================
> TEST FAILURE
> 
>     JT Harness : Tests that failed
>     Tests are grouped by their final status message.
>     Execution failed: `main' threw exception: TestFailedException: TEST FAILED: ; nested exception is: java.rmi.activation.ActivateFailedException: activation failed; nested exception is: java.rmi.activation.ActivationException: timeout creating child process
> 
>         java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java: rmid does not handle group restart for latecomer objects 
> 
>     Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
>         sanity/client/SwingSet/src/ColorChooserDemoTest.java: Verifies SwingSet3 ColorChooserDemo by performing simple interaction with all the controls that are shown in the ColorChooserDialog.
>         sanity/client/SwingSet/src/SwingSet2DemoTest.java: Verifies check box menu item, radio button menu item, nested menus and themes using SwingSet2 main window. 
> 
>     Report generated on Dec 16, 2020 5:54:22 PM
>     Using JT Harness 6.0; built on November 30, 2020 at 12:00:00 AM MSK with java version "1.8.0_172"

I tried to run this 3 tests separately - all passed. Looks like inference from other tests in test suite.
user at WORK-PC /cygdrive/f/Projects/official_openjdk
$ make test TEST="jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java"
Building target 'test' in configuration 'windows-x86_64-server-release'
Running tests using JTREG control variable 'VM_OPTIONS=-Duser.language=en -Duser.country=US'
Test selection 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java', will run:
* jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java

Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
Test results: passed: 1
Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
                                                         1     1     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'windows-x86_64-server-release'
user at WORK-PC /cygdrive/f/Projects/official_openjdk
$ make test TEST="jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java"
Building target 'test' in configuration 'windows-x86_64-server-release'
Running tests using JTREG control variable 'VM_OPTIONS=-Duser.language=en -Duser.country=US'
Test selection 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
* jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java

Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
Test results: passed: 1
Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
                                                         1     1     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'windows-x86_64-server-release'
user at WORK-PC /cygdrive/f/Projects/official_openjdk
$ make test TEST="jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java"
Building target 'test' in configuration 'windows-x86_64-server-release'
Running tests using JTREG control variable 'VM_OPTIONS=-Duser.language=en -Duser.country=US'
Test selection 'jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java', will run:
* jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java

Running test 'jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java'
Passed: java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java
Test results: passed: 1
Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_java_rmi_activation_Activatable_restartLatecomer_RestartLatecomer_java\html\report.html
Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_rmi_activation_Activatable_restartLatecomer_RestartLatecomer_java
Finished running test 'jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java'
Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_java_rmi_activation_Activatable_restartLatecomer_RestartLatecomer_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java
                                                         1     1     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'windows-x86_64-server-release'

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From prr at openjdk.java.net  Wed Dec 16 17:15:00 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 16 Dec 2020 17:15:00 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop [v2]
In-Reply-To: <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>
Message-ID: <8x2aulxTMTvDITwrKYmoHwSmUfXi87jzQ2LziEe6cz4=.65b11f34-7fce-4836-aee2-7a43f2814384@github.com>

On Tue, 15 Dec 2020 15:24:03 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> There are few places in code where manual `while` loop is used with `Iterator` to iterate over `Collection`.
>> Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
>> It doesn't have any performance impact: java compiler generates similar code when compiling _enhanced-for_ cycle.
>> 
>> See similar cleanup in C++ code - #1707
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8258006: Replace 'while' cycles with iterator with enhanced 'for' in java.desktop

Ok. Approved.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1574

From alitvinov at openjdk.java.net  Wed Dec 16 19:44:08 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 16 Dec 2020 19:44:08 GMT
Subject: <Swing Dev> [jdk16] RFR: 8255880: UI of Swing components is not
 redrawn after their internal state changed
Message-ID: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>

Hello,

This is a review request for straight back port of the fix for the bug JDK-8255880 from JDK 17 to JDK 16, which is currently in RDP 1 phase. The fix was tested and the regression test was executed on MS Windows OS, Linux OS, macOS.

Thank you,
Anton

-------------

Commit messages:
 - Backport e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa

Changes: https://git.openjdk.java.net/jdk16/pull/38/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=38&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255880
  Stats: 199 lines in 2 files changed: 199 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/38/head:pull/38

PR: https://git.openjdk.java.net/jdk16/pull/38

From prr at openjdk.java.net  Wed Dec 16 19:50:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 16 Dec 2020 19:50:56 GMT
Subject: <Swing Dev> [jdk16] RFR: 8255880: UI of Swing components is not
 redrawn after their internal state changed
In-Reply-To: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>
References: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>
Message-ID: <63M4jiS3ufkFFTWeung1fIVQGfXbsPsz4oCTwy5P3YE=.2b284642-8067-4fae-b195-32b01795331d@github.com>

On Wed, 16 Dec 2020 19:37:23 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello,
> 
> This is a review request for straight back port of the fix for the bug JDK-8255880 from JDK 17 to JDK 16, which is currently in RDP 1 phase. The fix was tested and the regression test was executed on MS Windows OS, Linux OS, macOS.
> 
> Thank you,
> Anton

Fine but in that casw why didn't you withdraw the 17 PR and just push to 16 which will get forward synced ?

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/38

From alitvinov at openjdk.java.net  Wed Dec 16 19:50:58 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 16 Dec 2020 19:50:58 GMT
Subject: <Swing Dev> [jdk16] Integrated: 8255880: UI of Swing components is
 not redrawn after their internal state changed
In-Reply-To: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>
References: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>
Message-ID: <cw8AWFfUDhtK7draYXduam1Igq2R2-GcX_P1eOqAWlA=.bb54cf70-a9d9-49f2-9985-3faceabf9e7e@github.com>

On Wed, 16 Dec 2020 19:37:23 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello,
> 
> This is a review request for straight back port of the fix for the bug JDK-8255880 from JDK 17 to JDK 16, which is currently in RDP 1 phase. The fix was tested and the regression test was executed on MS Windows OS, Linux OS, macOS.
> 
> Thank you,
> Anton

This pull request has now been integrated.

Changeset: 87644a2b
Author:    Anton Litvinov <alitvinov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/87644a2b
Stats:     199 lines in 2 files changed: 199 ins; 0 del; 0 mod

8255880: UI of Swing components is not redrawn after their internal state changed

Reviewed-by: prr
Backport-of: e8c40bafa51ed73247d2a03a8411cbcb0cdf4efa

-------------

PR: https://git.openjdk.java.net/jdk16/pull/38

From serb at openjdk.java.net  Wed Dec 16 21:09:11 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 16 Dec 2020 21:09:11 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in the
 JPasswordField
Message-ID: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>

- The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
 - The new implementation of setText() clean an internal data storage
 - Also some internal caches are cleaned as well

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk16/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=39&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258373
  Stats: 393 lines in 7 files changed: 392 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/39/head:pull/39

PR: https://git.openjdk.java.net/jdk16/pull/39

From alitvinov at openjdk.java.net  Wed Dec 16 23:49:59 2020
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 16 Dec 2020 23:49:59 GMT
Subject: <Swing Dev> [jdk16] RFR: 8255880: UI of Swing components is not
 redrawn after their internal state changed
In-Reply-To: <63M4jiS3ufkFFTWeung1fIVQGfXbsPsz4oCTwy5P3YE=.2b284642-8067-4fae-b195-32b01795331d@github.com>
References: <v2s7LO4RS-CHLWDp0KT5SycfA7kqIUhtodBrsRhDLxU=.4aac60f6-1138-4220-b07c-a27d49a0edb3@github.com>
 <63M4jiS3ufkFFTWeung1fIVQGfXbsPsz4oCTwy5P3YE=.2b284642-8067-4fae-b195-32b01795331d@github.com>
Message-ID: <fKlo4rwLThmuRDQxd2TbcQtIYC4NFFBSW7fD6AvFSzo=.c8361f76-8da2-48c9-89d8-582ee2e2261e@github.com>

On Wed, 16 Dec 2020 19:46:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Hello,
>> 
>> This is a review request for straight back port of the fix for the bug JDK-8255880 from JDK 17 to JDK 16, which is currently in RDP 1 phase. The fix was tested and the regression test was executed on MS Windows OS, Linux OS, macOS.
>> 
>> Thank you,
>> Anton
>
> Fine but in that casw why didn't you withdraw the 17 PR and just push to 16 which will get forward synced ?

Hello Phil. For me the main goal was to fix this bug in the latest JDK 
feature release, that is why I initiated integration to "openjdk/jdk" as 
soon as the fix was approved there. Integration of this fix to 
"openjdk/jdk" repository was my first integration to OpenJDK project in 
Git, at that moment I did not anticipate that obligatory synchronization 
from "openjdk/jdk16" to "openjdk/jdk" yet. Today based on the fact that 
this bug is P3 and not an enhancement and that following "fix-request" 
process in JBS is not prescribed for this type of bug in RDP 1 phase, 
and that this bug on Monday still was targeted to JDK 16, I came to a 
conclusion that there is legal right to go through this back port 
procedure to try to deliver the fix to JDK 16. I thought that there 
would not be a trouble during this synchronization, because in Mercurial 
such cases during merge were handled automatically silently. Hopefully 
Git will manage to handle it automatically.

I guarantee that this is the first and last time from my side, next 
times, if there are, I will not be initiating back ports to 
stabilization repositories in pre-RDP 2 phases, if the fix is integrated 
to always open repository.

On 16/12/2020 19:47, prrace wrote:
>
> *@prrace* approved this pull request.
>
> Fine but in that casw why didn't you withdraw the 17 PR and just push 
> to 16 which will get forward synced ?
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk16/pull/38*pullrequestreview-554028620__;Iw!!GqivPVa7Brio!Klj4EK4RrD6Ivj-inV3MaaZOe1byFdk_Gc3CiAQr3B7qKv70SsuZx4n6HCvGZl9q6Xg$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AQY7S7HOZTSK3ZGZNM3A5R3SVEFEBANCNFSM4U6PRW5Q__;!!GqivPVa7Brio!Klj4EK4RrD6Ivj-inV3MaaZOe1byFdk_Gc3CiAQr3B7qKv70SsuZx4n6HCvGh1BcT_U$>.
>

-------------

PR: https://git.openjdk.java.net/jdk16/pull/38

From psadhukhan at openjdk.java.net  Thu Dec 17 03:35:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 03:35:55 GMT
Subject: <Swing Dev> Integrated: 8196093:
 javax/swing/JComboBox/8072767/bug8072767.java fails
In-Reply-To: <m39zrSzOfIBLhxKpLy67Nkr1BytH_62_2GROy6w1HTg=.9a55877d-3449-482f-941a-9e65c7bf25bb@github.com>
References: <m39zrSzOfIBLhxKpLy67Nkr1BytH_62_2GROy6w1HTg=.9a55877d-3449-482f-941a-9e65c7bf25bb@github.com>
Message-ID: <z3YWbzZJHHieaOUQIgfLuerh8oPLNrJ-ICotVeYvtR4=.5af5ec0c-0e8a-478c-81f5-361bad6aad2a@github.com>

On Tue, 15 Dec 2020 09:46:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing if JComboBox tests was run in group in nightly mach5 testing.
> Modified test to move frame to centre of screen, add delays before frame show. Also updated the test that ran just before this test move frame to center of screen.
> Resultant modified test ran fine in JComboBox group and also in standalone, several iterations of which are ran in mach5. Link in JBS.

This pull request has now been integrated.

Changeset: 513269d2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/513269d2
Stats:     15 lines in 3 files changed: 4 ins; 4 del; 7 mod

8196093: javax/swing/JComboBox/8072767/bug8072767.java fails

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/1778

From psadhukhan at openjdk.java.net  Thu Dec 17 04:04:02 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 04:04:02 GMT
Subject: <Swing Dev> RFR: 8258554:
 javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F
Message-ID: <k2A81LKPOGz3k51owEubftBvIqbAVQoPxBs8QW6Db8s=.87d79f02-2b1f-4762-b198-be434b99ccb6@github.com>

This test tests whether creation of Renderers and Editors are delayed but in nimbus and subseqeuently in GTK L&F the renderers are created in installDefaults() [1] itself so it fails in GTKL&F.
As nimbus is already skipped in the test, it is modified to skip GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
Mach5 job running for several iterations for all platform is ok. Link in JBS.

[1] https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java#L118

-------------

Commit messages:
 - Fixed jcheck issue
 - 8258554: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F

Changes: https://git.openjdk.java.net/jdk/pull/1813/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1813&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258554
  Stats: 27 lines in 2 files changed: 15 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1813.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1813/head:pull/1813

PR: https://git.openjdk.java.net/jdk/pull/1813

From psadhukhan at openjdk.java.net  Thu Dec 17 04:22:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 04:22:55 GMT
Subject: <Swing Dev> RFR: 8258233: Reenable another fixed problemlisted
 test
In-Reply-To: <3D2riO2APy-Iq1jR3zZ4Ts88a5_icQ4hX6rqtBdTC9o=.9fb1ea4c-f614-4da8-b583-ec8523b9c53f@github.com>
References: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
 <3D2riO2APy-Iq1jR3zZ4Ts88a5_icQ4hX6rqtBdTC9o=.9fb1ea4c-f614-4da8-b583-ec8523b9c53f@github.com>
Message-ID: <viLXt7JxEAp1LDF9t8RD3U7JTNH8c4zKLYPukH_Xx8k=.eb5789aa-bb50-4a87-b9e5-48ff5fe61b24@github.com>

On Mon, 14 Dec 2020 13:23:06 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in mach5 testing but was fixed in JDK-8198004 later on, but this test was not removed from problemList. We can remove it from problemlist now.
>> Tested for several iteration in mach5. Link in JBS.
>
> Marked as reviewed by trebari (Committer).

Any "R"eviewers please?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1766

From psadhukhan at openjdk.java.net  Thu Dec 17 04:26:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 04:26:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
Message-ID: <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>

On Tue, 15 Dec 2020 20:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   name correction
>
> Marked as reviewed by prr (Reviewer).

@prrace Did you approve the 1st version of the fix [https://openjdk.github.io/cr/?repo=jdk&pr=1182&range=00]
or the current (4th) version? 
If 1st, is there any way to integrate the 1st version without updating the PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From jdv at openjdk.java.net  Thu Dec 17 04:35:00 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Dec 2020 04:35:00 GMT
Subject: <Swing Dev> RFR: 8258233: Reenable another fixed problemlisted
 test
In-Reply-To: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
References: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
Message-ID: <UJLt_NUrPxnf-xbkksj01Z1pAwhs_-aXxttPHRWcIQg=.61cc454a-ac63-4b07-8bb6-7ad80db9852a@github.com>

On Mon, 14 Dec 2020 12:45:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in mach5 testing but was fixed in JDK-8198004 later on, but this test was not removed from problemList. We can remove it from problemlist now.
> Tested for several iteration in mach5. Link in JBS.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1766

From psadhukhan at openjdk.java.net  Thu Dec 17 04:38:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 04:38:57 GMT
Subject: <Swing Dev> Integrated: 8258233: Reenable another fixed
 problemlisted test
In-Reply-To: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
References: <ZbiwsMcZh4SiTbC8KVZ2ThJQSBGRZ0SK6m2ix8BrFwM=.8688f464-bb15-40e8-9273-c4628de8da29@github.com>
Message-ID: <L08gMPUs5xi-rED0ntGsRyh6lBYR28LMU0O9EFloUtc=.cb7797e9-c6e5-4c47-8c58-14ef7b1e79d7@github.com>

On Mon, 14 Dec 2020 12:45:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in mach5 testing but was fixed in JDK-8198004 later on, but this test was not removed from problemList. We can remove it from problemlist now.
> Tested for several iteration in mach5. Link in JBS.

This pull request has now been integrated.

Changeset: d77b49d1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d77b49d1
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8258233: Reenable another fixed problemlisted test

Reviewed-by: trebari, jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/1766

From psadhukhan at openjdk.java.net  Thu Dec 17 05:05:02 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 05:05:02 GMT
Subject: <Swing Dev> RFR: 8258557: Deproblemlist fixed problemlisted test
Message-ID: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>

javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in nightly mach5 testing but was later fixed in JDK-6847157 but this test was not removed from ProblemList. 
We can remove this test from problemlist now.
mach5 job running for several iteration on all platforms is ok. Link in JBS.

-------------

Commit messages:
 - 8258557: Deproblemlist fixed problemlisted test

Changes: https://git.openjdk.java.net/jdk/pull/1814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1814&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258557
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1814/head:pull/1814

PR: https://git.openjdk.java.net/jdk/pull/1814

From philip.race at oracle.com  Thu Dec 17 07:57:51 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 16 Dec 2020 23:57:51 -0800
Subject: <Swing Dev> EA8 build of Project Lanai (Java 2D Metal rendering
 pipeline for macOS) is now posted
Message-ID: <5FDB0F7F.9030206@oracle.com>

The EA 8 build of Project Lanai [1] was posted today at 
https://jdk.java.net/lanai/

EA 8 Build 17-lanai+1-2 (2020/12/12)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of 
issues.

One particular request :
To anyone who has a mac still running 10.12 - we don't expect Metal to 
run (it requires at least 10.13
and maybe even later by the time it is final) but we would like 
confirmation that nothing in Metal
prevents OpenGL running on older releases.
Note there is currently a hotspot build bug unrelated to Lanai that 
prevents running on 10.10
and maybe 10.11 but 10.12 will be a useful data point.

EA 8 contains the following new bug fixes relative to EA 7

8257886: Build issue in macOS 10.14
8256683: Lanai: NetBeans IDE - AA Text rendering appears brighter 
compared to OpenGL
8242925: J2DDemo - Anti-Aliasing with Metal differs from OGL
8257618: Lanai: GradientPaint interpolates over stops limits
8257566: Lanai: System runs out of application memory while running the 
Unmanaged_BufferredImage_draw_NearestNeighbor test multiple times
8257441: Lanai: java/awt/image/VolatileImage/DrawHugeImageTest fails
8257442: Lanai: Create RenderPerf tests for SW to HW blits
8257413: Lanai - Use optimum sized temporary buffer while replacing 
texture region
8238285: Lanai: java/awt/image/DrawImage tests fail
8256576: DrawImage/BlitRotateClippedArea fails

-phil.

From trebari at openjdk.java.net  Thu Dec 17 08:00:56 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 17 Dec 2020 08:00:56 GMT
Subject: <Swing Dev> RFR: 8258557: Deproblemlist fixed problemlisted test
In-Reply-To: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
References: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
Message-ID: <M4wojAvMGiqgDVxHlKayh2Mb-_tCWG3Nh-kc_xwyKjo=.78a1b31d-a7de-437e-bc42-5b16ec8f9451@github.com>

On Thu, 17 Dec 2020 04:59:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in nightly mach5 testing but was later fixed in JDK-6847157 but this test was not removed from ProblemList. 
> We can remove this test from problemlist now.
> mach5 job running for several iteration on all platforms is ok. Link in JBS.

Marked as reviewed by trebari (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1814

From kcr at openjdk.java.net  Thu Dec 17 13:04:56 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 17 Dec 2020 13:04:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
Message-ID: <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>

On Thu, 17 Dec 2020 04:23:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>  If 1st, is there any way to integrate the 1st version without updating the PR?

No, this is not possible. If you need to integrate an earlier version, you will need to revert those changes in your local branch and push them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From kizune at openjdk.java.net  Thu Dec 17 16:39:00 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 17 Dec 2020 16:39:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
Message-ID: <DcmHSGVpEuZKE_oEeRZugTFYBRXi2fyHrkLGnuMMRzc=.2eb52d27-4be5-4293-b471-57eefad22db0@github.com>

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>  - The new implementation of setText() clean an internal data storage
>  - Also some internal caches are cleaned as well

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/39

From vdyakov at openjdk.java.net  Thu Dec 17 17:14:59 2020
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 17 Dec 2020 17:14:59 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <DcmHSGVpEuZKE_oEeRZugTFYBRXi2fyHrkLGnuMMRzc=.2eb52d27-4be5-4293-b471-57eefad22db0@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
 <DcmHSGVpEuZKE_oEeRZugTFYBRXi2fyHrkLGnuMMRzc=.2eb52d27-4be5-4293-b471-57eefad22db0@github.com>
Message-ID: <kTBmyVsTf8bdAlY1blaOtvEOqcIERjRw4T0AjGyd5HI=.b292297b-4429-42f4-bce3-a1db98b509a4@github.com>

On Thu, 17 Dec 2020 16:36:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>>  - The new implementation of setText() clean an internal data storage
>>  - Also some internal caches are cleaned as well
>
> Looks good.

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From psadhukhan at openjdk.java.net  Thu Dec 17 17:22:03 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 17 Dec 2020 17:22:03 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
Message-ID: <CDG_F_W5tTztmoL5j-v-RukdxFq_UGV1wPE_kzY7YsM=.d33ff04b-f615-4f76-b901-08a02b2fb811@github.com>

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>  - The new implementation of setText() clean an internal data storage
>  - Also some internal caches are cleaned as well

src/java.desktop/share/classes/javax/swing/JPasswordField.java line 286:

> 284:     @BeanProperty(bound = false, description = "the text of this component")
> 285:     public void setText(String t) {
> 286:         // overwrite the old data first

If we dont have javadoc for a public method, wouldn't build like make-docs fail?

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From prr at openjdk.java.net  Thu Dec 17 17:26:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Dec 2020 17:26:56 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
Message-ID: <IxS8yDjEU_vsnGwdkigPrivpxi5xtOfd0tHb4T9VTLU=.49c07491-7722-42fd-ba67-58e88a1155d0@github.com>

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>  - The new implementation of setText() clean an internal data storage
>  - Also some internal caches are cleaned as well

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From prr at openjdk.java.net  Thu Dec 17 18:05:59 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 17 Dec 2020 18:05:59 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
Message-ID: <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>

On Thu, 17 Dec 2020 13:02:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace Did you approve the 1st version of the fix [https://openjdk.github.io/cr/?repo=jdk&pr=1182&range=00]
>> or the current (4th) version? 
>> If 1st, is there any way to integrate the 1st version without updating the PR?
>
>>  If 1st, is there any way to integrate the 1st version without updating the PR?
> 
> No, this is not possible. If you need to integrate an earlier version, you will need to revert those changes in your local branch and push them.

I wouldn't know how to approve an earlier version. SFAIK I approved the current version.
One thing here though is that I think you should WITHDRAW this PR and re-submit for JDK 16.
I don't think we want to have to wait until JDK 17 to be able to read tabs on macOS 11.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From shurailine at openjdk.java.net  Thu Dec 17 21:51:05 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Thu, 17 Dec 2020 21:51:05 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test base
Message-ID: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>

Some changes to JSliderDemoTest: set a non-default driver and additional diagnostics

-------------

Commit messages:
 - JDK-8258645: Bring Jemmy 1.3.11 to JDK test base

Changes: https://git.openjdk.java.net/jdk/pull/1831/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1831&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258645
  Stats: 123 lines in 9 files changed: 69 ins; 9 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1831/head:pull/1831

PR: https://git.openjdk.java.net/jdk/pull/1831

From shurailine at openjdk.java.net  Thu Dec 17 21:51:05 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Thu, 17 Dec 2020 21:51:05 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
Message-ID: <QfFhBzfI4n6QuvUL_mDCkhCAdkKs6-Ms7_yOaipp-X0=.6fec122c-6d78-4050-9ed1-672e8c745006@github.com>

On Thu, 17 Dec 2020 21:45:50 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Some changes to JSliderDemoTest: set a non-default driver and additional diagnostics

@amresh-sahu @akolarkunnu , if you can take a look that would be great

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From serb at openjdk.java.net  Fri Dec 18 00:06:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 00:06:58 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
Message-ID: <GAvX33Zyi9RwEF_8Sj0tEmx_UkVmp6XfhxMHcWbiCXo=.06793fc8-3dfc-46c7-b755-3fae72a5a2b2@github.com>

On Thu, 17 Dec 2020 21:45:50 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Some changes to JSliderDemoTest: set a non-default driver and additional diagnostics

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From serb at openjdk.java.net  Fri Dec 18 00:10:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 00:10:57 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop [v2]
In-Reply-To: <8x2aulxTMTvDITwrKYmoHwSmUfXi87jzQ2LziEe6cz4=.65b11f34-7fce-4836-aee2-7a43f2814384@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>
 <8x2aulxTMTvDITwrKYmoHwSmUfXi87jzQ2LziEe6cz4=.65b11f34-7fce-4836-aee2-7a43f2814384@github.com>
Message-ID: <LEoa5rFMqo0v__4A_fGIW_SBC7cR-8paPHs2H2eAdE8=.e927301a-005c-4576-bd38-a9c3ff1e129b@github.com>

On Wed, 16 Dec 2020 17:11:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8258006: Replace 'while' cycles with iterator with enhanced 'for' in java.desktop
>
> Ok. Approved.

I'll run some other automated tests, in progress.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From serb at openjdk.java.net  Fri Dec 18 00:21:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 00:21:00 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
Message-ID: <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>

On Thu, 10 Dec 2020 16:06:00 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Please review the following fix for jdk16.
>> 
>> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
>> 1 - select button
>> 2 - menu posted
>> 3 - select button
>> 4 - menu taken down
>> 
>> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
>> 
>> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
>> 
>> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
>> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
>> 
>> Added a test to test the same in all the LookAndFeels
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed mode of files

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 806:

> 804: 
> 805: 
> 806:             "PopupMenu.consumeEventOnClose", Boolean.FALSE,

This property was added to support some kind of "native" behavior.
The code from the BasicPopupMenuUI.java:

                    // Ask UIManager about should we consume event that closes
                    // popup. This made to match native apps behaviour.
                    boolean consumeEvent =
                        UIManager.getBoolean("PopupMenu.consumeEventOnClose");
                    // Consume the event so that normal processing stops.
                    if(consumeEvent && !(src instanceof MenuElement)) {
                        me.consume();
                    }
So after this fix, the mouse event that causes the popup to close will be not be dispatched to the next component?

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From serb at openjdk.java.net  Fri Dec 18 01:30:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 01:30:58 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <CDG_F_W5tTztmoL5j-v-RukdxFq_UGV1wPE_kzY7YsM=.d33ff04b-f615-4f76-b901-08a02b2fb811@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
 <CDG_F_W5tTztmoL5j-v-RukdxFq_UGV1wPE_kzY7YsM=.d33ff04b-f615-4f76-b901-08a02b2fb811@github.com>
Message-ID: <vVaLfHLRKdodhF0dhpqwLVh3pWekz12_wo9Uvk2QgPE=.cece5c5c-63b1-4b05-97fb-3f84c098c08b@github.com>

On Thu, 17 Dec 2020 17:19:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>>  - The new implementation of setText() clean an internal data storage
>>  - Also some internal caches are cleaned as well
>
> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 286:
> 
>> 284:     @BeanProperty(bound = false, description = "the text of this component")
>> 285:     public void setText(String t) {
>> 286:         // overwrite the old data first
> 
> If we dont have javadoc for a public method, wouldn't build like make-docs fail?

"make docs" works fine.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From psadhukhan at openjdk.java.net  Fri Dec 18 03:31:57 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 18 Dec 2020 03:31:57 GMT
Subject: <Swing Dev> [jdk16] RFR: 8258373: Update the text handling in
 the JPasswordField
In-Reply-To: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
Message-ID: <JWrj0oBVB1z9vGYQMp6Z_xvvf8Mn4eR77wVrdCkJa6Q=.c4c54be1-8686-4a31-8a8d-cb3ae9968026@github.com>

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>  - The new implementation of setText() clean an internal data storage
>  - Also some internal caches are cleaned as well

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From psadhukhan at openjdk.java.net  Fri Dec 18 03:38:02 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 18 Dec 2020 03:38:02 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
Message-ID: <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>

On Thu, 17 Dec 2020 18:03:04 GMT, Phil Race <prr at openjdk.org> wrote:

>>>  If 1st, is there any way to integrate the 1st version without updating the PR?
>> 
>> No, this is not possible. If you need to integrate an earlier version, you will need to revert those changes in your local branch and push them.
>
> I wouldn't know how to approve an earlier version. SFAIK I approved the current version.
> One thing here though is that I think you should WITHDRAW this PR and re-submit for JDK 16.
> I don't think we want to have to wait until JDK 17 to be able to read tabs on macOS 11.

The current version has the issue of text color obtained through [selectedControlColor] being changed through "Preferences->General->Accent Color", which is not in our control, which was already discussed. So, I thought the 1st version, which is more robust, is the one which is approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Fri Dec 18 06:28:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 06:28:56 GMT
Subject: <Swing Dev> [jdk16] Integrated: 8258373: Update the text handling
 in the JPasswordField
In-Reply-To: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
References: <f9IHcpf2bDifp95bdWpQNRBgh0S5OkXkG95Vn8zqft4=.887a97c8-6237-4f3f-a288-4ddea493f1c9@github.com>
Message-ID: <iAq1u_x5IRgcqv40moIanfNmPkeq9xIQi3l-HVup9zc=.c8ac9825-7518-4b18-9f59-cb747db48da2@github.com>

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The JTextComponent.setText() is overidden in the JPasswordField to make the "text" property non-"bound" in the JPasswordField, same as in the JTextComponent
>  - The new implementation of setText() clean an internal data storage
>  - Also some internal caches are cleaned as well

This pull request has now been integrated.

Changeset: 7afb01dc
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/7afb01dc
Stats:     393 lines in 7 files changed: 392 ins; 0 del; 1 mod

8258373: Update the text handling in the JPasswordField

Reviewed-by: kizune, prr, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk16/pull/39

From trebari at openjdk.java.net  Fri Dec 18 07:52:58 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Fri, 18 Dec 2020 07:52:58 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
 <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
Message-ID: <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>

On Fri, 18 Dec 2020 00:18:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed mode of files
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 806:
> 
>> 804: 
>> 805: 
>> 806:             "PopupMenu.consumeEventOnClose", Boolean.FALSE,
> 
> This property was added to support some kind of "native" behavior.
> The code from the BasicPopupMenuUI.java:
> 
>                     // Ask UIManager about should we consume event that closes
>                     // popup. This made to match native apps behaviour.
>                     boolean consumeEvent =
>                         UIManager.getBoolean("PopupMenu.consumeEventOnClose");
>                     // Consume the event so that normal processing stops.
>                     if(consumeEvent && !(src instanceof MenuElement)) {
>                         me.consume();
>                     }
> So after this fix, the mouse event that causes the popup to close will be not be dispatched to the next component?

Before the fix the mouse event that cause the popup to close  was consumed here as the "PopupMenu.consumeEventOnClose" was true.

After the fix the mouse event that cause the popup to close will not be consumed here as  "PopupMenu.consumeEventOnClose" is set to false in the fix for Windows, GTK, Nimbus and Motif LAF.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From akolarkunnu at openjdk.java.net  Fri Dec 18 09:21:55 2020
From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu)
Date: Fri, 18 Dec 2020 09:21:55 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <GAvX33Zyi9RwEF_8Sj0tEmx_UkVmp6XfhxMHcWbiCXo=.06793fc8-3dfc-46c7-b755-3fae72a5a2b2@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
 <GAvX33Zyi9RwEF_8Sj0tEmx_UkVmp6XfhxMHcWbiCXo=.06793fc8-3dfc-46c7-b755-3fae72a5a2b2@github.com>
Message-ID: <53seybwR4fRhgsj8BRzb7Sn0p-7zVHtkVrERfD0Bktg=.17509b22-b197-46de-ab4c-3c47751a34f7@github.com>

On Fri, 18 Dec 2020 00:04:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Some changes to JSliderDemoTest: set a non-default driver and additional diagnostics
>
> Marked as reviewed by serb (Reviewer).

Some general comments: 
JBS CODETOOLS tasks are still in NEW status, but corresponding codes are already checkedin
https://bugs.openjdk.java.net/browse/CODETOOLS-7902736
https://bugs.openjdk.java.net/browse/CODETOOLS-7902811 

A little info in JBS task/RFR, better to list all CODETOOLS(jemmy) fixes are integrating as part of this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From github.com+72060147+amresh-sahu at openjdk.java.net  Fri Dec 18 11:39:26 2020
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Fri, 18 Dec 2020 11:39:26 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <53seybwR4fRhgsj8BRzb7Sn0p-7zVHtkVrERfD0Bktg=.17509b22-b197-46de-ab4c-3c47751a34f7@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
 <GAvX33Zyi9RwEF_8Sj0tEmx_UkVmp6XfhxMHcWbiCXo=.06793fc8-3dfc-46c7-b755-3fae72a5a2b2@github.com>
 <53seybwR4fRhgsj8BRzb7Sn0p-7zVHtkVrERfD0Bktg=.17509b22-b197-46de-ab4c-3c47751a34f7@github.com>
Message-ID: <_j5Gh1mRluZS2fXVWlNcIBdArKTW47lCetNweIgQ1Kg=.bdf1d669-6347-4834-bd83-e3862b557ff6@github.com>

On Fri, 18 Dec 2020 09:19:05 GMT, Abdul Kolarkunnu <akolarkunnu at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> Some general comments: 
> JBS CODETOOLS tasks are still in NEW status, but corresponding codes are already checkedin
> https://bugs.openjdk.java.net/browse/CODETOOLS-7902736
> https://bugs.openjdk.java.net/browse/CODETOOLS-7902811 
> 
> A little info in JBS task/RFR, better to list all CODETOOLS(jemmy) fixes are integrating as part of this.
> 
> Changes are looking good.

LGTM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From kcr at openjdk.java.net  Fri Dec 18 13:03:26 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 18 Dec 2020 13:03:26 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
Message-ID: <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>

On Fri, 18 Dec 2020 03:35:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I wouldn't know how to approve an earlier version. SFAIK I approved the current version.
>> One thing here though is that I think you should WITHDRAW this PR and re-submit for JDK 16.
>> I don't think we want to have to wait until JDK 17 to be able to read tabs on macOS 11.
>
> The current version has the issue of text color obtained through [selectedControlColor] being changed through "Preferences->General->Accent Color", which is not in our control, which was already discussed. So, I thought the 1st version, which is more robust, is the one which is approved.

If you want to go back to the first version, then you will need to revert the changes from the subsequent commits and push a new commit.

However, please see Phil's comment above: since this should go into JDK 16, you will need to create a personal fork of jdk16, clone that repo, push your patch to a new branch in that repo, and create a PR from that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From javalists at cbfiddle.com  Fri Dec 18 15:57:56 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 18 Dec 2020 07:57:56 -0800
Subject: <Swing Dev> EA8 build of Project Lanai (Java 2D Metal rendering
 pipeline for macOS) is now posted
In-Reply-To: <5FDB0F7F.9030206@oracle.com>
References: <5FDB0F7F.9030206@oracle.com>
Message-ID: <CD5A73C1-E85E-4278-B224-FE84A15EC295@cbfiddle.com>



> On Dec 16, 2020, at 11:57 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> To anyone who has a mac still running 10.12 - we don't expect Metal to run (it requires at least 10.13
> and maybe even later by the time it is final) but we would like confirmation that nothing in Metal
> prevents OpenGL running on older releases.
> Note there is currently a hotspot build bug unrelated to Lanai that prevents running on 10.10
> and maybe 10.11 but 10.12 will be a useful data point.

I tried running it on macOS 10.12 under Parallels Desktop.

If I don?t ask for metal, it seems to work.

If I ask for metal, it fails awkwardly:

Failed to load library. error (null)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201218/25ed08c5/attachment.htm>

From vdyakov at openjdk.java.net  Fri Dec 18 19:05:59 2020
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 18 Dec 2020 19:05:59 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
Message-ID: <hVE6fSK71p6s-rXcx42HA0XoBrz-MRJOdfTRh1Y9AvI=.c092566b-81d5-4c2b-b654-7974f885a315@github.com>

On Thu, 10 Dec 2020 16:06:00 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Please review the following fix for jdk16.
>> 
>> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when the button is selected. If the button is selected and the menu is not posted the action listener will post the menu. If the button is selected and the menu is displayed the action listener will take the menu down. The use case is:
>> 1 - select button
>> 2 - menu posted
>> 3 - select button
>> 4 - menu taken down
>> 
>> With MetalLookAndFeel the above use case works fine, but with WindowsLookAndFeel the second button selection does not fire the actionPerformed event,  button needs to be selected third time for the menu to be taken down.
>> 
>> The issue is that the button must be selected twice after the menu is posted to have the actionPerformed event to fire when using the Windows look and feel.
>> 
>> Fix : MouseGrabber is not removed while uninstalling the listeners in the BasicPopupMenuUI.
>> By removing the mouseGrabber in the uninstallListeners() methods fixes this issue.
>> 
>> Added a test to test the same in all the LookAndFeels
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed mode of files

Marked as reviewed by vdyakov (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From shurailine at openjdk.java.net  Fri Dec 18 21:19:54 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Fri, 18 Dec 2020 21:19:54 GMT
Subject: <Swing Dev> RFR: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <_j5Gh1mRluZS2fXVWlNcIBdArKTW47lCetNweIgQ1Kg=.bdf1d669-6347-4834-bd83-e3862b557ff6@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
 <GAvX33Zyi9RwEF_8Sj0tEmx_UkVmp6XfhxMHcWbiCXo=.06793fc8-3dfc-46c7-b755-3fae72a5a2b2@github.com>
 <53seybwR4fRhgsj8BRzb7Sn0p-7zVHtkVrERfD0Bktg=.17509b22-b197-46de-ab4c-3c47751a34f7@github.com>
 <_j5Gh1mRluZS2fXVWlNcIBdArKTW47lCetNweIgQ1Kg=.bdf1d669-6347-4834-bd83-e3862b557ff6@github.com>
Message-ID: <eOkEwVJiZKsIQ_Kgf-ilBaya_2cWxIft4YAbiJBiM1c=.dffcc47f-b492-40a5-a768-29dda58c9380@github.com>

On Fri, 18 Dec 2020 11:36:38 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

>> Some general comments: 
>> JBS CODETOOLS tasks are still in NEW status, but corresponding codes are already checkedin
>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902736
>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902811 
>> 
>> A little info in JBS task/RFR, better to list all CODETOOLS(jemmy) fixes are integrating as part of this.
>> 
>> Changes are looking good.
>
> LGTM.

Linked the related issued form the bug.

Thanks

> On Dec 18, 2020, at 1:19 AM, Muneer Kolarkunnu <notifications at github.com> wrote:
> 
> 
> Some general comments:
> JBS CODETOOLS tasks are still in NEW status, but corresponding codes are already checkedin
> https://bugs.openjdk.java.net/browse/CODETOOLS-7902736 <https://bugs.openjdk.java.net/browse/CODETOOLS-7902736>
> https://bugs.openjdk.java.net/browse/CODETOOLS-7902811 <https://bugs.openjdk.java.net/browse/CODETOOLS-7902811>
> A little info in JBS task/RFR, better to list all CODETOOLS(jemmy) fixes are integrating as part of this.
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1831*issuecomment-747965917__;Iw!!GqivPVa7Brio!KYZ5dXudJoL8o4P3va-Vk_I-vv44I0HFaD_zKF4XbQJz5R-mRUKiy0f_hgGotsQGxmc$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABN6PZUFNCY4Y2G5KHRN7M3SVMNBTANCNFSM4VAJLRNQ__;!!GqivPVa7Brio!KYZ5dXudJoL8o4P3va-Vk_I-vv44I0HFaD_zKF4XbQJz5R-mRUKiy0f_hgGoXX8NQvg$>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From shurailine at openjdk.java.net  Fri Dec 18 21:19:55 2020
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Fri, 18 Dec 2020 21:19:55 GMT
Subject: <Swing Dev> Integrated: JDK-8258645: Bring Jemmy 1.3.11 to JDK test
 base
In-Reply-To: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
References: <QrI7UlWUoTW7mHNV46MfnXfkSwryV6D3Y-xaCwWlqEM=.5f1af30b-d589-4dcb-af4b-e941b6dd5bdc@github.com>
Message-ID: <YE16KHyCUl5R_11_mlkDMePb-GD3CyTIc4kJZjJy6Us=.708c2fae-4e02-4fed-a6e6-0b6b3199cd5a@github.com>

On Thu, 17 Dec 2020 21:45:50 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Some changes to JSliderDemoTest: set a non-default driver and additional diagnostics

This pull request has now been integrated.

Changeset: 6a78b2a2
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a78b2a2
Stats:     123 lines in 9 files changed: 69 ins; 9 del; 45 mod

8258645: Bring Jemmy 1.3.11 to JDK test base

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1831

From serb at openjdk.java.net  Fri Dec 18 21:41:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 21:41:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
Message-ID: <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>

On Fri, 18 Dec 2020 13:00:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The current version has the issue of text color obtained through [selectedControlColor] being changed through "Preferences->General->Accent Color", which is not in our control, which was already discussed. So, I thought the 1st version, which is more robust, is the one which is approved.
>
> If you want to go back to the first version, then you will need to revert the changes from the subsequent commits and push a new commit.
> 
> However, please see Phil's comment above: since this should go into JDK 16, you will need to create a personal fork of jdk16, clone that repo, push your patch to a new branch in that repo, and create a PR from that.

> > The forumpost is here https://discussions.apple.com/thread/252067605
> > The hardcoded being referred was in this 1st iteration of the fix
> > https://openjdk.github.io/cr/?repo=jdk&pr=1182&range=00
> 
> OK. So I guess this could work for either light or dark theme but since we cache the result, if you switch theme whilst JDK is running it won't help - but we would have a bunch of work to do to support that.

It does not cached it is a mutable SystemColor which is updated on the color theme switch, it works in a similar way as text selection color which might be configured in the macOS settings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Fri Dec 18 21:45:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 21:45:58 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
 <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
 <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>
Message-ID: <odsYEKbosxjshVThQTuWLZFkc76emYTk-wlCXBBF5hc=.29bdbb13-d481-4f3a-8813-8b7e0f393ee0@github.com>

On Fri, 18 Dec 2020 07:49:42 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 806:
>> 
>>> 804: 
>>> 805: 
>>> 806:             "PopupMenu.consumeEventOnClose", Boolean.FALSE,
>> 
>> This property was added to support some kind of "native" behavior.
>> The code from the BasicPopupMenuUI.java:
>> 
>>                     // Ask UIManager about should we consume event that closes
>>                     // popup. This made to match native apps behaviour.
>>                     boolean consumeEvent =
>>                         UIManager.getBoolean("PopupMenu.consumeEventOnClose");
>>                     // Consume the event so that normal processing stops.
>>                     if(consumeEvent && !(src instanceof MenuElement)) {
>>                         me.consume();
>>                     }
>> So after this fix, the mouse event that causes the popup to close will be not be dispatched to the next component?
>
> Before the fix the mouse event that cause the popup to close  was consumed here as the "PopupMenu.consumeEventOnClose" was true.
> 
> After the fix the mouse event that cause the popup to close will not be consumed here as  "PopupMenu.consumeEventOnClose" is set to false in the fix for Windows, GTK, Nimbus and Motif LAF.

And does it match the native behavior? I mean different values of "consumeEventOnClose" weren't a bug. It was intentionally set to the appropriate value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From prr at openjdk.java.net  Fri Dec 18 21:50:58 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Dec 2020 21:50:58 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
Message-ID: <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>

On Fri, 18 Dec 2020 21:38:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>It does not cached it is a mutable SystemColor which is updated on the color theme switch,
> it works in a similar way as text selection color which might be configured in the macOS settings.

Looked in the code as if it was cached by us. But if not even better, right ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Fri Dec 18 22:17:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 22:17:58 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
Message-ID: <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJLpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>

On Fri, 18 Dec 2020 21:48:04 GMT, Phil Race <prr at openjdk.org> wrote:

> > It does not cached it is a mutable SystemColor which is updated on the color theme switch,
> > it works in a similar way as text selection color which might be configured in the macOS settings.
> 
> Looked in the code as if it was cached by us. But if not even better, right ?

This is the place where the problem is sitting, we still do not know how to get the correct color from the cocoa library in the native code. Do not know Prasanta tried to get the font color from the tab-pane stub in the native code or not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From prr at openjdk.java.net  Fri Dec 18 22:25:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Dec 2020 22:25:55 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJLpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
 <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJ
 LpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
Message-ID: <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>

On Fri, 18 Dec 2020 22:14:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>>It does not cached it is a mutable SystemColor which is updated on the color theme switch,
>>> it works in a similar way as text selection color which might be configured in the macOS settings.
>> 
>> Looked in the code as if it was cached by us. But if not even better, right ?
>
>> > It does not cached it is a mutable SystemColor which is updated on the color theme switch,
>> > it works in a similar way as text selection color which might be configured in the macOS settings.
>> 
>> Looked in the code as if it was cached by us. But if not even better, right ?
> 
> This is the place where the problem is sitting, we still do not know how to get the correct color from the cocoa library in the native code. Do not know Prasanta tried to get the font color from the tab-pane stub in the native code or not.

So why would this API return the wrong colour ?
Sounds like we need to re-cap the alternatives and the pros and cons along with some explanation
And do it before opening the 16 PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Fri Dec 18 22:43:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 22:43:57 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
 <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJ
 LpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
 <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>
Message-ID: <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>

On Fri, 18 Dec 2020 22:23:24 GMT, Phil Race <prr at openjdk.org> wrote:

> So why would this API return the wrong colour ?

That method used in the last version returns the color which is not the color of the tabpane. It is a similar color in some cases, but not always.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From serb at openjdk.java.net  Fri Dec 18 22:59:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 18 Dec 2020 22:59:57 GMT
Subject: <Swing Dev> RFR: 8258554:
 javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F
In-Reply-To: <k2A81LKPOGz3k51owEubftBvIqbAVQoPxBs8QW6Db8s=.87d79f02-2b1f-4762-b198-be434b99ccb6@github.com>
References: <k2A81LKPOGz3k51owEubftBvIqbAVQoPxBs8QW6Db8s=.87d79f02-2b1f-4762-b198-be434b99ccb6@github.com>
Message-ID: <nCupjQOMBgBdW2Ugr4aPUXQ_Y_o2gvXsBdRsLrznDgc=.3e6718c2-1746-4706-8df5-a7d1c0264013@github.com>

On Thu, 17 Dec 2020 03:56:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test tests whether creation of Renderers and Editors are delayed but in nimbus and subseqeuently in GTK L&F the renderers are created in installDefaults() [1] itself so it fails in GTKL&F.
> As nimbus is already skipped in the test, it is modified to skip GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
> Mach5 job running for several iterations for all platform is ok. Link in JBS.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java#L118

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1813

From javalists at cbfiddle.com  Fri Dec 18 23:26:21 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 18 Dec 2020 15:26:21 -0800
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
 <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJ
 LpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
 <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>
 <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>
Message-ID: <CD575CAF-025F-4221-955D-175DAD30C735@cbfiddle.com>

Just to be clear, there is no Apple API whose purpose is to reveal the color that AppKit uses to paint the text in a tab.
Any color choice you make, literal or symbolic, will either be wrong now or sometime in the future, or both.

Trying to deduce the color by analyzing an actual native view might work, but it is not guaranteed to work forever.
Apple?s commitment to faithful rendering of views into images has been decreasing over the years, I?m sorry to say.

  Alan


> On Dec 18, 2020, at 2:43 PM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> On Fri, 18 Dec 2020 22:23:24 GMT, Phil Race <prr at openjdk.org> wrote:
> 
>> So why would this API return the wrong colour ?
> 
> That method used in the last version returns the color which is not the color of the tabpane. It is a similar color in some cases, but not always.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1182
> 


From prr at openjdk.java.net  Fri Dec 18 23:38:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Dec 2020 23:38:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
 <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJ
 LpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
 <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>
 <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>
Message-ID: <V6R_wFRrmnStVVKCOhCb8VJFRstQ-zVMxydezSwB38o=.d4718707-8bc5-4ab2-9154-d3914bd4c035@github.com>

On Fri, 18 Dec 2020 22:41:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So why would this API return the wrong colour ?
>> Sounds like we need to re-cap the alternatives and the pros and cons along with some explanation
>> And do it before opening the 16 PR.
>
>> So why would this API return the wrong colour ?
> 
> That method used in the last version returns the color which is not the color of the tabpane. It is a similar color in some cases, but not always.

So I think we need to hard code the most accurate colour we can and yet somehow take into account dark mode to the same extent we are doing with other components.
I can imagine a clever scheme which tries to derive something that is at least a reasonable contrast - we've done
with GTK3 but at least let's get a fix for what the problem is today.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From psadhukhan at openjdk.java.net  Sat Dec 19 11:58:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 19 Dec 2020 11:58:56 GMT
Subject: <Swing Dev> RFR: 8251377: [macos11] JTabbedPane selected tab
 text is barely legible [v4]
In-Reply-To: <V6R_wFRrmnStVVKCOhCb8VJFRstQ-zVMxydezSwB38o=.d4718707-8bc5-4ab2-9154-d3914bd4c035@github.com>
References: <AHTT41f_zyFzfbz84uceHPocG1Uo7ybh_7CUVQ-n1UU=.997b51b3-2d36-40c7-954b-0a7950c03825@github.com>
 <uga0pLIn0PLnHu3mNMmVFk7Fkf8h1WY6lc0CNHMUlKY=.d6c779c5-8d0d-4263-a29b-f1232b780992@github.com>
 <8Y4t84SMwSPwQsPAuhgAkO1yD2PeJrs99_usj0aDFxA=.8326725d-0fb3-4351-a109-3c93f20c697d@github.com>
 <EX2vRbEYiafTpRwOPDRqLHLCSGVy_Of6KjktQnamLCE=.fe51619c-8929-4da2-a079-ba7d95de0d7a@github.com>
 <f3tmzVG-QjFfUagd6rg9040kWxj9cnqoBZzYerrFN3E=.035300ab-8ff0-452d-97b9-23a57a28a0d3@github.com>
 <Imfu9EylpdwlvDI-7rSQ2k4s_20rTVY1Pzast5np3vY=.74c6230f-88e1-49d8-b96c-95872a90dec0@github.com>
 <4pE6FQOupsLfyktFrOcUnFubPKgZUwws-Szo-bseTr8=.0bfc1665-ea0d-44f5-aa27-3d684839752d@github.com>
 <HQa0ox1ElScLLUekaCIcG_U3c0hBzJZuOxgPixVGyLQ=.afd3e0eb-726b-42dc-968f-8230fd5a4e14@github.com>
 <DG6DQcuMaZofhVnw72XLtxZfsCOsNwp3eggH_Y1fgIA=.3f750952-f2bc-4c79-965a-28da8af503d5@github.com>
 <phXWeE6xF8lbW225Ip1NK3I80ROxpuhU3l3qxIfCclY=.1f9387c8-4d40-48d5-a10e-ec3b82ebca36@github.com>
 <u3I6gx1sNdD1rm18xSjog9YWs5MCBdAEypJ
 LpKhevUM=.623cbac8-0d50-4be5-95a7-137a87f0c78c@github.com>
 <xM1QcWo56nUSMKbqthFPC5_B-2P4Ofg3ioMmtEboF_Q=.fb3b6560-4d43-45ec-83d0-33ffe28eb271@github.com>
 <PczHNzB0HGrAR1NAw2Su1vwhyEY_Fg1FqQkWCDuhWwI=.3030c212-9f66-4884-9f76-97cd46a7077b@github.com>
 <V6R_wFRrmnStVVKCOhCb8VJFRstQ-zVMxydezSwB38o=.d4718707-8bc5-4ab2-9154-d3914bd4c035@github.com>
Message-ID: <Cys4m8Bpnt1CoXqpoGJbPzvv7Mg9U4hWdXTCGdJhFLU=.62ce8494-5c6f-4f28-8296-cd759b84c722@github.com>

On Fri, 18 Dec 2020 23:36:27 GMT, Phil Race <prr at openjdk.org> wrote:

>>> So why would this API return the wrong colour ?
>> 
>> That method used in the last version returns the color which is not the color of the tabpane. It is a similar color in some cases, but not always.
>
> So I think we need to hard code the most accurate colour we can and yet somehow take into account dark mode to the same extent we are doing with other components.
> I can imagine a clever scheme which tries to derive something that is at least a reasonable contrast - we've done
> with GTK3 but at least let's get a fix for what the problem is today.

I have tested the 1st version (lightGray) in both light and dark theme (along with -Dapple.awt.application.appearance=system) and it is legible in both cases. So, I guess, till we have the reply from Apple, we can consider this fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1182

From psadhukhan at openjdk.java.net  Sat Dec 19 12:02:55 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 19 Dec 2020 12:02:55 GMT
Subject: <Swing Dev> Integrated: 8258554:
 javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F
In-Reply-To: <k2A81LKPOGz3k51owEubftBvIqbAVQoPxBs8QW6Db8s=.87d79f02-2b1f-4762-b198-be434b99ccb6@github.com>
References: <k2A81LKPOGz3k51owEubftBvIqbAVQoPxBs8QW6Db8s=.87d79f02-2b1f-4762-b198-be434b99ccb6@github.com>
Message-ID: <8dvxVkmSCfm4U5Lz07SgXnGzAvr5NELJLLHaIzclZfc=.ae876b49-2707-4e4a-bcd8-1030a54acb54@github.com>

On Thu, 17 Dec 2020 03:56:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test tests whether creation of Renderers and Editors are delayed but in nimbus and subseqeuently in GTK L&F the renderers are created in installDefaults() [1] itself so it fails in GTKL&F.
> As nimbus is already skipped in the test, it is modified to skip GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
> Mach5 job running for several iterations for all platform is ok. Link in JBS.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java#L118

This pull request has now been integrated.

Changeset: c7c53d01
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c7c53d01
Stats:     27 lines in 2 files changed: 15 ins; 2 del; 10 mod

8258554: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1813

From serb at openjdk.java.net  Sat Dec 19 22:16:56 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 19 Dec 2020 22:16:56 GMT
Subject: <Swing Dev> RFR: 8258006: Replaces while cycles with iterator
 with enhanced for in java.desktop [v2]
In-Reply-To: <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
 <wu7Gj80w4-UAjZxDSWrZqdqh9xTiKA7ae6brNxh3kBY=.9caced84-d905-42ea-8a44-1dabc8ef48c1@github.com>
Message-ID: <sbItCkKSBO4j8XuTKeyocNgRVNEx7cy95GfXZzkDfxs=.ae2b1720-d83a-4486-b480-b79785334eb0@github.com>

On Tue, 15 Dec 2020 15:24:03 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> There are few places in code where manual `while` loop is used with `Iterator` to iterate over `Collection`.
>> Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
>> It doesn't have any performance impact: java compiler generates similar code when compiling _enhanced-for_ cycle.
>> 
>> See similar cleanup in C++ code - #1707
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8258006: Replace 'while' cycles with iterator with enhanced 'for' in java.desktop

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From github.com+741251+turbanoff at openjdk.java.net  Sat Dec 19 22:22:56 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 19 Dec 2020 22:22:56 GMT
Subject: <Swing Dev> Integrated: 8258006: Replaces while cycles with
 iterator with enhanced for in java.desktop
In-Reply-To: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
References: <-qhgBaIcGzqUX1awyRI4iMC4ALv906xfvaSnVH7ObrU=.0369c185-5ddc-416d-ad56-301c3b692a23@github.com>
Message-ID: <uSJQqN9o0mF2ijG6OQRlBnejqVAMkwHGJcu26ZIiHDQ=.f4b7d9a5-a770-49bd-b8e3-5f219a21e4ff@github.com>

On Wed, 2 Dec 2020 19:23:28 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are few places in code where manual `while` loop is used with `Iterator` to iterate over `Collection`.
> Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone.
> It doesn't have any performance impact: java compiler generates similar code when compiling _enhanced-for_ cycle.
> 
> See similar cleanup in C++ code - #1707

This pull request has now been integrated.

Changeset: 580af490
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/580af490
Stats:     167 lines in 25 files changed: 0 ins; 99 del; 68 mod

8258006: Replaces while cycles with iterator with enhanced for in java.desktop

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1574

From prr at openjdk.java.net  Sun Dec 20 01:44:09 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 01:44:09 GMT
Subject: <Swing Dev> RFR: 8257809: JNI warnings from Toolkit JPEG image
 decoding
Message-ID: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>

The fix is to reverse the order of acquisition to get dst before src so that the call to GetArrayLength() comes first.
This also necessitates moving the RELEASE_ARRAYS() call on an error condition to the new "2nd" block.

The new regression test passes on all platforms and all the other headless tests passed too.
So do the automated headful tests.

-------------

Commit messages:
 - 8257809: JNI warnings from Toolkit JPEG image decoding
 - 8257809: JNI warnings from Toolkit JPEG image decoding

Changes: https://git.openjdk.java.net/jdk/pull/1850/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1850&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257809
  Stats: 126 lines in 4 files changed: 116 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1850.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1850/head:pull/1850

PR: https://git.openjdk.java.net/jdk/pull/1850

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:10:02 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:10:02 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
Message-ID: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>

8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

-------------

Commit messages:
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

Changes: https://git.openjdk.java.net/jdk/pull/1853/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8080272
  Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:46:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:46:10 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v2]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <hY6bq5j7bf8POwY5aKS87ncspu7iRgBq-8N8PZsW6Os=.e4ecc2ff-a299-4221-92be-6f98756c933e@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in JrtPath. They compiled with java 8 language level

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From alanb at openjdk.java.net  Sun Dec 20 19:45:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:45:54 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.

We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.

One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:09:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:09:12 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v3]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oNRktI1p1Z3VLqIBLK6yPqk-mDMFmh8EzMrRuHmtp8w=.cdd1f3fe-c7ba-4e83-8220-da2e2582004f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in ASM
  use Files.copy in sjavac

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01-02

  Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:15:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:15:09 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v4]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <F5_oGJSwGgKTiBxBuzIa3DietHA6DAukNrG1tKXMwzQ=.89920e48-6c93-4ea9-b383-63dc9ba58fa9@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in MLet too

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:22:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:22:10 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v5]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <vAvbxQL52sRM-zF5IuAEfbLXaj-8xfux8XNvlDyQTno=.f1389529-1b8c-4d5a-a335-bea8d182586f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in Win32PrintJob too

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03-04

  Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:25:52 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:25:52 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
Message-ID: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>

On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From prr at openjdk.java.net  Sun Dec 20 20:36:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 20:36:56 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
Message-ID: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>

On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.
>> 
>> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.
>> 
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
> 
> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

So these changes are all over the place which means no one person knows how to test all of it.
Have you run the sound, swing tests, and the  printing tests on unix and windows ?
For printing for sure you'll need to do some manual testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From serb at openjdk.java.net  Sun Dec 20 22:50:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 20 Dec 2020 22:50:55 GMT
Subject: <Swing Dev> RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
Message-ID: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race <prr at openjdk.org> wrote:

>>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>> 
>> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.
>
> So these changes are all over the place which means no one person knows how to test all of it.
> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
> For printing for sure you'll need to do some manual testing.

I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From jwilhelm at openjdk.java.net  Mon Dec 21 09:14:13 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 21 Dec 2020 09:14:13 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
In-Reply-To: <fOSLTd2YbDw4YmfxNl8K1AxPTOHMdt2Dj5eLmRLomyk=.95727f9e-a051-4a82-900f-de79202c61aa@github.com>
References: <fOSLTd2YbDw4YmfxNl8K1AxPTOHMdt2Dj5eLmRLomyk=.95727f9e-a051-4a82-900f-de79202c61aa@github.com>
Message-ID: <IQLHzfcTQzSfHuuC7bBMAFUa68yFDXDB1SOri7leFBs=.27787a7c-5132-47e5-8919-3e7dcc3d1886@github.com>

On Mon, 21 Dec 2020 09:05:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: d2343880
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2343880
Stats:     1822 lines in 76 files changed: 1281 ins; 263 del; 278 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/1857

From jwilhelm at openjdk.java.net  Mon Dec 21 09:14:12 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 21 Dec 2020 09:14:12 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
Message-ID: <fOSLTd2YbDw4YmfxNl8K1AxPTOHMdt2Dj5eLmRLomyk=.95727f9e-a051-4a82-900f-de79202c61aa@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8258007: Add instrumentation to NativeLibraryTest
 - 8258002: Update "type" terminology in generated docs
 - 8223607: --override-methods=summary ignores some signature changes
 - 8258687: Build broken on Windows after fix for JDK-8258134
 - 8256693: getAnnotatedReceiverType parameterizes types too eagerly
 - 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack
 - 8258134: assert(size == calc_size) failed: incorrect size calculation on x86_32 with AVX512 machines
 - 8257974: Regression 21% in DaCapo-lusearch-large after JDK-8236926
 - 8258373: Update the text handling in the JPasswordField
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d4c7db50...67de4667

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1857&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1857&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1857/files
  Stats: 1822 lines in 76 files changed: 1281 ins; 263 del; 278 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1857.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1857/head:pull/1857

PR: https://git.openjdk.java.net/jdk/pull/1857

From trebari at openjdk.java.net  Mon Dec 21 12:20:55 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 21 Dec 2020 12:20:55 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <odsYEKbosxjshVThQTuWLZFkc76emYTk-wlCXBBF5hc=.29bdbb13-d481-4f3a-8813-8b7e0f393ee0@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
 <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
 <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>
 <odsYEKbosxjshVThQTuWLZFkc76emYTk-wlCXBBF5hc=.29bdbb13-d481-4f3a-8813-8b7e0f393ee0@github.com>
Message-ID: <FH5R07msEXBJgDdW5U1hXrg1Iy34cRDln9rXxUGZgdw=.15e9bd14-bf6f-45bc-8d35-c053e473ee7c@github.com>

On Fri, 18 Dec 2020 21:43:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Before the fix the mouse event that cause the popup to close  was consumed here as the "PopupMenu.consumeEventOnClose" was true.
>> 
>> After the fix the mouse event that cause the popup to close will not be consumed here as  "PopupMenu.consumeEventOnClose" is set to false in the fix for Windows, GTK, Nimbus and Motif LAF.
>
> And does it match the native behavior? I mean different values of "consumeEventOnClose" weren't a bug. It was intentionally set to the appropriate value.

yeah , i have checked in windows and ubuntu native apps and it is matching native behaviour.
The issue is seen in Motif, Nimbus, GTK and windows which sets consumeEventOnClose to true.
It is not seen in Metal And Aqua which doesn't set this variable and the value from BasicLookAndFeel.java is used which is false.

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 22 19:45:05 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 22 Dec 2020 19:45:05 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value previously
 dereferenced in java.desktop
Message-ID: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>

I checked JDK16 repository in SpotBugs 4.2.0
![???????????](https://user-images.githubusercontent.com/741251/102926543-405c9000-44a6-11eb-9772-bf81a22ec78a.png)
I fixed only places in java.desktop module.
I didn't fixed places, where dereferencing is done inside method.

-------------

Commit messages:
 - 8231041: Spotbugs: Null check of value previously dereferenced in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/1869/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1869&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231041
  Stats: 69 lines in 13 files changed: 13 ins; 36 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1869.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1869/head:pull/1869

PR: https://git.openjdk.java.net/jdk/pull/1869

From prr at openjdk.java.net  Tue Dec 22 20:20:57 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 22 Dec 2020 20:20:57 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop
In-Reply-To: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
Message-ID: <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>

On Tue, 22 Dec 2020 19:39:57 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I checked JDK16 repository in SpotBugs 4.2.0
> ![???????????](https://user-images.githubusercontent.com/741251/102926543-405c9000-44a6-11eb-9772-bf81a22ec78a.png)
> I fixed only places in java.desktop module.
> I didn't fixed places, where dereferencing is done inside method.

Did it occur that maybe the previous de-reference without a null check is the real problem ?
The proposed Raster change actually needs to be addressed as discussed inhttps://bugs.openjdk.java.net/browse/JDK-8255800 and so should not be part of this proposed change. DataBufferUShort may be the same.

But *all* of them need to be re-examined rather than just blindly updating them as some tool suggests.

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1869

From serb at openjdk.java.net  Tue Dec 22 23:00:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Dec 2020 23:00:55 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop
In-Reply-To: <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
 <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
Message-ID: <CPenN-0zTnmo_NWdOpQj9ZRD9TIuedf2XZVlBTQxUSo=.da820577-7525-4555-bb6c-6a99106b2bb5@github.com>

On Tue, 22 Dec 2020 20:17:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> I checked JDK16 repository in SpotBugs 4.2.0
>> ![???????????](https://user-images.githubusercontent.com/741251/102926543-405c9000-44a6-11eb-9772-bf81a22ec78a.png)
>> I fixed only places in java.desktop module.
>> I didn't fixed places, where dereferencing is done inside method.
>
> Did it occur that maybe the previous de-reference without a null check is the real problem ?
> The proposed Raster change actually needs to be addressed as discussed inhttps://bugs.openjdk.java.net/browse/JDK-8255800 and so should not be part of this proposed change. DataBufferUShort may be the same.
> 
> But *all* of them need to be re-examined rather than just blindly updating them as some tool suggests.

I had a similar fix in past, but the problem here is that most of these exceptions are not specified, or specified differently than actually works. So I postponed the fix since the spec clarification is required. I suggest postponing this PR until then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1869

From psadhukhan at openjdk.java.net  Wed Dec 23 07:46:59 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 23 Dec 2020 07:46:59 GMT
Subject: <Swing Dev> RFR: 8258557: Deproblemlist fixed problemlisted test
In-Reply-To: <M4wojAvMGiqgDVxHlKayh2Mb-_tCWG3Nh-kc_xwyKjo=.78a1b31d-a7de-437e-bc42-5b16ec8f9451@github.com>
References: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
 <M4wojAvMGiqgDVxHlKayh2Mb-_tCWG3Nh-kc_xwyKjo=.78a1b31d-a7de-437e-bc42-5b16ec8f9451@github.com>
Message-ID: <-JG0NPFHyWbGN9cVy1KFkK6fgQQY4NFrgrenQatGrc8=.0cc60000-98e8-4201-a1ef-fa3019a1741a@github.com>

On Thu, 17 Dec 2020 07:57:45 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in nightly mach5 testing but was later fixed in JDK-6847157 but this test was not removed from ProblemList. 
>> We can remove this test from problemlist now.
>> mach5 job running for several iteration on all platforms is ok. Link in JBS.
>
> Marked as reviewed by trebari (Committer).

Any "R"eviewer please before the holidays?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1814

From psadhukhan at openjdk.java.net  Wed Dec 23 10:45:09 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 23 Dec 2020 10:45:09 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane selected
 tab text is barely legible
Message-ID: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>

Please review a fix for jdk16.
On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
so the proposed fix is to use this system color for BigSur. 
For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.

-------------

Commit messages:
 - 8251377: [macos11] JTabbedPane selected tab text is barely legible

Changes: https://git.openjdk.java.net/jdk16/pull/65/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=65&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251377
  Stats: 10 lines in 4 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/65/head:pull/65

PR: https://git.openjdk.java.net/jdk16/pull/65

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 23 11:21:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Dec 2020 11:21:09 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop [v2]
In-Reply-To: <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
 <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
Message-ID: <Iz066SA5Yhyho221PIKjV1Q982Ir5MxDAZ45vcCS8NM=.ac6a80fc-68a9-49ba-ad01-4fb4420ea2e7@github.com>

On Tue, 22 Dec 2020 20:17:59 GMT, Phil Race <prr at openjdk.org> wrote:

>But all of them need to be re-examined rather than just blindly updating them as some tool suggests.

I agree. I actually did careful investigation of all my changes. As you can see SpotBugs reported much more than I actually propose to fix. I reverted most controversal changes from this PR. I hoped that reviewers could help me to clarify controversal changes and start discussion about unclear places.
I will go through my changes and my thoughts about it:
### 1. `DataBufferUShort` explicit NPE in constructors
 
![???????????](https://user-images.githubusercontent.com/741251/102990509-8823fb80-4528-11eb-908f-42b90d3ae844.png)

Behaviour of `DataBufferUShort` constructors in case if `dataArray == null` is the same as in original code, as in the changed code, as in _hypothetical code_ where we removed dereference before `null` check. This behavior - is NullPointerException
This code is in original form, as it was uploaded into open source under https://bugs.openjdk.java.net/browse/JDK-6662775 So there is no chance that there are consumers of this code which expect _NPE with this specific message_ `dataArray is null`.
  
### 2. Dereference of parameter `JComponent c` in method `getPreferredSize` in classes `BasicToolTipUI`, `SynthToolTipUI`
![???????????](https://user-images.githubusercontent.com/741251/102990550-9d008f00-4528-11eb-85c8-2eb5034e1549.png)

 This dereference was there from original upload of OpenJDK.
 While NPE is not specified in javadoc of method `javax.swing.plaf.ComponentUI#getPreferredSize`, most of implementations do not check nullness of passed parameter. As I know it matches with general Swing behaviour about null tolerance.
 
### 3. Dereference of field `stack` in `javax.swing.text.html.parser.Parser#ignoreElement`
![???????????](https://user-images.githubusercontent.com/741251/102990568-a5f16080-4528-11eb-84cf-faa47160f1a2.png)

 This dereference was there from original upload of OpenJDK.
 Method `ignoreElement` is called only from method `legalElementContext` which has `null` check at the start:
        // Deal with the empty stack
        if (stack == null) {
            // System.out.println("-- stack is empty");
            if (elem != dtd.html) {
                // System.out.println("-- pushing html");
                startTag(makeTag(dtd.html, true));
                return legalElementContext(elem);
            }
            return true;
        }

### 4. Null checks of paragraph `javax.swing.text.Element` after `for` cycle in 3 methods: `javax.swing.text.html.AccessibleHTML.TextElementInfo.TextAccessibleContext#getParagraphElement`, `javax.swing.text.DefaultStyledDocument#getParagraphElement`, `javax.swing.text.JTextComponent.AccessibleJTextComponent#getParagraphElement`
![???????????](https://user-images.githubusercontent.com/741251/102990588-aee23200-4528-11eb-93e3-ada52eafc1a5.png)

This methods have the same cycle before `null` check
                Element para;
                for (para = model.getDefaultRootElement(); ! para.isLeaf(); ) {
                    int pos = para.getElementIndex(index);
                    para = para.getElement(pos);
                }
SpotBugs reported redundant `null` check of `para`, because dereference is alredy happened in `for` cycle condition: `! para.isLeaf()`
This dereference and `null` check were there from original upload of OpenJDK.
`para` is a result of `Element.getElement` method call. Since parameter `pos` is result of previous call to `Element.getElementIndex` - and this method, according to its javadoc, must return valid child element index for non-leafs.
It means `Element.getElement` shouldn't return `null` values according to contracts. So even if some custom implementation returns `null` - it violates `Element` contract and NPE is expected.
OpenJDK implementations of `Element`

### 5. Null check of in method `javax.swing.text.html.StyleSheet#getRule(HTML.Tag, Element)`
![???????????](https://user-images.githubusercontent.com/741251/102990622-bdc8e480-4528-11eb-9f2d-a89940666e75.png)

Variable `AttributeSet attr` is result of method `javax.swing.text.Element#getAttributes`. It is dereferenced and then `null` checked.
This dereference was there from original upload of OpenJDK.
Javadoc of method `javax.swing.text.Element#getAttributes` doesn't specify that it can return `null`.
OpenJDK implementations never return `null`. Actually there is only one implementation `javax.swing.text.AbstractDocument.AbstractElement#getAttributes`:
        public AttributeSet getAttributes() {
            return this;
        }

### 6. `Component c = javax.swing.MenuElement.getComponent()` is `null`-checked in `javax.swing.JMenuBar#processBindingForKeyStrokeRecursive`
![???????????](https://user-images.githubusercontent.com/741251/102991095-9888a600-4529-11eb-9f84-3112a76194ee.png)

This dereference was there from original upload of OpenJDK.
Variable `c` is checked before another condition `c instanceof JComponent` in the same `if` statement. `instanceof JComponent` do not return `true` for `null` values. So it's safe to remove.
Javadoc of method `javax.swing.MenuElement.getComponent()` doesn't specify `null` as possible return value. All implementations inside OpenJDK return non-null value: `this`

### 7. Null check of `File fontFile` inside `sun.font.FileFont.CreatedFontFileDisposerRecord#dispose`
![???????????](https://user-images.githubusercontent.com/741251/102990639-c7524c80-4528-11eb-8a10-a59c81bff9bb.png)

This field of `sun.font.FileFont.CreatedFontFileDisposerRecord` class initialized in constructor, which is called in one place `sun.font.FileFont#setFileToRemove`. `File file` is passed there from the caller method `sun.font.SunFontManager#createFont2D`.
At the start method `sun.font.SunFontManager#createFont2D` there is dererefence:
        String fontFilePath = fontFile.getPath();
This internal method `sun.font.FontManager#createFont2D` never accepted `null` values since its introduction.
PS. I tracked where original `fontFile` value could came from and found 2 public methods:
a. `java.awt.Font#createFont(int, java.io.File)` - it does specify `NullPointerException` in it's javadoc
b. `java.awt.Font#createFonts(java.io.File)` - it does *NOT* specify `NullPointerException` in it's javadoc. Perphaps it should be specified to be consistent.
Anyway this fact is not directly related to removing redundant `null` check in `sun.font.FileFont.CreatedFontFileDisposerRecord#dispose`. Variable is dereferenced multiple times in code flow, before calling this method.

### 8. Null check of `bufferedImage` in `sun.print.PathGraphics#hasTransparentPixels`
![???????????](https://user-images.githubusercontent.com/741251/102991049-7d1d9b00-4529-11eb-8af1-30cc0d2f996e.png)

This dereference was there from original upload of OpenJDK.
Variable is dereferenced at the start of method. This method is called from 2 places: `sun.print.PSPathGraphics#drawImageToPlatform` and in `sun.awt.windows.WPathGraphics#drawImageToPlatform`. Both of this methods handle `null` values by themselves
        BufferedImage img = getBufferedImage(image);
        if (img == null) {
            return true;
        }

-------------

PR: https://git.openjdk.java.net/jdk/pull/1869

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 23 11:21:08 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Dec 2020 11:21:08 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop [v2]
In-Reply-To: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
Message-ID: <63yleuRLvsU0xeRhnNEwUWj1AwnO8KBZNGdYUH-hmuM=.11819d05-a580-4a87-b2fc-ce2fdebdbfd8@github.com>

> I checked JDK16 repository in SpotBugs 4.2.0
> ![???????????](https://user-images.githubusercontent.com/741251/102926543-405c9000-44a6-11eb-9772-bf81a22ec78a.png)
> I fixed only places in java.desktop module.
> I didn't fixed places, where dereferencing is done inside method.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8231041: Spotbugs: Null check of value previously dereferenced in java.desktop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1869/files
  - new: https://git.openjdk.java.net/jdk/pull/1869/files/ad0b4858..66e82b93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1869&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1869&range=00-01

  Stats: 8 lines in 3 files changed: 4 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1869.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1869/head:pull/1869

PR: https://git.openjdk.java.net/jdk/pull/1869

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 23 11:21:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Dec 2020 11:21:09 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop [v2]
In-Reply-To: <CPenN-0zTnmo_NWdOpQj9ZRD9TIuedf2XZVlBTQxUSo=.da820577-7525-4555-bb6c-6a99106b2bb5@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
 <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
 <CPenN-0zTnmo_NWdOpQj9ZRD9TIuedf2XZVlBTQxUSo=.da820577-7525-4555-bb6c-6a99106b2bb5@github.com>
Message-ID: <Uh4vyzlCinj-BQpmaHTr38-ySXlIT_CQI-VPKJKT17Q=.bdfb2485-f4ab-4053-915e-db0f25a70a0f@github.com>

On Tue, 22 Dec 2020 22:58:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>So I postponed the fix since the spec clarification is required. I suggest postponing this PR until then.

Do you know if this clarification is in progress now? As I see from @prrace comment there is https://bugs.openjdk.java.net/browse/JDK-8255800 Do you know any more similar issues?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1869

From github.com+70650887+skodanda at openjdk.java.net  Wed Dec 23 11:56:03 2020
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Wed, 23 Dec 2020 11:56:03 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based test
 open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular
 java test
Message-ID: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>

Hi All, Could you please review this fix for JDK16?

Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.

Fix: Rewrite the above applet based test to a regular java test.

Best Regards,
K Suman Rajkumaar

-------------

Commit messages:
 - Rewritten applet based test as a regular java test app.

Changes: https://git.openjdk.java.net/jdk/pull/1878/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1878&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258884
  Stats: 94 lines in 1 file changed: 70 ins; 10 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1878/head:pull/1878

PR: https://git.openjdk.java.net/jdk/pull/1878

From serb at openjdk.java.net  Wed Dec 23 12:46:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Dec 2020 12:46:58 GMT
Subject: <Swing Dev> RFR: 8258557: Deproblemlist fixed problemlisted test
In-Reply-To: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
References: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
Message-ID: <O5zjtJUm6p9TVZmqxdS87b1Di8UOB-PuTNT3ubi32VI=.75dc109f-3d00-4992-8783-8c7e7a401d9f@github.com>

On Thu, 17 Dec 2020 04:59:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in nightly mach5 testing but was later fixed in JDK-6847157 but this test was not removed from ProblemList. 
> We can remove this test from problemlist now.
> mach5 job running for several iteration on all platforms is ok. Link in JBS.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1814

From turbanoff at gmail.com  Wed Dec 23 12:58:32 2020
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 23 Dec 2020 15:58:32 +0300
Subject: <Swing Dev> Confusing method
 javax.swing.tree.DefaultTreeCellEditor.EditorContainer#EditorContainer()
Message-ID: <CAF+DQ5fFyOpt2aSynnepUjDBR07Cr8tOvdd9i-r8Vox8ybsycQ@mail.gmail.com>

Hello.
I've found a very strange methodin class EditorContainer:
javax.swing.tree.DefaultTreeCellEditor.EditorContainer#EditorContainer()
Method name is the same as class name, but it's not a constructor. I
think it's not a good idea to have such methods. Javadoc and comment
on these method are agree with me :)
Also SpotBugs show warning "Apparent method/constructor confusion" on
this - https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-apparent-method-constructor-confusion-nm-method-constructor-confusion

// This should not be used. It will be removed when new API is
// allowed.
/**
 * Do not use.
 */
public void EditorContainer() {
    setLayout(null);
}


I propose to deprecate this method. Probably for removal.


Andrey Turbanov

From philip.race at oracle.com  Wed Dec 23 16:04:57 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 23 Dec 2020 08:04:57 -0800
Subject: <Swing Dev> Confusing method
 javax.swing.tree.DefaultTreeCellEditor.EditorContainer#EditorContainer()
In-Reply-To: <CAF+DQ5fFyOpt2aSynnepUjDBR07Cr8tOvdd9i-r8Vox8ybsycQ@mail.gmail.com>
References: <CAF+DQ5fFyOpt2aSynnepUjDBR07Cr8tOvdd9i-r8Vox8ybsycQ@mail.gmail.com>
Message-ID: <404c9692-3965-e90a-bf7b-2b3857d706da@oracle.com>

Thanks for raising a discussion first.

This looks like a mistake from over 20 years ago :

https://bugs.openjdk.java.net/browse/JDK-4198051

I do not know why it was not deprecated then (or soon afterwards)
but I think it OK to at least add @Deprecated.
I usually hesitate over for removal especially in really old commonly used
classes until there is a good sense of what the impact would be on lots of
apps for which people may not even have all the source any more (eg they 
used
a 3rd party library).

-phil.

On 12/23/20 4:58 AM, Andrey Turbanov wrote:
> Hello.
> I've found a very strange methodin class EditorContainer:
> javax.swing.tree.DefaultTreeCellEditor.EditorContainer#EditorContainer()
> Method name is the same as class name, but it's not a constructor. I
> think it's not a good idea to have such methods. Javadoc and comment
> on these method are agree with me :)
> Also SpotBugs show warning "Apparent method/constructor confusion" on
> this - https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-apparent-method-constructor-confusion-nm-method-constructor-confusion
>
> // This should not be used. It will be removed when new API is
> // allowed.
> /**
>   * Do not use.
>   */
> public void EditorContainer() {
>      setLayout(null);
> }
>
>
> I propose to deprecate this method. Probably for removal.
>
>
> Andrey Turbanov


From psadhukhan at openjdk.java.net  Wed Dec 23 16:38:56 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 23 Dec 2020 16:38:56 GMT
Subject: <Swing Dev> Integrated: 8258557: Deproblemlist fixed problemlisted
 test
In-Reply-To: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
References: <WwmsBXtPhMC5Qk0wyubWVeNfF_dFhU2hiN-p27HgdIw=.8fa073a8-ff62-4841-b1bf-757abeae446b@github.com>
Message-ID: <sKZyeK1HNyzrCP27cKQfqhfvrC_PvIINvCQNV38Wtg0=.0116e56a-0deb-4f1e-8409-1b6243a37dff@github.com>

On Thu, 17 Dec 2020 04:59:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in nightly mach5 testing but was later fixed in JDK-6847157 but this test was not removed from ProblemList. 
> We can remove this test from problemlist now.
> mach5 job running for several iteration on all platforms is ok. Link in JBS.

This pull request has now been integrated.

Changeset: 91244cc7
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91244cc7
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8258557: Deproblemlist fixed problemlisted test

Reviewed-by: trebari, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1814

From serb at openjdk.java.net  Wed Dec 23 22:08:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Dec 2020 22:08:54 GMT
Subject: <Swing Dev> RFR: 8257809: JNI warnings from Toolkit JPEG image
 decoding
In-Reply-To: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
References: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
Message-ID: <7IU037_RvHNLATTCuyAHp-6OJbi5qZmFof1_sGN921w=.b1d3e51a-e3bb-4029-87df-84ae1b5cbd7a@github.com>

On Sun, 20 Dec 2020 01:37:47 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix is to reverse the order of acquisition to get dst before src so that the call to GetArrayLength() comes first.
> This also necessitates moving the RELEASE_ARRAYS() call on an error condition to the new "2nd" block.
> 
> The new regression test passes on all platforms and all the other headless tests passed too.
> So do the automated headful tests.

Marked as reviewed by serb (Reviewer).

test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh line 50:

> 48:     -cp "${CP}" -Xcheck:jni GetImageJNICheck | grep ReleasePrimitiveArrayCritical > "${CP}"/log.txt
> 49: 
> 50: #if [ $? -ne 0 ]

I always wonder why it is not possible to report such warnings as fatal errors or at least report the exit code as non zero. Probably it is meant to create an enhancement?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1850

From dcubed at openjdk.java.net  Wed Dec 23 22:27:01 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 23 Dec 2020 22:27:01 GMT
Subject: <Swing Dev> RFR: 8258913: ProblemList
 javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
Message-ID: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>

A trivial fix to ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64.

-------------

Commit messages:
 - 8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64

Changes: https://git.openjdk.java.net/jdk/pull/1885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1885&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258913
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1885/head:pull/1885

PR: https://git.openjdk.java.net/jdk/pull/1885

From dcubed at openjdk.java.net  Wed Dec 23 22:27:02 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 23 Dec 2020 22:27:02 GMT
Subject: <Swing Dev> RFR: 8258913: ProblemList
 javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
In-Reply-To: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
References: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
Message-ID: <N0MFHzl5IBWrrTH0wkiqRpXZr_8z4wZSLtBslTfooRk=.e83fd26a-706a-46f3-a079-c336259f1197@github.com>

On Wed, 23 Dec 2020 22:21:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64.

@prrace - please review when you get the chance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1885

From prr at openjdk.java.net  Wed Dec 23 23:21:57 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Dec 2020 23:21:57 GMT
Subject: <Swing Dev> RFR: 8258913: ProblemList
 javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
In-Reply-To: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
References: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
Message-ID: <f_7BeyzjkgxMtf2KD-3JcIpvvPHb0ZrPE_99kQfHIes=.937b7977-837b-429f-b545-8b46013d7125@github.com>

On Wed, 23 Dec 2020 22:21:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1885

From dcubed at openjdk.java.net  Wed Dec 23 23:21:57 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 23 Dec 2020 23:21:57 GMT
Subject: <Swing Dev> RFR: 8258913: ProblemList
 javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
In-Reply-To: <f_7BeyzjkgxMtf2KD-3JcIpvvPHb0ZrPE_99kQfHIes=.937b7977-837b-429f-b545-8b46013d7125@github.com>
References: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
 <f_7BeyzjkgxMtf2KD-3JcIpvvPHb0ZrPE_99kQfHIes=.937b7977-837b-429f-b545-8b46013d7125@github.com>
Message-ID: <4zZteU0cO4OpXoQ8wLGrNOBYFQpoUQYAzP5SOrLHXwM=.55f8ebac-2621-45d5-aac6-040d28333c2f@github.com>

On Wed, 23 Dec 2020 23:17:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64.
>
> Marked as reviewed by prr (Reviewer).

@prrace - Thanks for the fast review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1885

From dcubed at openjdk.java.net  Wed Dec 23 23:21:58 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 23 Dec 2020 23:21:58 GMT
Subject: <Swing Dev> Integrated: 8258913: ProblemList
 javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
In-Reply-To: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
References: <FYFxZ74knI5LHf2UJV8WljhfsbC6yCPYX23MMt7bKeY=.4459e155-706c-4e48-9156-b6ec58175cd7@github.com>
Message-ID: <tUEy8VcB5V8fMlSSsayYW-gkr8EY5OdWosaWrqTVD5g=.92205eb0-7c8b-4176-b425-b09e77b5dfd6@github.com>

On Wed, 23 Dec 2020 22:21:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64.

This pull request has now been integrated.

Changeset: 127582f8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/127582f8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/1885

From serb at openjdk.java.net  Wed Dec 23 23:49:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Dec 2020 23:49:57 GMT
Subject: <Swing Dev> RFR: 8048109: JToggleButton does not fire
 actionPerformed under certain conditions [v4]
In-Reply-To: <FH5R07msEXBJgDdW5U1hXrg1Iy34cRDln9rXxUGZgdw=.15e9bd14-bf6f-45bc-8d35-c053e473ee7c@github.com>
References: <DIug9CQQguKKvbd-CG6NgPp011j7NmEI470DPMIyWPg=.b100692f-a5c6-4dd6-a02b-f85af20eb57c@github.com>
 <PHdzaI5JYc2R_piiDx--o-fBMItTCED3WkmPi20L17s=.d7a423c0-b663-4c9d-9cbe-b7c2c761315b@github.com>
 <ad1ydktaZdQOjoPK23yhnAvJ6U1ZJ6LMztjkBeredmY=.97a6b118-8626-48a1-9005-ac8718f36abf@github.com>
 <-cE9eTaeK1Tb0uVNh4ICINADEJ7ca-22xQBAPcwoyAE=.42736629-8faa-471f-91c2-6d61cf913182@github.com>
 <odsYEKbosxjshVThQTuWLZFkc76emYTk-wlCXBBF5hc=.29bdbb13-d481-4f3a-8813-8b7e0f393ee0@github.com>
 <FH5R07msEXBJgDdW5U1hXrg1Iy34cRDln9rXxUGZgdw=.15e9bd14-bf6f-45bc-8d35-c053e473ee7c@github.com>
Message-ID: <LPGCW0REMlhU-7YxflrUnXlqI0z-sOaHY3n_Ge3pYs4=.27f9da7d-cd4a-474a-a979-81ebec915c26@github.com>

On Mon, 21 Dec 2020 12:18:19 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> And does it match the native behavior? I mean different values of "consumeEventOnClose" weren't a bug. It was intentionally set to the appropriate value.
>
> yeah , i have checked in windows and ubuntu native apps and it is matching native behaviour.
> The issue is seen in Motif, Nimbus, GTK and windows which sets consumeEventOnClose to true.
> It is not seen in Metal And Aqua which doesn't set this variable and the value from BasicLookAndFeel.java is used which is false.

Can you recheck that using the next usecase:
 - Create menu in the frame
 - Add jbutton to the frame exactly in the place where the menu popup is opened
 - Open menu and click some menu item, will the jbutton be clicked?

-------------

PR: https://git.openjdk.java.net/jdk/pull/600

From psadhukhan at openjdk.java.net  Thu Dec 24 07:41:05 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Dec 2020 07:41:05 GMT
Subject: <Swing Dev> RFR: 8258924:
 javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F
Message-ID: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>

This test tests whether SplitPane is opaque or not but in nimbus and subseqeuently in GTK L&F the opaque property is set to false [1]
As nimbus is already handled in the test, it is modified to handle GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
Mach5 job running for several iterations for all platform is ok. Link in JBS.

[1] https://raw.githubusercontent.com/openjdk/jdk/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
      uiComponent opaque="false" type="javax.swing.JSplitPane" name="SplitPane" ui="SplitPaneUI" subregion="false"

-------------

Commit messages:
 - gtk fix

Changes: https://git.openjdk.java.net/jdk/pull/1888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1888&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258924
  Stats: 25 lines in 2 files changed: 15 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1888/head:pull/1888

PR: https://git.openjdk.java.net/jdk/pull/1888

From prr at openjdk.java.net  Thu Dec 24 17:39:00 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Dec 2020 17:39:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible
In-Reply-To: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
Message-ID: <5aOQonMTYI7Al0KBoW8n2bdROzoepWux4JEZppKIr4g=.170bb0dd-1321-481f-a679-3c3acd8aae19@github.com>

On Wed, 23 Dec 2020 10:41:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a fix for jdk16.
> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
> so the proposed fix is to use this system color for BigSur. 
> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 873:

> 871:             "TabbedPane.selectedTabTitlePressedColor", selectedTabTitlePressedColor,
> 872:             "TabbedPane.selectedTabTitleDisabledColor", selectedTabTitleDisabledColor,
> 873:             "TabbedPane.selectedTabTitleNormalColor", System.getProperty("os.version").contains("10.16") ? selectedControlTextColor : selectedTabTitleNormalColor,

That doesn't look very robust. What will happen on the next version of macOS ?

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From javalists at cbfiddle.com  Thu Dec 24 17:53:18 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 24 Dec 2020 09:53:18 -0800
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible
In-Reply-To: <5aOQonMTYI7Al0KBoW8n2bdROzoepWux4JEZppKIr4g=.170bb0dd-1321-481f-a679-3c3acd8aae19@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
 <5aOQonMTYI7Al0KBoW8n2bdROzoepWux4JEZppKIr4g=.170bb0dd-1321-481f-a679-3c3acd8aae19@github.com>
Message-ID: <9E2F7EAB-0B55-471E-BB9B-2003F34CA139@cbfiddle.com>

What alternative are you proposing? I don?t believe there is any option that is guaranteed not to require changing
for some future release of macOS without some new API from Apple, e.g. ?selectedTabTextColor?.



> On Dec 24, 2020, at 9:39 AM, Phil Race <prr at openjdk.java.net> wrote:
> 
> On Wed, 23 Dec 2020 10:41:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:
> 
>> Please review a fix for jdk16.
>> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
>> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
>> so the proposed fix is to use this system color for BigSur. 
>> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.
> 
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 873:
> 
>> 871:             "TabbedPane.selectedTabTitlePressedColor", selectedTabTitlePressedColor,
>> 872:             "TabbedPane.selectedTabTitleDisabledColor", selectedTabTitleDisabledColor,
>> 873:             "TabbedPane.selectedTabTitleNormalColor", System.getProperty("os.version").contains("10.16") ? selectedControlTextColor : selectedTabTitleNormalColor,
> 
> That doesn't look very robust. What will happen on the next version of macOS ?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk16/pull/65
> 


From prr at openjdk.java.net  Thu Dec 24 18:12:00 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Dec 2020 18:12:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible
In-Reply-To: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
Message-ID: <bgEmg7TdvAPo_yiH6tcrHOVGt9KZ2DBjyXn7VO7pToM=.8775b069-041a-4bd1-af6f-4e0c8b4f7fc0@github.com>

On Wed, 23 Dec 2020 10:41:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a fix for jdk16.
> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
> so the proposed fix is to use this system color for BigSur. 
> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.

> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [swing-dev](mailto:swing-dev at openjdk.java.net):_
> 
> What alternative are you proposing? I don?t believe there is any option that is guaranteed not to require changing
> for some future release of macOS without some new API from Apple, e.g. ?selectedTabTextColor?.

Alan,
We contacted Apple and this is their recommendation since there is no way to future-proof it.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From psadhukhan at openjdk.java.net  Thu Dec 24 18:36:12 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Dec 2020 18:36:12 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible [v2]
In-Reply-To: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
Message-ID: <qnrZmmfzuJH7uvmJcHn0ihkLxLTj0eHl_FH8XjZETM4=.d4b8ea6a-11ad-4853-8ed0-d4c893dba650@github.com>

> Please review a fix for jdk16.
> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
> so the proposed fix is to use this system color for BigSur. 
> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Check for BigSur and above

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/65/files
  - new: https://git.openjdk.java.net/jdk16/pull/65/files/504f1bd0..ad3c52b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=65&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=65&range=00-01

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/65/head:pull/65

PR: https://git.openjdk.java.net/jdk16/pull/65

From psadhukhan at openjdk.java.net  Thu Dec 24 18:36:13 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Dec 2020 18:36:13 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible
In-Reply-To: <bgEmg7TdvAPo_yiH6tcrHOVGt9KZ2DBjyXn7VO7pToM=.8775b069-041a-4bd1-af6f-4e0c8b4f7fc0@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
 <bgEmg7TdvAPo_yiH6tcrHOVGt9KZ2DBjyXn7VO7pToM=.8775b069-041a-4bd1-af6f-4e0c8b4f7fc0@github.com>
Message-ID: <ULwfgjYT-q9NiO0LokHk-1ivEZWJxOU8kR7BIIC1dEM=.97cb705c-647f-4994-b5f7-067a255f49c8@github.com>

On Thu, 24 Dec 2020 18:08:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review a fix for jdk16.
>> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
>> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
>> so the proposed fix is to use this system color for BigSur. 
>> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.
>
>> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [swing-dev](mailto:swing-dev at openjdk.java.net):_
>> 
>> What alternative are you proposing? I don?t believe there is any option that is guaranteed not to require changing
>> for some future release of macOS without some new API from Apple, e.g. ?selectedTabTextColor?.
> 
> Alan,
> We contacted Apple and this is their recommendation since there is no way to future-proof it.

Headful jtreg and jck tests have passed.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From psadhukhan at openjdk.java.net  Thu Dec 24 18:36:14 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Dec 2020 18:36:14 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible [v2]
In-Reply-To: <5aOQonMTYI7Al0KBoW8n2bdROzoepWux4JEZppKIr4g=.170bb0dd-1321-481f-a679-3c3acd8aae19@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
 <5aOQonMTYI7Al0KBoW8n2bdROzoepWux4JEZppKIr4g=.170bb0dd-1321-481f-a679-3c3acd8aae19@github.com>
Message-ID: <MTCX7VKtu2q3Qw4giEWh-VlG0ep8iC8QyLDDIOiLnPw=.04c55274-1722-4c8d-84ab-c145d0d8a204@github.com>

On Thu, 24 Dec 2020 17:35:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for BigSur and above
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 873:
> 
>> 871:             "TabbedPane.selectedTabTitlePressedColor", selectedTabTitlePressedColor,
>> 872:             "TabbedPane.selectedTabTitleDisabledColor", selectedTabTitleDisabledColor,
>> 873:             "TabbedPane.selectedTabTitleNormalColor", System.getProperty("os.version").contains("10.16") ? selectedControlTextColor : selectedTabTitleNormalColor,
> 
> That doesn't look very robust. What will happen on the next version of macOS ?

Check for BigSur and above is added

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From prr at openjdk.java.net  Thu Dec 24 18:50:58 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 24 Dec 2020 18:50:58 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible [v2]
In-Reply-To: <qnrZmmfzuJH7uvmJcHn0ihkLxLTj0eHl_FH8XjZETM4=.d4b8ea6a-11ad-4853-8ed0-d4c893dba650@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
 <qnrZmmfzuJH7uvmJcHn0ihkLxLTj0eHl_FH8XjZETM4=.d4b8ea6a-11ad-4853-8ed0-d4c893dba650@github.com>
Message-ID: <cKlu-B2anohV68mnHwszIRE5oF3f5nmR2aKL_lFJu5M=.e8ba251f-a24b-4373-b200-c384dad1746d@github.com>

On Thu, 24 Dec 2020 18:36:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a fix for jdk16.
>> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
>> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
>> so the proposed fix is to use this system color for BigSur. 
>> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for BigSur and above

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From psadhukhan at openjdk.java.net  Thu Dec 24 18:54:00 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Dec 2020 18:54:00 GMT
Subject: <Swing Dev> [jdk16] Integrated: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible
In-Reply-To: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
Message-ID: <zBX0PrRgKRiTfxibYf8kluTvAfpai9PqfgHAsapTBiw=.bb7a2b2a-3c20-454b-afcf-f03f92fdf5aa@github.com>

On Wed, 23 Dec 2020 10:41:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Please review a fix for jdk16.
> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
> so the proposed fix is to use this system color for BigSur. 
> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.

This pull request has now been integrated.

Changeset: 3f67afd3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/3f67afd3
Stats:     15 lines in 5 files changed: 13 ins; 0 del; 2 mod

8251377: [macos11] JTabbedPane selected tab text is barely legible

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From serb at openjdk.java.net  Fri Dec 25 00:23:00 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 25 Dec 2020 00:23:00 GMT
Subject: <Swing Dev> [jdk16] RFR: 8251377: [macos11] JTabbedPane
 selected tab text is barely legible [v2]
In-Reply-To: <qnrZmmfzuJH7uvmJcHn0ihkLxLTj0eHl_FH8XjZETM4=.d4b8ea6a-11ad-4853-8ed0-d4c893dba650@github.com>
References: <wIA15TEGnAYNPgyBuZXKaJh5BT9HQCh9_j_zp4z6KVY=.79878897-4c64-4347-a90f-116bc6916a50@github.com>
 <qnrZmmfzuJH7uvmJcHn0ihkLxLTj0eHl_FH8XjZETM4=.d4b8ea6a-11ad-4853-8ed0-d4c893dba650@github.com>
Message-ID: <Tf2QMUN1UKn4bDzzuhyI2p9ZKT-ot4_TVxnsG93yP_0=.0d0b1435-1f51-40a5-b709-a9c1a84831ec@github.com>

On Thu, 24 Dec 2020 18:36:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a fix for jdk16.
>> On macOS 11 (bigsur), using the Swing Aqua Look and Feel, the text of the selected JTabbedPane tab title text is just a light gray outline of white text on a white background. The macOS 11 design inverted from dark background / light text to light background / dark text, so white text on white background is not legible.
>> Correct system color to use for this scenario, as per Apple, is [NSColor controlTextColor]
>> so the proposed fix is to use this system color for BigSur. 
>> For preBigSur releases, "white" is still used as the above color is for text color but the tabPane background color is still not readable through any Apple API, so [NSColor controlTextColor] which returns black will not be legible on preBigSur releases which has black background.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for BigSur and above

src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 873:

> 871:             "TabbedPane.selectedTabTitlePressedColor", selectedTabTitlePressedColor,
> 872:             "TabbedPane.selectedTabTitleDisabledColor", selectedTabTitleDisabledColor,
> 873:             "TabbedPane.selectedTabTitleNormalColor", JRSUIUtils.isMacOSXBigSurOrAbove() ? selectedControlTextColor : selectedTabTitleNormalColor,

I guess an intention was to use the JRSUIUtils.isBigSurOrAbove field not the JRSUIUtils.isMacOSXBigSurOrAbove() method, otherwise, why did you add it.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/65

From jwilhelm at openjdk.java.net  Tue Dec 29 05:27:58 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 29 Dec 2020 05:27:58 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
Message-ID: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests
 - 8216400: improve handling of IOExceptions in JavaCompiler.close()
 - 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed out
 - Merge
 - 8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
 - 8258856: VM build without C1/C2 fails after JDK-8243205
 - 8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation
 - 8258839: Remove JVM option ExitVMOnVerifyError
 - 8258186: Replace use of JNI_COMMIT mode with mode 0
 - ... and 117 more: https://git.openjdk.java.net/jdk/compare/881bceb9...85accc95

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/1902/files
  Stats: 24075 lines in 702 files changed: 18594 ins; 3271 del; 2210 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1902/head:pull/1902

PR: https://git.openjdk.java.net/jdk/pull/1902

From jwilhelm at openjdk.java.net  Tue Dec 29 05:28:00 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 29 Dec 2020 05:28:00 GMT
Subject: <Swing Dev> Integrated: Merge jdk16
In-Reply-To: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>
References: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>
Message-ID: <xAv2P29NIKMsBoiLLkWS974g55kCcqZoGUM2qO-vhfw=.3b9cb745-a147-4b67-b73b-d0c53860907b@github.com>

On Tue, 29 Dec 2020 05:22:02 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 07c93fab
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07c93fab
Stats:     143 lines in 15 files changed: 84 ins; 43 del; 16 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/1902

From serb at openjdk.java.net  Thu Dec 31 06:34:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 31 Dec 2020 06:34:58 GMT
Subject: <Swing Dev> RFR: 8258924:
 javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F
In-Reply-To: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
References: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
Message-ID: <k8rm7nKLgGbTDtawSfKXeno9co6FwtmYSmWTjIPmNRM=.054f710b-a018-4974-a290-a8c8d7abe3c6@github.com>

On Thu, 24 Dec 2020 07:33:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This test tests whether SplitPane is opaque or not but in nimbus and subseqeuently in GTK L&F the opaque property is set to false [1]
> As nimbus is already handled in the test, it is modified to handle GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
> Mach5 job running for several iterations for all platform is ok. Link in JBS.
> 
> [1] https://raw.githubusercontent.com/openjdk/jdk/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
>       uiComponent opaque="false" type="javax.swing.JSplitPane" name="SplitPane" ui="SplitPaneUI" subregion="false"

test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java line 40:

> 38:                 UIManager.setLookAndFeel(LF.getClassName());
> 39:             } catch (UnsupportedLookAndFeelException ignored) {
> 40:                 System.out.println("Unsupported L&F: " + LF.getClassName());

If L&F is unsupported then don't we need to continue o the next one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1888

From serb at openjdk.java.net  Thu Dec 31 06:36:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 31 Dec 2020 06:36:58 GMT
Subject: <Swing Dev> RFR: JDK-8258884: [TEST_BUG] Convert applet-based
 test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a
 regular java test
In-Reply-To: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
References: <ubRLovcgb3XrLPNsh9lFmPmEwo_-WRoIUbTFWWkG75c=.a49cb4d5-ed71-4b6e-afbb-fbc7e1c9bff6@github.com>
Message-ID: <dl0T90XuRd_2WAoHaxaFvcolDAT8BHkGpJBPRd4SOJk=.ca333016-cf50-4fca-82ee-4b1d4889f1a4@github.com>

On Wed, 23 Dec 2020 11:50:41 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All, Could you please review this fix for JDK16?
> 
> Problem Description: The test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java is applet based.
> 
> Fix: Rewritten the above applet based test to a regular java test.
> 
> Best Regards,
> K Suman Rajkumaar

test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java line 47:

> 45:  * @summary [macosx] Checkmarks of JCheckBoxMenuItems aren't rendered
> 46:  *           in high resolution on Retina
> 47:  * @run main bug8031573

Looks like this line will make the test automatic?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1878

From serb at openjdk.java.net  Thu Dec 31 06:42:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 31 Dec 2020 06:42:57 GMT
Subject: <Swing Dev> RFR: 8231041: Spotbugs: Null check of value
 previously dereferenced in java.desktop [v2]
In-Reply-To: <Uh4vyzlCinj-BQpmaHTr38-ySXlIT_CQI-VPKJKT17Q=.bdfb2485-f4ab-4053-915e-db0f25a70a0f@github.com>
References: <iIzwFcQIarimNFGS2d2WaFthd5VxlBo8y7lcpFeEDQQ=.b3890e83-db0f-4606-859f-4b8689032832@github.com>
 <72reUZEPPtv_rXyPwMpBbfJ-sr4SHX1imj08dLmFERA=.47520947-bb67-4b72-8bf7-54cbb95ae6aa@github.com>
 <CPenN-0zTnmo_NWdOpQj9ZRD9TIuedf2XZVlBTQxUSo=.da820577-7525-4555-bb6c-6a99106b2bb5@github.com>
 <Uh4vyzlCinj-BQpmaHTr38-ySXlIT_CQI-VPKJKT17Q=.bdfb2485-f4ab-4053-915e-db0f25a70a0f@github.com>
Message-ID: <feQdcW1TIfdeLUjtQd7-QDBCfH5Gbg_wOtyjdXIKnUU=.a5f3908c-04a7-42e0-b182-6aa726a4b479@github.com>

On Wed, 23 Dec 2020 11:18:03 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> > So I postponed the fix since the spec clarification is required. I suggest postponing this PR until then.
> 
> Do you know if this clarification is in progress now? As I see from @prrace comment there is https://bugs.openjdk.java.net/browse/JDK-8255800 Do you know any more similar issues?

I do not know any other issues except this one. If you wish to continue to work on this bug, then it will be simpler to only change the code where exceptions are already specified, for example, drop the changes in the DataBufferUShort(), etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1869

From psadhukhan at openjdk.java.net  Thu Dec 31 07:57:10 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 31 Dec 2020 07:57:10 GMT
Subject: <Swing Dev> RFR: 8258924:
 javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F [v2]
In-Reply-To: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
References: <iZRGIGhDPuK1v-RuM3HKE-vDdwlY_TRzzWznl6dDKnM=.2a81b107-fe45-46ac-ab0a-09daf89478d1@github.com>
Message-ID: <DR9unZ-cIskaInDB7XCusm1lLADglmG3Kr3Ue4vECgQ=.548aa562-2f39-4a69-b374-0d7d75495193@github.com>

> This test tests whether SplitPane is opaque or not but in nimbus and subseqeuently in GTK L&F the opaque property is set to false [1]
> As nimbus is already handled in the test, it is modified to handle GTK L&F too. Along with this modification, the test is also updated to test all installed L&Fs.
> Mach5 job running for several iterations for all platform is ok. Link in JBS.
> 
> [1] https://raw.githubusercontent.com/openjdk/jdk/master/src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
>       uiComponent opaque="false" type="javax.swing.JSplitPane" name="SplitPane" ui="SplitPaneUI" subregion="false"

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Continue to next L&F if current one is unsupported

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1888/files
  - new: https://git.openjdk.java.net/jdk/pull/1888/files/e13fb594..c357bd8f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1888&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1888&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1888/head:pull/1888

PR: https://git.openjdk.java.net/jdk/pull/1888

From hs at tagtraum.com  Tue Dec 29 20:07:03 2020
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 29 Dec 2020 21:07:03 +0100
Subject: <Swing Dev> <AWT Dev> EA8 build of Project Lanai (Java 2D Metal
 rendering pipeline for macOS) is now posted
In-Reply-To: <5FDB0F7F.9030206@oracle.com>
References: <5FDB0F7F.9030206@oracle.com>
Message-ID: <404B919B-CB05-455B-9209-7628B84B8A9F@tagtraum.com>

Hi,

For what it?s worth: I have tried this build with metal enabled on a complex Swing application (beaTunes) and wasn?t able to spot any differences.

Great work!

However, after I shut down beaTunes, IDEA wasn?t repainting correctly anymore (see attached screenshot). Note that IDEA was NOT running on the EA8 build. So I am guessing some system resources may not have been freed the way they are supposed to be freed. This was on macOS 10.15.7.

Cheers,

-hendrik



> On Dec 17, 2020, at 08:57, Philip Race <philip.race at oracle.com> wrote:
> 
> The EA 8 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/
> 
> EA 8 Build 17-lanai+1-2 (2020/12/12)
> 
> Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.
> 
> One particular request :
> To anyone who has a mac still running 10.12 - we don't expect Metal to run (it requires at least 10.13
> and maybe even later by the time it is final) but we would like confirmation that nothing in Metal
> prevents OpenGL running on older releases.
> Note there is currently a hotspot build bug unrelated to Lanai that prevents running on 10.10
> and maybe 10.11 but 10.12 will be a useful data point.
> 
> EA 8 contains the following new bug fixes relative to EA 7
> 
> 8257886: Build issue in macOS 10.14
> 8256683: Lanai: NetBeans IDE - AA Text rendering appears brighter compared to OpenGL
> 8242925: J2DDemo - Anti-Aliasing with Metal differs from OGL
> 8257618: Lanai: GradientPaint interpolates over stops limits
> 8257566: Lanai: System runs out of application memory while running the Unmanaged_BufferredImage_draw_NearestNeighbor test multiple times
> 8257441: Lanai: java/awt/image/VolatileImage/DrawHugeImageTest fails
> 8257442: Lanai: Create RenderPerf tests for SW to HW blits
> 8257413: Lanai - Use optimum sized temporary buffer while replacing texture region
> 8238285: Lanai: java/awt/image/DrawImage tests fail
> 8256576: DrawImage/BlitRotateClippedArea fails
> 
> -phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201229/0fc1e418/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-12-29 at 21.01.54.png
Type: image/png
Size: 402941 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201229/0fc1e418/ScreenShot2020-12-29at21.01.54-0001.png>

From hs at tagtraum.com  Tue Dec 29 21:04:24 2020
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 29 Dec 2020 22:04:24 +0100
Subject: <Swing Dev> <AWT Dev> EA8 build of Project Lanai (Java 2D Metal
 rendering pipeline for macOS) is now posted
In-Reply-To: <404B919B-CB05-455B-9209-7628B84B8A9F@tagtraum.com>
References: <5FDB0F7F.9030206@oracle.com>
 <404B919B-CB05-455B-9209-7628B84B8A9F@tagtraum.com>
Message-ID: <84CD9F99-1276-485E-BA79-828266F58601@tagtraum.com>

Hi,

I should add that so far I wasn?t able to repeat this glitch and no other application was affected, so this may also be completely unrelated.

-hendrik

> On Dec 29, 2020, at 21:07, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
> Hi,
> 
> For what it?s worth: I have tried this build with metal enabled on a complex Swing application (beaTunes) and wasn?t able to spot any differences.
> 
> Great work!
> 
> However, after I shut down beaTunes, IDEA wasn?t repainting correctly anymore (see attached screenshot). Note that IDEA was NOT running on the EA8 build. So I am guessing some system resources may not have been freed the way they are supposed to be freed. This was on macOS 10.15.7.
> 
> Cheers,
> 
> -hendrik
> 
> <Screen Shot 2020-12-29 at 21.01.54.png>
> 
>> On Dec 17, 2020, at 08:57, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>> 
>> The EA 8 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/ <https://jdk.java.net/lanai/>
>> 
>> EA 8 Build 17-lanai+1-2 (2020/12/12)
>> 
>> Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.
>> 
>> One particular request :
>> To anyone who has a mac still running 10.12 - we don't expect Metal to run (it requires at least 10.13
>> and maybe even later by the time it is final) but we would like confirmation that nothing in Metal
>> prevents OpenGL running on older releases.
>> Note there is currently a hotspot build bug unrelated to Lanai that prevents running on 10.10
>> and maybe 10.11 but 10.12 will be a useful data point.
>> 
>> EA 8 contains the following new bug fixes relative to EA 7
>> 
>> 8257886: Build issue in macOS 10.14
>> 8256683: Lanai: NetBeans IDE - AA Text rendering appears brighter compared to OpenGL
>> 8242925: J2DDemo - Anti-Aliasing with Metal differs from OGL
>> 8257618: Lanai: GradientPaint interpolates over stops limits
>> 8257566: Lanai: System runs out of application memory while running the Unmanaged_BufferredImage_draw_NearestNeighbor test multiple times
>> 8257441: Lanai: java/awt/image/VolatileImage/DrawHugeImageTest fails
>> 8257442: Lanai: Create RenderPerf tests for SW to HW blits
>> 8257413: Lanai - Use optimum sized temporary buffer while replacing texture region
>> 8238285: Lanai: java/awt/image/DrawImage tests fail
>> 8256576: DrawImage/BlitRotateClippedArea fails
>> 
>> -phil.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20201229/652ce8a4/attachment.htm>