From psadhukhan at openjdk.java.net  Mon Jan  3 15:52:14 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 3 Jan 2022 15:52:14 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <o7kRL5lyYT3K55fm3Mvu6QjCTrldELjBkoWvzwIypsA=.e5f6dd15-6023-448e-8895-587667b2d4cd@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
 <o7kRL5lyYT3K55fm3Mvu6QjCTrldELjBkoWvzwIypsA=.e5f6dd15-6023-448e-8895-587667b2d4cd@github.com>
Message-ID: <5ffx_zVIG1UWqBwzzqhgYEtMnmmke_lSDF_BFDHiSFI=.3ca93942-0232-464b-b94a-567effd5207a@github.com>

On Wed, 15 Dec 2021 23:06:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Does it mean that 3.144 after the first press is a delay caused by some code in the robot?

It seems to be osx12.0.1 system quirk..osx12.1 does not same issue...
Logs in Robot.java#keyPress() shows
1st "a" keypress, keyCode 65 System.timemillis1641224225838
2nd "a" keypress, keyCode 65 System.timemillis 1641224229077 diff of 3239....
not sure if any robot code gets executed between these 2 keypress (done in testcase)

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

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


From prr at openjdk.java.net  Mon Jan  3 18:08:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 3 Jan 2022 18:08:10 GMT
Subject: RFR: 8279337: The MToolkit is still referenced in a few places
In-Reply-To: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
References: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
Message-ID: <ZoZCtwjFSgPFg7kTlYDxZyrdkpFjGa6_75XgKmdotUU=.975a0530-24a2-42b7-9b3c-bfef1884082d@github.com>

On Thu, 30 Dec 2021 06:33:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The MToolkit (motif toolkit) was removed in jdk7, but it is still referenced in a few places.

Marked as reviewed by prr (Reviewer).

src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2021, Oracle and/or its affiliates. All rights reserved.

A little optimistic about getting a review between Dec 29th and Dcc 31st perhaps ? ;-)

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

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


From prr at openjdk.java.net  Mon Jan  3 19:17:17 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 3 Jan 2022 19:17:17 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <M-Vr450lK3WCtV3NIAmm3_ANqFCH2RVJWXqvuHUoFcQ=.29275dba-2f97-41bc-b0c4-361f035886ad@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

This just doesn't feel right. 3 seconds to register a key press ? 
I looked at the system on which this was originally reported and the key delay until repeat looks normal.
We've got at least one other bug open where there's some weirdness on macOS 12 where Robot slows down after "m" is pressed. Could this be something similar ?

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

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


From prr at openjdk.java.net  Mon Jan  3 19:32:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 3 Jan 2022 19:32:18 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v5]
In-Reply-To: <ITpG-N5Y3CEzdN_vYEL88IILX0T5RIyxwkQajXTrooQ=.e2170157-156d-40ca-916d-21f090b4026c@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <fK3Su35ju9JGP1TQBYEpUdCgNU-1PGZLYf19HYyl3a0=.d0936a5f-cee9-4938-b366-b86a6c5203e7@github.com>
 <ITpG-N5Y3CEzdN_vYEL88IILX0T5RIyxwkQajXTrooQ=.e2170157-156d-40ca-916d-21f090b4026c@github.com>
Message-ID: <GbpY7_SSL90_ZkAcmDczIkVM5zuFFEJ_qmbBa3ondT0=.06e6d696-7463-4968-ba1e-411e07b9f14a@github.com>

On Tue, 21 Dec 2021 21:26:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Should we add `@see javax.swing.JTable` to the Javadoc?

I don't think that is necessary. We are in JTable documentation already.

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

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


From prr at openjdk.java.net  Mon Jan  3 19:32:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 3 Jan 2022 19:32:18 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <wCIEODN2LmPyjg_8O7rYJcG-LS0SP35LZFVNZ7lNYJQ=.e603e1fd-bb8e-4208-a2cb-add42d78584f@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

I don't see the CSR  yet. Create it from the "More" menu of the JBS issue.

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

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


From prr at openjdk.java.net  Mon Jan  3 20:52:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 3 Jan 2022 20:52:10 GMT
Subject: RFR: JDK-8276809:
 java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on
 Windows [v3]
In-Reply-To: <l3cNPeoV0gh2UhSU-pQbfDaEVujGRzUrqgWHtbUcJOY=.6ea85ba3-5d76-4a99-a815-1c9f5f227b69@github.com>
References: <88pzPWHZU5dZbSXBuIwFqKeQPEiYxOrlZAU-xqGGVMg=.126a0ae6-4382-4986-89d0-250cc2c71081@github.com>
 <vZdJqlPw_-3v2JnC8K4qxzW8SCwPCvQcbUmy9X4jBRs=.20d73184-0584-4058-8e2d-02d62957592b@github.com>
 <xH3TupkjWB_vf4TLi9gu1HBVki8MO0SmkTPZtPzLGlc=.e11331c3-c639-4b47-8138-23992aaa1e27@github.com>
 <l3cNPeoV0gh2UhSU-pQbfDaEVujGRzUrqgWHtbUcJOY=.6ea85ba3-5d76-4a99-a815-1c9f5f227b69@github.com>
Message-ID: <j7ntpyqiYYcXTb4jvUNzLaML_78xI3sAt0dJ-Zzvd3c=.85094c29-5cc7-414e-9149-4a2c8af7ea54@github.com>

On Thu, 2 Dec 2021 00:50:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The error occurs when starting the tests from the Windows Task scheduler;
> however when running from the task scheduler the error occurs with the fastdebug-JVM not
> when running the opt/product JVM.

hmm. So the task scheduler may not have access to some desktop properties but I still don't see why debug vs product would be different. And the JNU_* function itself makes a sequence of calls without checking for exceptions.
   clazz = (*env)->FindClass(env, class_name);
    if (clazz == 0)
        goto done2;
    mid = (*env)->GetStaticMethodID(env, clazz, name, signature);
    if (mid == 0)
        goto done1;

The specs for these certainly say they may throw exceptions and
I'm very sure the VM doesn't know the code here does a check for ret == 0 so I'm puzzled why the JNU function isn't checking here ?

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

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


From serb at openjdk.java.net  Mon Jan  3 23:25:01 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 3 Jan 2022 23:25:01 GMT
Subject: RFR: 8279337: The MToolkit is still referenced in a few places
 [v2]
In-Reply-To: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
References: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
Message-ID: <2rEhaJ33rvRZdYGTS-f9JetnXidXoLCpKS58FGEk_Wg=.ce1ae014-f610-4356-bc1b-872bc8aef6d6@github.com>

> The MToolkit (motif toolkit) was removed in jdk7, but it is still referenced in a few places.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6939/files
  - new: https://git.openjdk.java.net/jdk/pull/6939/files/6c7ca0df..e5dc2f85

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

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

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


From serb at openjdk.java.net  Mon Jan  3 23:57:14 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 3 Jan 2022 23:57:14 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <W_q148btLkk615X47IXR-6xAaDUT_LC8LMXyVERwtRY=.5fbe37b3-9a3d-48a0-940b-4e6f6f201970@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Any volunteers?

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

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


From serb at openjdk.java.net  Mon Jan  3 23:57:13 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 3 Jan 2022 23:57:13 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <unc7nB3wSkOOimsj4aHDt5gnGLmtfXn8v9MsVYpjKHs=.e1615168-da67-4ad7-86f7-68ed375da769@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Any volunteers?

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

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


From prr at openjdk.java.net  Tue Jan  4 00:00:17 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 4 Jan 2022 00:00:17 GMT
Subject: RFR: 8279337: The MToolkit is still referenced in a few places
 [v2]
In-Reply-To: <2rEhaJ33rvRZdYGTS-f9JetnXidXoLCpKS58FGEk_Wg=.ce1ae014-f610-4356-bc1b-872bc8aef6d6@github.com>
References: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
 <2rEhaJ33rvRZdYGTS-f9JetnXidXoLCpKS58FGEk_Wg=.ce1ae014-f610-4356-bc1b-872bc8aef6d6@github.com>
Message-ID: <oPf8Yy4ZDpvO5JILMDWPBbcEhFhDWH6fzIMg_rXLkqM=.7b488c6c-c1b4-4c3c-881e-fbda8c7d799d@github.com>

On Mon, 3 Jan 2022 23:25:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The MToolkit (motif toolkit) was removed in jdk7, but it is still referenced in a few places.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2022

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Tue Jan  4 02:16:24 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 4 Jan 2022 02:16:24 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v3]
In-Reply-To: <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
Message-ID: <B35vO67S2LUA9WixCx1O6q9WVCg752gTr8TAdOw0Y-Y=.dc3493e1-9249-43b5-bed7-34fe53f80609@github.com>

On Thu, 21 Oct 2021 00:57:47 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>  - revert previous proposal
>  - Merge branch 'master' into 8240756
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Did this bug appear in some release, or do you think it never worked ?

Although I don't expect 255 slots your code like
if (gv.getGlyphCode(i) >= 0x1000000)

and
int slot = gV.getGlyphCode(i) >> 24;

will break if they are ..

The logic in drawGlyphVector where both initial slot != 0 and the final slot are handled
specially make this code more complex than desirable. Can you make the logic cleaner ?

The test relies heavily on internals. I'm not sure how long it will last.
"Pixel" (not Pixcel) count is an indicator that the rendering is the same, but why not
direct pixel to pixel comparison ?
Also it isn't actually testing that Japanese is rendered. It is testing that the images are the same
so if they are both "wrong" the test will still pass.

Did you ever look into why drawString did not need fixing too ?

Have you run other printing tests besides the new one to verify this all works ?

More importantly what on-screen testing have you done ?
Or have you proved CTextPipe is only used in printing ?

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

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


From psadhukhan at openjdk.java.net  Tue Jan  4 04:48:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 4 Jan 2022 04:48:25 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <OaR9qzuEuZ3My0IcdzCvlLOhyPQEQGET4pC6j2TBPa0=.71235e3b-8a0e-482b-80c8-bc0fca98a1a3@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

Not sure if it is similar slowness issue after "m" keypress. For this at least, it is manifested only for repeated keys
as If we type "aad", the time taken for "d" key is (log in Robot#keyPress)
keyCode 68 time 1641224229200 (diff of 123 from last keypress time 1641224229077 )

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

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


From duke at openjdk.java.net  Tue Jan  4 06:32:19 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 4 Jan 2022 06:32:19 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <wCIEODN2LmPyjg_8O7rYJcG-LS0SP35LZFVNZ7lNYJQ=.e603e1fd-bb8e-4208-a2cb-add42d78584f@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
 <wCIEODN2LmPyjg_8O7rYJcG-LS0SP35LZFVNZ7lNYJQ=.e603e1fd-bb8e-4208-a2cb-add42d78584f@github.com>
Message-ID: <NvCulfF9c6gNpyWzUDLEXH-W-h097MTb0OpnnRk0hO0=.25d4d692-f4ed-44cf-b378-277a4924e642@github.com>

On Mon, 3 Jan 2022 19:28:54 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't see the CSR yet. Create it from the "More" menu of the JBS issue.

Yes, CSR is created from JBS..

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

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


From duke at openjdk.java.net  Tue Jan  4 06:41:18 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 4 Jan 2022 06:41:18 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <v0Z0Jn-dkdYebEG7OYSqHx1tuj7C6-LLJ24TvPRrKA8=.0d2dd286-ab51-4c37-b792-d675d43b645e@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Please Review the csr https://bugs.openjdk.java.net/browse/JDK-8279421

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

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


From duke at openjdk.java.net  Tue Jan  4 06:43:10 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Tue, 4 Jan 2022 06:43:10 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <s2gGEOZPg7ZEOuc1_HhoRfeA1pwZTArJzZPwwjybh20=.ce1eebd4-8dba-44a7-b8b2-7b2c8edecb56@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

Please review the csr https://bugs.openjdk.java.net/browse/JDK-8279420

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

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


From kizune at openjdk.java.net  Tue Jan  4 13:18:22 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 4 Jan 2022 13:18:22 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <oB2WutRJVzTLzSlF6qO_c5DxZ42r8aP3Ft9bLaimlrA=.942f9494-d5c1-427e-96c1-079dd05ee5cb@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Marked as reviewed by kizune (Reviewer).

test/jdk/java/awt/event/HierarchyEvent/AncestorResized/AncestorResized.java line 58:

> 56: 
> 57:     public static void main(String[] args) throws Exception {
> 58:         Frame frame;

Not a big fan of the split declaration and initialization of all the variables but that existed before the fix and it is purely cosmetic. Other than that looks good.

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

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


From mbaesken at openjdk.java.net  Tue Jan  4 14:22:25 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 4 Jan 2022 14:22:25 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro detection on
 recent distro SUSE 15
Message-ID: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>

Hello, please review this adjustment for recent SUSE Linux 15.
The font coding on UNIX, see setOsNameAndVersion in files 

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
src/java.desktop/unix/classes/sun/font/MFontConfiguration.java

uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :

Example content of /etc/os-release
NAME="SLES"
VERSION="12-SP2"
VERSION_ID="12.2"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"

There the name and version information is stored (NAME=... , VERSION_ID=...).

Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?

Thanks, Matthias

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

Commit messages:
 - JDK-8278549

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

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


From kizune at openjdk.java.net  Tue Jan  4 17:39:12 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 4 Jan 2022 17:39:12 GMT
Subject: [jdk18] RFR: 8278612: [macos]
 test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on
 macOS
In-Reply-To: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
References: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
Message-ID: <Fq4Uit9wCU5FWhtNkO9YhYN_qSHbjwCmW4LLkWxZsFs=.d9356bb7-a5f3-4c86-8d1b-eff942f52bfa@github.com>

On Wed, 22 Dec 2021 12:42:30 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

Looks good to me.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/65


From aivanov at openjdk.java.net  Tue Jan  4 20:59:15 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 4 Jan 2022 20:59:15 GMT
Subject: [jdk18] RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
References: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
Message-ID: <f97ONTdwgVEDNj7UUWVY21k2CvKoA-blIcgRE5lr6as=.ea3484d9-49fb-4fa7-9fd0-0114806c5e00@github.com>

On Tue, 21 Dec 2021 15:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

Any volunteers to review?

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

PR: https://git.openjdk.java.net/jdk18/pull/54


From naoto at openjdk.java.net  Tue Jan  4 21:12:16 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 4 Jan 2022 21:12:16 GMT
Subject: [jdk18] RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
References: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
Message-ID: <MpLHo5WrHHFNyoEoVN2sxQyOHEY8dDfTF9YbJFjsQeY=.f2ca6187-0b79-4e1b-894f-ec52c3f2494f@github.com>

On Tue, 21 Dec 2021 15:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

Looks correct.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/54


From prr at openjdk.java.net  Wed Jan  5 02:13:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 5 Jan 2022 02:13:55 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does not
 work properly for SheetCollate
Message-ID: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>

This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.

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

Commit messages:
 - 4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

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

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


From serb at openjdk.java.net  Wed Jan  5 03:47:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 5 Jan 2022 03:47:15 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate
In-Reply-To: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
Message-ID: <aJR4llRyhFbWyYj8BsDwkR5cWKxN-ao8jGnA5AAR8mA=.0bc5aa28-9b53-4d19-9b80-015bd8e50a1b@github.com>

On Wed, 5 Jan 2022 02:05:29 GMT, Phil Race <prr at openjdk.org> wrote:

> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.

test/jdk/javax/print/attribute/StreamServiceSheetCollateTest.java line 52:

> 50:         OutputStream out = new ByteArrayOutputStream();
> 51:         StreamPrintService sps = fact[0].getPrintService(out);
> 52:         if (!sps.isAttributeCategorySupported(SheetCollate.class)) {

Can we add other attributes to the tests? I made a quick check for some attributes and it looks like the code is quite confused, on my windows, the same issue exists for the "OrientationRequested.class".

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

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


From myano at openjdk.java.net  Wed Jan  5 09:55:17 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 5 Jan 2022 09:55:17 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <O-d8kcmTYF8iJVWdOtbzEJ2_wQTead4JoZm63u-MJss=.d3c5f9b5-788e-4f6c-a028-41642eff61b6@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb Could you please check this pull request?

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

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


From myano at openjdk.java.net  Wed Jan  5 09:58:08 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 5 Jan 2022 09:58:08 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v3]
In-Reply-To: <EzgzwF2UBALTquK53lMx3zFJ5WAjr6aVdVmknJzto5k=.5808613e-7df4-4483-b364-18102b7ce285@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <1APEWt6EfSMXZSLa9JNxgLwQpdtfpOBE1VBgXCUntxM=.83285e41-fd61-452d-b3bf-7da6ce4f432b@github.com>
 <T6_ck6kgpSKNJA2rgB-GtP5dnTpV02QWh7r583Sf-R8=.5fff3497-d130-450c-8c20-ba0a902396cc@github.com>
 <EzgzwF2UBALTquK53lMx3zFJ5WAjr6aVdVmknJzto5k=.5808613e-7df4-4483-b364-18102b7ce285@github.com>
Message-ID: <hKfzg2Ncjv-Q43_CC04Ids8tHKClVfZ7QuDQxvEnDA8=.dbe2b0c2-3bd3-497e-8080-f6c00953ab59@github.com>

On Tue, 21 Dec 2021 05:28:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I fixed the test as it was pointed out to me.
>
> Now it cannot be compiled due to "unreported exception java.lang.ClassNotFoundException; must be caught or declared to be thrown" from the setLookAndFeel(); Note that the new version still has a race, the invokeLater/setLookAndFeel can be executed later than the code in the showOpenDialog(), so the code in showOpenDialog may use the wrong L&F properties, can we move the showOpenDialog to the EDT as well?

@mrserb Could you please confirm to the above comment and fix?

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

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


From psadhukhan at openjdk.java.net  Wed Jan  5 10:20:17 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 5 Jan 2022 10:20:17 GMT
Subject: RFR: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in [v3]
In-Reply-To: <XnwVVItT5RLvjQ2RCOd7AKyy1cBcKYT8AUzrcBjJ71M=.b47b5e43-4b36-4962-bce6-6a487168d9b9@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
 <XnwVVItT5RLvjQ2RCOd7AKyy1cBcKYT8AUzrcBjJ71M=.b47b5e43-4b36-4962-bce6-6a487168d9b9@github.com>
Message-ID: <IneMIMZb0Fm-WWkNxcReuMqmkCxDX3xNbU96OV91bCo=.f1d7fe03-09f2-4c14-9156-00c2087439e5@github.com>

On Thu, 23 Dec 2021 09:39:59 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> I would like to fix the bug reported in JDK-8277463.
>> 
>> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in

Although it is reproduced for Nimbus L&F too due to which I did not mention to use Metal L&F at start, but I don't object to switch to Metal at start.

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

Marked as reviewed by psadhukhan (Reviewer).

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


From aivanov at openjdk.java.net  Wed Jan  5 16:25:18 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 5 Jan 2022 16:25:18 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <P3CAcwMHQeKUujY-WSP7g_AdZIZ01I0U1kl-lFCj7RI=.09761d6c-4e63-49f2-a824-e980f234bba3@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Marked as reviewed by aivanov (Reviewer).

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

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


From dcubed at openjdk.java.net  Wed Jan  5 16:30:42 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 16:30:42 GMT
Subject: [jdk18] RFR: 8279525: ProblemList
 java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
Message-ID: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>

A trivial fix to ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64.

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

Commit messages:
 - 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64

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

PR: https://git.openjdk.java.net/jdk18/pull/81


From ccheung at openjdk.java.net  Wed Jan  5 16:35:21 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 5 Jan 2022 16:35:21 GMT
Subject: [jdk18] RFR: 8279525: ProblemList
 java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
In-Reply-To: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>
References: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>
Message-ID: <tYPc2EjaPaPEA3AA7iu6x_EEFHo7VIi49UpcJPurjxc=.bc511633-5c89-4bf5-b527-155acda38513@github.com>

On Wed, 5 Jan 2022 16:22:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64.

Looks good and trivial.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/81


From dcubed at openjdk.java.net  Wed Jan  5 16:41:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 16:41:21 GMT
Subject: [jdk18] RFR: 8279525: ProblemList
 java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
In-Reply-To: <tYPc2EjaPaPEA3AA7iu6x_EEFHo7VIi49UpcJPurjxc=.bc511633-5c89-4bf5-b527-155acda38513@github.com>
References: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>
 <tYPc2EjaPaPEA3AA7iu6x_EEFHo7VIi49UpcJPurjxc=.bc511633-5c89-4bf5-b527-155acda38513@github.com>
Message-ID: <m0-5jq5JBUv3xx2cN1_PqPzfYOSBwrbusUi3DFSDOw4=.47596d09-ef80-4992-9634-a3d3ceff9129@github.com>

On Wed, 5 Jan 2022 16:32:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64.
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk18/pull/81


From dcubed at openjdk.java.net  Wed Jan  5 16:41:22 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 5 Jan 2022 16:41:22 GMT
Subject: [jdk18] Integrated: 8279525: ProblemList
 java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
In-Reply-To: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>
References: <jpEgbo7Jd1hMqiDJidgQicb6EdHW5HlcwSEq6nSYCZk=.926f2dd1-d49b-47d6-819d-94a5f6307f66@github.com>
Message-ID: <jzcng4Y0cIyBHi73YHYeF8HN0KefiPiazC50mmxE0fM=.1c71efeb-ae63-4a88-bf25-ab8c0a59f21f@github.com>

On Wed, 5 Jan 2022 16:22:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64.

This pull request has now been integrated.

Changeset: 5cd95153
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/5cd95153331860f990c268bd28e4cd38f3ce6d4a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64

Reviewed-by: ccheung

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

PR: https://git.openjdk.java.net/jdk18/pull/81


From achung at openjdk.java.net  Wed Jan  5 16:58:53 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 5 Jan 2022 16:58:53 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added check for other L&Fs, added newline to test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/9bf899fa..0a6283bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=09-10

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

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


From vdyakov at openjdk.java.net  Wed Jan  5 17:28:15 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 5 Jan 2022 17:28:15 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
Message-ID: <uelEmAev75QFeuBZRui7-Ww-S9_Vzvyq4C2G77mvrZA=.5016dbba-b99a-4294-af11-684153cd0c86@github.com>

On Wed, 5 Jan 2022 16:58:53 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for other L&Fs, added newline to test

@aivanov-jdk  @azuev-java please review

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

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


From lbourges at openjdk.java.net  Wed Jan  5 17:35:19 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 5 Jan 2022 17:35:19 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v10]
In-Reply-To: <zpv7BNMCYGS46-g71oPhITHOJkvAOmOe9fOZZD3LGM4=.bb761f9a-e2a8-47d4-b377-56a5c0db45a5@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <W1sc79kkjjEU2gMwVffM-tW9nvdr4hIkRNvWJrkPzXY=.0d9881e6-2761-4fe2-81e3-86abb50fd5ca@github.com>
 <zpv7BNMCYGS46-g71oPhITHOJkvAOmOe9fOZZD3LGM4=.bb761f9a-e2a8-47d4-b377-56a5c0db45a5@github.com>
Message-ID: <0jRj8FQfLFl9f_O6UEeTZQQwssHqZ4bf0CoXHN65XsU=.0cb202ca-e18f-4918-b4b6-c8bae07df3f2@github.com>

On Wed, 15 Dec 2021 23:49:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   Addressing code review feedback: "Use BigDecomal.setScale(40) to ascertain precision."
>>   
>>   The geom.* unit tests passed before & after this change.
>>   
>>   https://github.com/openjdk/jdk/pull/6227#discussion_r752908494
>
> There seems to be a number of things to discuss aside from the maths
> 
> - You are changing the signature of public API
>   src/java.desktop/share/classes/java/awt/geom/Path2D.java
> public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
> 
> So no longer final, and no longer synchronized.
> This means a CSR is required and we need to think about it .. the intention was that the subclass not over-ride.
> And why remove synchronized ? I am fairly sure it was there to make sure no one was mutating the Path whilst
> bounds are being calculated.
> And you are using getPathIterator(AffineTransform) and the docs for that say it isn't thread safe.
> So I think this implementation needs to be thought about very carefully.
> 
> - You are adding a new public static method
> 
> public static Rectangle2D getBounds2D(final PathIterator pi);
> 
> Is this really necessary ? It is just for the benefit of the public API caller so can be package private.
> 
> - For me it doesn't build because of a doclint error
> 
> src/java.desktop/share/classes/java/awt/geom/Path2D.java:2102: warning: no @param for pi
>     public static Rectangle2D getBounds2D(final PathIterator pi) {
>                               ^
> error: warnings found and -Werror specified
> 
> Fixing that I find that the updated UnitTest.java fail with a build with these changes :-
> 
> % java UnitTest
> Exception in thread "main" java.lang.RuntimeException: the shape must not intersect anything above its bounds
>     at UnitTest.testGetBounds2D(UnitTest.java:1396)
>     at UnitTest.testBounds(UnitTest.java:1302)
>     at UnitTest.test(UnitTest.java:1175)
>     at UnitTest.main(UnitTest.java:1435)
> 
> Then we have some even more difficult questions.
> The control points may not be within the bounds of the curve which is of course the premise of the bug report.
> The specification (javadoc) isn't very forthcoming on whether it is allowed to not include them .. ie is it expected they should be ?
> And it appears we have JCK tests which expect they ARE included. So as it is this change would not pass the existing TCK/JCK. 
> Which means we'd have to be 100% sure about this change in behaviour and be able to justify it.
> FWIW unless the spec explicitly says they are, in some place I've overlooked,
> then I'd say its a quality-of-implementation thing as to how tight the bounds are, and the new behaviour is allowed by spec.
> Applications however might still find this a behaviourally incompatible change .. and could potentially see undesirable consequences -
> even as other applications see better consequences.
> So perhaps new API that defines tighter bounds  might be  the way to address this .. but I am far from being sure about that.

@prrace could you say on CSR or not ?

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

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


From ant at openjdk.java.net  Wed Jan  5 18:40:22 2022
From: ant at openjdk.java.net (Anton Tarasov)
Date: Wed, 5 Jan 2022 18:40:22 GMT
Subject: [jdk18] Integrated: 8278612: [macos]
 test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on
 macOS
In-Reply-To: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
References: <H3iBh16sydeJH-75Mc7F1g_V9Q8b6fqffVirO0ICMLc=.2b160644-f689-48f6-b28e-8b42c567ae19@github.com>
Message-ID: <0MUHcyOHsrDF0aR-oQkx2meTqwOBTukGr4SiLtkIR1s=.23c1074c-1fdd-43f5-a96e-ad32e8b57481@github.com>

On Wed, 22 Dec 2021 12:42:30 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

This pull request has now been integrated.

Changeset: 590fa9d8
Author:    Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/590fa9d8d75b4cf401fe5a1556f4f0b7145a77ab
Stats:     28 lines in 3 files changed: 20 ins; 0 del; 8 mod

8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS

Reviewed-by: serb, kizune

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

PR: https://git.openjdk.java.net/jdk18/pull/65


From prr at openjdk.java.net  Wed Jan  5 19:11:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 5 Jan 2022 19:11:03 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate [v2]
In-Reply-To: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
Message-ID: <oQW8DgcY1S7Jw7Fla-n-9yyp-mggzMsNy_oR1sz8abc=.96719f47-efd0-4553-88a0-d01b111c7dd7@github.com>

> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.

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

   4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6963/files
  - new: https://git.openjdk.java.net/jdk/pull/6963/files/a360aee6..69f49feb

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

  Stats: 176 lines in 3 files changed: 104 ins; 71 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6963.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6963/head:pull/6963

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


From prr at openjdk.java.net  Wed Jan  5 19:11:07 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 5 Jan 2022 19:11:07 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate [v2]
In-Reply-To: <aJR4llRyhFbWyYj8BsDwkR5cWKxN-ao8jGnA5AAR8mA=.0bc5aa28-9b53-4d19-9b80-015bd8e50a1b@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
 <aJR4llRyhFbWyYj8BsDwkR5cWKxN-ao8jGnA5AAR8mA=.0bc5aa28-9b53-4d19-9b80-015bd8e50a1b@github.com>
Message-ID: <GkRQzGJ90ik8-TkUxjS4zvShouT-Mn2UaIbSSoYHgf8=.c5979850-a61e-410a-b31b-42c83328aecf@github.com>

On Wed, 5 Jan 2022 03:43:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate
>
> test/jdk/javax/print/attribute/StreamServiceSheetCollateTest.java line 52:
> 
>> 50:         OutputStream out = new ByteArrayOutputStream();
>> 51:         StreamPrintService sps = fact[0].getPrintService(out);
>> 52:         if (!sps.isAttributeCategorySupported(SheetCollate.class)) {
> 
> Can we add other attributes to the tests? I made a quick check for some attributes and it looks like the code is quite confused, on my windows, the same issue exists for the "OrientationRequested.class".

I've also fixed OrientationRequested and added other Enum attributes to the test.

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

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


From prr at openjdk.java.net  Wed Jan  5 20:21:07 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 5 Jan 2022 20:21:07 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate [v3]
In-Reply-To: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
Message-ID: <X6eie_zc_qtxxiY9lz5e7tiuDOnGCLX7DN25zn7nYa4=.c25d1539-72bf-4eee-85ef-6c091d29a9da@github.com>

> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.

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

   4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6963/files
  - new: https://git.openjdk.java.net/jdk/pull/6963/files/69f49feb..7722c2c3

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

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

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


From prr at openjdk.java.net  Wed Jan  5 22:54:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 5 Jan 2022 22:54:18 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
Message-ID: <i8wNF6CsEhC-9p88qf8vH9nSdhDDwcFjY7Z2QMpvz4Y=.81f1d2ff-d730-4e43-8782-329736fe78e2@github.com>

On Thu, 16 Dec 2021 18:33:37 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> This removes code that relied on consulting the Bezier control points to calculate the Rectangle2D bounding box. Instead it's pretty straight-forward to convert the Bezier control points into the x & y parametric equations. At their most complex these equations are cubic polynomials, so calculating their extrema is just a matter of applying the quadratic formula to calculate their extrema. (Or in path segments that are quadratic/linear/constant: we do even less work.)
>> 
>> The bug writeup indicated they wanted Path2D#getBounds2D() to be more accurate/concise. They didn't explicitly say they wanted CubicCurve2D and QuadCurve2D to become more accurate too. But a preexisting unit test failed when Path2D#getBounds2D() was updated and those other classes weren't. At this point I considered either:
>> A. Updating CubicCurve2D and QuadCurve2D to use the new more accurate getBounds2D() or
>> B. Updating the unit test to forgive the discrepancy.
>> 
>> I chose A. Which might technically be seen as scope creep, but it feels like a more holistic/better approach.
>> 
>> Other shapes in java.awt.geom should not require updating, because they already identify concise bounds.
>> 
>> This also includes a new unit test (in Path2D/UnitTest.java) that fails without the changes in this commit.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>   
>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>   
>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>   
>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>   
>   This is in response to prrace's code review:
>   
>   >    You are changing the signature of public API
>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>   >
>   > So no longer final, and no longer synchronized.
>   > This means a CSR is required and we need to think about it ..
>   > the intention was that the subclass not over-ride.
>   > And why remove synchronized ? I am fairly sure it was there to
>   > make sure no one was mutating the Path whilst
>   > bounds are being calculated.
>   > And you are using getPathIterator(AffineTransform) and the docs
>   > for that say it isn't thread safe.
>   > So I think this implementation needs to be thought about very carefully.

I still recommend a CSR since
1) Although "compatible", this visibly moves the specs for getBounds2D() from copies on the Float and Double nested sub-classes to the enclosing parent class
2) Although in the spirit of what getBounds2D() is supposed to do  .. it actually hasn't for over 20 years. We like to document such behavioural changes via a CSR.

Actually regarding (1) there's also a real change there too since now The Float subclass will return a Rectangle2D.Double .. I am not sure that we should actually do that.

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

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


From prr at openjdk.java.net  Thu Jan  6 00:30:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 6 Jan 2022 00:30:18 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <0ULpsdHYR4YNgqjVbmPfxWkFQDdHKD9HLIsINVPe6Fc=.36e23369-c812-4308-a481-54e2b5de2b88@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

This looks reasonable to me.  Seems unlikely to do any harm.

Can we have a (manual) test along the lines of the sample code so folks can verify the scenarios ?

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

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


From jwilhelm at openjdk.java.net  Thu Jan  6 00:52:49 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 6 Jan 2022 00:52:49 GMT
Subject: RFR: Merge jdk18
Message-ID: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
 - 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS
 - 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64
 - 8278897: Alignment of heap segments is not enforced correctly
 - 8279222: Incorrect legacyMap.get in java.security.Provider after JDK-8276660
 - 8278948: compiler/vectorapi/reshape/TestVectorCastAVX1.java crashes in assembler

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6975/files
  Stats: 750 lines in 28 files changed: 687 ins; 8 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6975/head:pull/6975

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


From jwilhelm at openjdk.java.net  Thu Jan  6 01:30:25 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 6 Jan 2022 01:30:25 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>
References: <kDznDSRknZuL6_YIcikb_iYSWb9I_olD3_mZuM2tUrQ=.c3e92d60-0716-44af-ac9d-4c00675162bd@github.com>
Message-ID: <T3U1fecEM_kjFzm9hlfUE93R9wVvPXXg4_Bsay8Ppbk=.75dded0d-1b32-475e-8da1-3a6cd47fbac4@github.com>

On Thu, 6 Jan 2022 00:42:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 844dfb3a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/844dfb3ab6a1d8b68ccdcc73726ee0f73cfcb3c8
Stats:     750 lines in 28 files changed: 687 ins; 8 del; 55 mod

Merge

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

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


From tnakamura at openjdk.java.net  Thu Jan  6 02:49:17 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 6 Jan 2022 02:49:17 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v4]
In-Reply-To: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
Message-ID: <EpGBL9QudBtYJsU6Ylku5Uc-8qd2FBLLodd-gW7d2ig=.e9f6daeb-ec55-4271-a6be-c9dad0c08ff9@github.com>

> Hi,
> 
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
> 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.

Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Revised according to review comments
 - Merge branch 'master' into 8240756
 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
 - revert previous proposal
 - Merge branch 'master' into 8240756
 - 2nd proposal
 - Revert previous change
 - Merge branch 'master' into 8240756
   merge master
 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3619/files
  - new: https://git.openjdk.java.net/jdk/pull/3619/files/c52a9f98..e5d3a032

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

  Stats: 973589 lines in 3327 files changed: 514106 ins; 439563 del; 19920 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619

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


From tnakamura at openjdk.java.net  Thu Jan  6 02:56:20 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 6 Jan 2022 02:56:20 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v3]
In-Reply-To: <B35vO67S2LUA9WixCx1O6q9WVCg752gTr8TAdOw0Y-Y=.dc3493e1-9249-43b5-bed7-34fe53f80609@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>
 <B35vO67S2LUA9WixCx1O6q9WVCg752gTr8TAdOw0Y-Y=.dc3493e1-9249-43b5-bed7-34fe53f80609@github.com>
Message-ID: <QIv-EDd6ugv7jfeQqcWc5gIZbHLsft3a6gDTFJQh9yY=.0accc12d-0b7b-4da6-b2be-6214b11cbded@github.com>

On Tue, 4 Jan 2022 02:12:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>>  - revert previous proposal
>>  - Merge branch 'master' into 8240756
>>  - 2nd proposal
>>  - Revert previous change
>>  - Merge branch 'master' into 8240756
>>    merge master
>>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>
> Did this bug appear in some release, or do you think it never worked ?
> 
> Although I don't expect 255 slots your code like
> if (gv.getGlyphCode(i) >= 0x1000000)
> 
> and
> int slot = gV.getGlyphCode(i) >> 24;
> 
> will break if they are ..
> 
> The logic in drawGlyphVector where both initial slot != 0 and the final slot are handled
> specially make this code more complex than desirable. Can you make the logic cleaner ?
> 
> The test relies heavily on internals. I'm not sure how long it will last.
> "Pixel" (not Pixcel) count is an indicator that the rendering is the same, but why not
> direct pixel to pixel comparison ?
> Also it isn't actually testing that Japanese is rendered. It is testing that the images are the same
> so if they are both "wrong" the test will still pass.
> 
> Did you ever look into why drawString did not need fixing too ?
> 
> Have you run other printing tests besides the new one to verify this all works ?
> 
> More importantly what on-screen testing have you done ?
> Or have you proved CTextPipe is only used in printing ?

Thank you for the comments, @prrace

> Did this bug appear in some release, or do you think it never worked ?

I think it never worked.

> Although I don't expect 255 slots your code like if (gv.getGlyphCode(i) >= 0x1000000)
> and int slot = gV.getGlyphCode(i) >> 24;
> will break if they are ..

Fixed. Thank you for pointing out.

> The logic in drawGlyphVector where both initial slot != 0 and the final slot are handled specially make this code more complex than desirable. Can you make the logic cleaner ?

Revised the logic.

> The test relies heavily on internals. I'm not sure how long it will last.

I agree. But, without using OSXOffScreenSurfaceData class, printing test is required. I think it's hard to create automate tests.

> "Pixel" (not Pixcel) count is an indicator that the rendering is the same, but why not direct pixel to pixel comparison ? Also it isn't actually testing that Japanese is rendered. It is testing that the images are the same so if they are both "wrong" the test will still pass.

I'm sorry for misspelling. I revised the testcase. I realized that fallback fonts are different between CoreText library and Java side. So, now the test will check the drawing bounds of test string by drawGlyphVector. Also, if there is no capable font, it will be skipped.

> Did you ever look into why drawString did not need fixing too ?

I'm not fully understanding CoreText library, but CTLine object picked up automatically fallback fonts by Unicode data.

> Have you run other printing tests besides the new one to verify this all works ?

Yes. We've tested some printing based on J2Ddemo and SwingSet2 with non-ASCII characters.

> More importantly what on-screen testing have you done ? Or have you proved CTextPipe is only used in printing ?

I wasn't able to find the way to call the method except the scenario in the original report, which is to print JTable with non-ASCII characters. If this method had been used more, more people would have found it.

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

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


From psadhukhan at openjdk.java.net  Thu Jan  6 06:23:15 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 6 Jan 2022 06:23:15 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate [v3]
In-Reply-To: <X6eie_zc_qtxxiY9lz5e7tiuDOnGCLX7DN25zn7nYa4=.c25d1539-72bf-4eee-85ef-6c091d29a9da@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
 <X6eie_zc_qtxxiY9lz5e7tiuDOnGCLX7DN25zn7nYa4=.c25d1539-72bf-4eee-85ef-6c091d29a9da@github.com>
Message-ID: <gp-v3AV9KZbQJfosStQV74AhujjYZBqt7RaOdJvt-LA=.35fb4c28-86de-4fa6-88d6-7f6b11989aa2@github.com>

On Wed, 5 Jan 2022 20:21:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>    4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

src/java.desktop/share/classes/sun/print/PSStreamPrintService.java line 453:

> 451:                 !(flavor.equals(DocFlavor.SERVICE_FORMATTED.PAGEABLE) ||
> 452:                 flavor.equals(DocFlavor.SERVICE_FORMATTED.PRINTABLE))) {
> 453:                 return attr == SheetCollate.UNCOLLATED;

Shouldn't we need to do the same for SheetCollate in WIn32PrintService#isATtributeValueSupported() where it always return false?

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

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


From serb at openjdk.java.net  Thu Jan  6 06:27:17 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 6 Jan 2022 06:27:17 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <iqx3JNgQo0_nrNFZOGdRZhOa7D4kIY9LIk6UeqnV5fc=.99614893-b9b6-4412-a4f5-40d955c7fe2f@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Jan  6 06:30:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 6 Jan 2022 06:30:27 GMT
Subject: RFR: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate [v3]
In-Reply-To: <X6eie_zc_qtxxiY9lz5e7tiuDOnGCLX7DN25zn7nYa4=.c25d1539-72bf-4eee-85ef-6c091d29a9da@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
 <X6eie_zc_qtxxiY9lz5e7tiuDOnGCLX7DN25zn7nYa4=.c25d1539-72bf-4eee-85ef-6c091d29a9da@github.com>
Message-ID: <-GMXtcFg2gQnAlY2t0NdZLYAI8I5DiTAWO6Xz7hjCOQ=.98691767-e2d6-46e8-ab38-6227821545b5@github.com>

On Wed, 5 Jan 2022 20:21:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>    4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.java.net  Thu Jan  6 09:12:11 2022
From: duke at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 6 Jan 2022 09:12:11 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <X-swpflkp-D1PZSKVSi0ZCwhd5CTDrp5PHsCpxKrPAc=.5d66b608-76bf-4a61-824a-4394fb4dcf2d@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

1. Run the test code on a screen with DPI scaling set to 100%, the frame icon displayed should be "16"

![image](https://user-images.githubusercontent.com/54304/148357766-541ebc0d-343a-4135-a2a6-d4a57e60f446.png)

2. Change the DPI scaling of the screen (or move the frame to a secondary screen with a different scaling), the frame icon should change ("20" at 125%, "24" at 150%)

![image](https://user-images.githubusercontent.com/54304/148357980-457068b0-cdd0-43e7-b4dc-6d7c10c78b68.png)

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

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


From psadhukhan at openjdk.java.net  Thu Jan  6 10:05:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 6 Jan 2022 10:05:24 GMT
Subject: [jdk18] RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
References: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
Message-ID: <RdXBRyr4wvprIAe094DxRFYR9NoBAHuZlYh7lIoHhQc=.20c51785-2986-4737-ae19-753a71de42b5@github.com>

On Tue, 21 Dec 2021 15:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

It looks reasonable to me.. But for confidence, did you check if JDK-8147842, JDK-8184016 and  JDK-8183504 still behaves properly.
Also, I guess since ATR is almost done, I think it will be more apt to place this PR on the mainline

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

PR: https://git.openjdk.java.net/jdk18/pull/54


From shade at openjdk.java.net  Thu Jan  6 10:17:12 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 6 Jan 2022 10:17:12 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <oVIT1cI8WZMIqx7sA1BOhFnfs1vmR1lhXplRTR13Gvo=.514185b5-1a70-4400-8950-8f2b42a08760@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

I think Phil meant adding the reproducer as "manual" jtreg test, like this one:
 https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Frame/CycleThroughFrameTest/CycleThroughFrameTest.java

Notice `@run main/manual CycleThroughFrameTest` -- it would not run automatically, but interested parties could execute that test manually.

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

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


From psadhukhan at openjdk.java.net  Thu Jan  6 11:11:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 6 Jan 2022 11:11:24 GMT
Subject: RFR: 8278232: [macos] Wrong chars emitted when entering certain
 char-sequence of Indic language
Message-ID: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>

Devanagiri script was not rendered properly in macos after JDK-8068283 due to incorporated check of utf16 string encoding should be more than 2 bytes is not satisfied. 
Additional check added in JDK-8132503 to ascertain if utf8 string encoding is complex or not was also not satisfied because of which complex Devanagairi unicode text insertion was not working.
Fix is to add Devanagiri codePoint to the complex list so that it is rendered properly.

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

Commit messages:
 - 8278232: [macos] Wrong chars emitted when entering certain char-sequence of Indic language

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

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


From prr at openjdk.java.net  Thu Jan  6 19:10:20 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 6 Jan 2022 19:10:20 GMT
Subject: Integrated: 4884570: StreamPrintService.isAttributeValueSupported does
 not work properly for SheetCollate
In-Reply-To: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
References: <lW16pX4mj2DtaaB6mkYPVmn4-IsfPYU4WtqCg_1-eL4=.ec8a964c-49eb-4718-be11-85fa6c0087ac@github.com>
Message-ID: <Xkul0KeZibsvCGTNf_DXaoa3N6_glyjgKtUyZQwpw5A=.0a9c6006-d7cf-432d-8a02-9f7b3e35f52b@github.com>

On Wed, 5 Jan 2022 02:05:29 GMT, Phil Race <prr at openjdk.org> wrote:

> This fixes a longstanding consistency issue where the Postscript StreamPrintService would report SheetCollate.UNCOLLATED in a list of supported values then report it was not supported under the same conditions.

This pull request has now been integrated.

Changeset: b3dbfc64
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3dbfc645283cb315016ec531ec41570ab3f75f1
Stats:     106 lines in 2 files changed: 104 ins; 0 del; 2 mod

4884570: StreamPrintService.isAttributeValueSupported does not work properly for SheetCollate

Reviewed-by: serb

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

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


From duke at openjdk.java.net  Fri Jan  7 05:16:19 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 7 Jan 2022 05:16:19 GMT
Subject: Withdrawn: 8273101: Eliminate the usage of threadgroup sandboxing in
 the java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <yiliCDBKpkYdho_Ka45ADOFlWQQvBU3vquvJq3PPrRk=.4ca6855f-25e8-4616-b647-baa3c9efc330@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

This pull request has been closed without being integrated.

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

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


From aivanov at openjdk.java.net  Fri Jan  7 17:12:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 7 Jan 2022 17:12:28 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
Message-ID: <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>

On Wed, 5 Jan 2022 16:58:53 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for other L&Fs, added newline to test

The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.

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

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


From aivanov at openjdk.java.net  Fri Jan  7 18:08:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 7 Jan 2022 18:08:29 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
Message-ID: <IMNQHL2pmAc3pP6ZyPD11gWMTxghlgTY6B6sRZ1QiEQ=.2e026c1c-7923-4e3e-9e40-96c9d588e30a@github.com>

On Wed, 5 Jan 2022 16:58:53 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for other L&Fs, added newline to test

src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 195:

> 193:         return new Rectangle(insets.left, 0,
> 194:                 fScrollBar.getWidth() - (insets.left + insets.right),
> 195:                 fScrollBar.getHeight());

What about vertical insets? Horizontal insets are handled now yet the border could render something vertically.

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

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


From aivanov at openjdk.java.net  Fri Jan  7 18:38:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 7 Jan 2022 18:38:29 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
 <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>
Message-ID: <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>

On Fri, 7 Jan 2022 17:09:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.

I decided to go ahead and experimented with the test. [My latest version](https://github.com/aivanov-jdk/jdk/blob/7ab9cdae8151dd71c60d752991c3d44dc2d0f76e/test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java) is available on GitHub. It should work in headless environment. (I noticed that the test doesn't have `@key headful` where it must have been there.) I added saving the images captured if the test fails, which should help in analyzing the failure.

This version of the test fails for me on builds without the fix and passes on the build with the fix included. @alisenchung, you can cherry-pick the changes from my branch into yours.

Probably it's enough to capture only the second image and then check for the color of the border.

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

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


From achung at openjdk.java.net  Fri Jan  7 20:07:38 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 7 Jan 2022 20:07:38 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
 <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>
 <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
Message-ID: <kBgRmilfjMQSx6I3LJ0TIJyYfep4aNpZpW0SIMCjJh4=.2628f512-6e50-4cff-b8e9-01c3e5d3e118@github.com>

On Fri, 7 Jan 2022 18:35:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.
> 
> I decided to go ahead and experimented with the test. [My latest version](https://github.com/aivanov-jdk/jdk/blob/7ab9cdae8151dd71c60d752991c3d44dc2d0f76e/test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java) is available on GitHub. It should work in headless environment. (I noticed that the test doesn't have `@key headful` where it must have been there.) I added saving the images captured if the test fails, which should help in analyzing the failure.
> 
> This version of the test fails for me on builds without the fix and passes on the build with the fix included. @alisenchung, you can cherry-pick the changes from my branch into yours.
> 
> Probably it's enough to capture only the second image and then check for the color of the border.

Thanks!

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

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


From serb at openjdk.java.net  Fri Jan  7 20:18:19 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 7 Jan 2022 20:18:19 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled. [v2]
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <QLAkOSagZwospdX3d-RPfWC8TggHG2jJf43GZQa4dyY=.00b024db-ec7f-48fc-aba5-b0b6992ff65e@github.com>

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8225122
 - Update AncestorResized.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5711/files
  - new: https://git.openjdk.java.net/jdk/pull/5711/files/7f5a6c24..1ea40057

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

  Stats: 1015911 lines in 4148 files changed: 544293 ins; 447874 del; 23744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5711/head:pull/5711

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


From aivanov at openjdk.java.net  Fri Jan  7 22:15:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 7 Jan 2022 22:15:37 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <z8cB3cuRBxYkyepTP830FRHFupXULjQjE8qbLjQjOe4=.662e8c6e-161a-4bd0-b77a-9db9d549bc5a@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Fri Jan  7 22:20:32 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 7 Jan 2022 22:20:32 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <zI0jc9FnEbn3skWFxivZlTPh27dP9rbQSRtrL5eajCA=.039d3fe3-bd51-44d7-a4f3-caa79695268a@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Marked as reviewed by aivanov (Reviewer).

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

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


From prr at openjdk.java.net  Fri Jan  7 23:58:27 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 7 Jan 2022 23:58:27 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <O8pZwP3uwx-53FcNJQZvgNPdCaQfNvtHmshMprmrA80=.70fd5f39-be22-4398-8526-4a1b69154a38@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

@TejeshR13 you need to move the CSR to "final".

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

Marked as reviewed by prr (Reviewer).

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


From shurailine at openjdk.java.net  Sat Jan  8 00:50:59 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Sat, 8 Jan 2022 00:50:59 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing accessibility
Message-ID: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>

JDK-8279641: Create manual JTReg tests for Swing accessibility

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

Commit messages:
 - JDK-8279641: Create manual JTReg tests for Swing accessibility

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

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


From shurailine at openjdk.java.net  Sat Jan  8 00:55:26 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Sat, 8 Jan 2022 00:55:26 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
Message-ID: <TfUXuXMgdCcXtCkjmPMwUYmjCbXLTX6Uq6vCZguxiRk=.05c09442-e307-4d8d-b005-3c2fb7abb53f@github.com>

On Sat, 8 Jan 2022 00:42:18 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Tests are based on SwingSet2 application. 
> Test instructions are loaded from HTML files. 
> 
> See readme for more info.

@prrace Can you take a look?

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

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


From serb at openjdk.java.net  Sat Jan  8 01:05:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 8 Jan 2022 01:05:33 GMT
Subject: Integrated: 8279337: The MToolkit is still referenced in a few places
In-Reply-To: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
References: <heEyKqD8sBvioy4iVKHSq1u2IXq89AuPGfJijzM_8_s=.7561bce4-dbd0-4f78-9118-64369066fd69@github.com>
Message-ID: <PIP4-iCxIcf9zMELqe_Fa9zrwJj0f00sn46Bxservjo=.ab6321a0-864c-46dd-a320-447e98f90631@github.com>

On Thu, 30 Dec 2021 06:33:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The MToolkit (motif toolkit) was removed in jdk7, but it is still referenced in a few places.

This pull request has now been integrated.

Changeset: f203723f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f203723fc72c5d92c8745d4c595f360a9b50c512
Stats:     117 lines in 18 files changed: 5 ins; 57 del; 55 mod

8279337: The MToolkit is still referenced in a few places

Reviewed-by: prr

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

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


From serb at openjdk.java.net  Sat Jan  8 01:07:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 8 Jan 2022 01:07:27 GMT
Subject: Integrated: 8225122: Test AncestorResized.java fails when Windows
 desktop is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <J68omLC5Qr_vIadtAU6NaVpb-BrLPjI-vk87uC-pwnI=.0102ea09-5b4b-4a9c-975b-b31b1e8ac3e9@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

This pull request has now been integrated.

Changeset: 77757ba9
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77757ba974239b558e29c7adc551dfa04b9baa48
Stats:     206 lines in 1 file changed: 5 ins; 178 del; 23 mod

8225122: Test AncestorResized.java fails when Windows desktop is scaled.

Reviewed-by: kizune, aivanov

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

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


From kizune at openjdk.java.net  Sun Jan  9 17:30:29 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 9 Jan 2022 17:30:29 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <ITRoVNqI2CR13J2FGq4p2mTjg65PCdCKzpsADwjoyxg=.b76f6996-1c20-448f-8498-17ee8d33f7a4@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Marked as reviewed by kizune (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Mon Jan 10 05:33:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 10 Jan 2022 05:33:01 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module
Message-ID: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>

The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

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

Commit messages:
 - Fix
 - 8278254: Cleanup doclint warnings in java.desktop module

Changes: https://git.openjdk.java.net/jdk/pull/7004/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278254
  Stats: 258 lines in 19 files changed: 192 ins; 19 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004

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


From duke at openjdk.java.net  Mon Jan 10 11:06:08 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 11:06:08 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to NullPointerException
 when creating DataPusher
Message-ID: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>

There is possible NPE, when trying to play AudioClip

import java.applet.AudioClip;
import java.io.IOException;
import java.net.URL;


public class AudioNpe {
    public static void main(String[] args) throws IOException, InterruptedException {
        URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
        AudioClip content = (AudioClip)url.getContent();
        content.play();

        Thread.sleep(10000L);
    }
}


	  at java.lang.Thread.<init>(Thread.java:393)
	  at java.lang.Thread.<init>(Thread.java:760)
	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
	  - locked <0x955> (a com.sun.media.sound.DataPusher)
	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
	  at main.java.AudioNpe.main(AudioNpe.java:12)


It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.

After fix - audio clip plays without problems.

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

Commit messages:
 - [PATCH] Avoid NPE when creating a Thread without name
 - [PATCH] Avoid NPE when creating a Thread without name
 - [PATCH] Avoid NPE when creating a Thread without name

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

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


From serb at openjdk.java.net  Mon Jan 10 11:06:09 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 10 Jan 2022 11:06:09 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <aYviuMgsurADRid5Tws82FDeJFHP5fiHkv2ex8jSz30=.f32e0b93-f4af-4ae3-9322-0c3076728ba2@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

As a test, you can use the logic similar to this one: https://github.com/openjdk/jdk/blob/bd92674be563ad291990216b7cdf061c498f5dd3/test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java#L50
Just the file should be big enough (>1MB) to provoke the usage of DataPusher instead of "in memory clip".

@turbanoff do you plan to update the PR?

src/java.desktop/share/classes/com/sun/media/sound/JSSecurityManager.java line 115:

> 113:                                final boolean doStart)
> 114:     {
> 115:         String name = (threadName != null) ? threadName : "JSSM Thread";

Probably it will be better to leave this check as is, and just use the "name" var as a parameter to the new Thread, so it will prevent any similar issues in the future.

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

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


From duke at openjdk.java.net  Mon Jan 10 11:06:10 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 11:06:10 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <jGe4z80uc2JnGco1vUm8ljQnWBPqODaVE4NW79a--o4=.39e4c9f4-1bec-4891-93c9-7b35fc3ea343@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

Yes. Hope to update it this week.

Test added

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

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


From duke at openjdk.java.net  Mon Jan 10 11:06:12 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 11:06:12 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <aYviuMgsurADRid5Tws82FDeJFHP5fiHkv2ex8jSz30=.f32e0b93-f4af-4ae3-9322-0c3076728ba2@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
 <aYviuMgsurADRid5Tws82FDeJFHP5fiHkv2ex8jSz30=.f32e0b93-f4af-4ae3-9322-0c3076728ba2@github.com>
Message-ID: <F-Cz2Fc6SovZn1ckrIackSUv2fwbu_EPWzIOTYIUVfA=.dc1f0b97-edf9-4b64-b405-c3d328edd475@github.com>

On Tue, 16 Nov 2021 02:46:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There is possible NPE, when trying to play AudioClip
>> 
>> import java.applet.AudioClip;
>> import java.io.IOException;
>> import java.net.URL;
>> 
>> 
>> public class AudioNpe {
>>     public static void main(String[] args) throws IOException, InterruptedException {
>>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>>         AudioClip content = (AudioClip)url.getContent();
>>         content.play();
>> 
>>         Thread.sleep(10000L);
>>     }
>> }
>> 
>> 
>> 	  at java.lang.Thread.<init>(Thread.java:393)
>> 	  at java.lang.Thread.<init>(Thread.java:760)
>> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
>> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
>> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
>> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
>> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
>> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
>> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
>> 
>> 
>> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
>> 
>> After fix - audio clip plays without problems.
>
> src/java.desktop/share/classes/com/sun/media/sound/JSSecurityManager.java line 115:
> 
>> 113:                                final boolean doStart)
>> 114:     {
>> 115:         String name = (threadName != null) ? threadName : "JSSM Thread";
> 
> Probably it will be better to leave this check as is, and just use the "name" var as a parameter to the new Thread, so it will prevent any similar issues in the future.

It's a good practice to always set meaningful thread name. I think this package-private API is not supposed to be widely used. And fact that it was unnoticed for long time, gives very small chance that this method will be used in future code.
I would like to remove such _redundant_ code.

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

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


From duke at openjdk.java.net  Mon Jan 10 16:14:34 2022
From: duke at openjdk.java.net (duke)
Date: Mon, 10 Jan 2022 16:14:34 GMT
Subject: Withdrawn: 8233568: [TESTBUG] AWT event tests failing on MacOS
In-Reply-To: <wuww34-8VarDB4XRQ0sUI17MFpOyWa4DKOZSRckNcqo=.a72bed71-3776-4eab-8eca-e029bde09ed0@github.com>
References: <wuww34-8VarDB4XRQ0sUI17MFpOyWa4DKOZSRckNcqo=.a72bed71-3776-4eab-8eca-e029bde09ed0@github.com>
Message-ID: <AO00OWNpj_EBWqFo5BXfxr0T_p7fIurtDn_EnWD3IH8=.bd001ed3-9da9-4a30-8d5e-36b7803151be@github.com>

On Thu, 21 Oct 2021 15:47:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Tests passing on macos, so removing from ProblemList

This pull request has been closed without being integrated.

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

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


From mdoerr at openjdk.java.net  Mon Jan 10 16:40:29 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 10 Jan 2022 16:40:29 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15
In-Reply-To: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
Message-ID: <X39Er1akeQFZqOYU3OUwffgrxFGFfPQOwXsey246AGE=.c7d356af-9b69-44c5-9bb3-63e3030d1908@github.com>

On Tue, 4 Jan 2022 14:14:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this adjustment for recent SUSE Linux 15.
> The font coding on UNIX, see setOsNameAndVersion in files 
> 
> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
> 
> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
> 
> Example content of /etc/os-release
> NAME="SLES"
> VERSION="12-SP2"
> VERSION_ID="12.2"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
> 
> There the name and version information is stored (NAME=... , VERSION_ID=...).
> 
> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
> 
> Thanks, Matthias

Changes requested by mdoerr (Reviewer).

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 298:

> 296:     }
> 297: 
> 298:     private String getOsinfo(String s) {

Maybe call it `extractOsInfo`?

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 346:

> 344:                 }
> 345:                 osName = props.getProperty("NAME");
> 346:                 osVersion =  props.getProperty("VERSION_ID");

Extra whitespace.

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

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


From achung at openjdk.java.net  Mon Jan 10 16:59:28 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 10 Jan 2022 16:59:28 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v12]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge branch 'master' of github.com:alisenchung/jdk into 8190264
 - updated test
 - added check for other L&Fs, added newline to test
 - removed todo comment
 - finished test
 - fixed test 2
 - fixed test
 - need to fix comparison of BufferedImages
 - removed robot mouse moves, use pixel colors to check
 - removed manual tag
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/fd0217b8...ee57b8ac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/0a6283bd..ee57b8ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=10-11

  Stats: 965758 lines in 3134 files changed: 508319 ins; 438352 del; 19087 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6374/head:pull/6374

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


From achung at openjdk.java.net  Mon Jan 10 16:59:28 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 10 Jan 2022 16:59:28 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
 <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>
 <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
Message-ID: <6M13T9APthNcWbQhuZHuU--3d922PxM_oP_K6esIc3E=.db1c7aff-44aa-4de6-96e0-5ba8089e8f5d@github.com>

On Fri, 7 Jan 2022 18:35:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.
>
>> The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.
> 
> I decided to go ahead and experimented with the test. [My latest version](https://github.com/aivanov-jdk/jdk/blob/7ab9cdae8151dd71c60d752991c3d44dc2d0f76e/test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java) is available on GitHub. It should work in headless environment. (I noticed that the test doesn't have `@key headful` where it must have been there.) I added saving the images captured if the test fails, which should help in analyzing the failure.
> 
> This version of the test fails for me on builds without the fix and passes on the build with the fix included. @alisenchung, you can cherry-pick the changes from my branch into yours.
> 
> Probably it's enough to capture only the second image and then check for the color of the border.

I updated the test using @aivanov-jdk final version of the test, it should fail before the fix and pass after the fix. @mrserb @azuev-java could you take a look?

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

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


From aivanov at openjdk.java.net  Mon Jan 10 18:47:31 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 10 Jan 2022 18:47:31 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v11]
In-Reply-To: <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <dAemHDpdHNxOxAy6Ijzg6iB0ihrifZV24riNwh0YXjU=.b83b2e48-a907-49ea-b204-014efb2e82a7@github.com>
 <04FiOi8uNMsR3A2t3ALV1ioUpoKO-X4kxgBh7vXLCbs=.2c633dfb-842f-42be-a44d-bb7b313af265@github.com>
 <nHlJw7zqL4J4F-BovWO6jVemttxb-bzHTHWGQIjVZTQ=.13052014-036c-4817-9351-1b3f444f843a@github.com>
Message-ID: <3xDUJ2ez5s6XdrCDgoOGA50Puqbbm-QdRn9GaGoqPFE=.84c4effe-dd87-462d-ac10-7c17c546b180@github.com>

On Fri, 7 Jan 2022 18:35:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.
>
>> The test does not fail for me on the build without the fix. It's confirmed by the image where scroll bar thumb is painted in the border.
> 
> I decided to go ahead and experimented with the test. [My latest version](https://github.com/aivanov-jdk/jdk/blob/7ab9cdae8151dd71c60d752991c3d44dc2d0f76e/test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java) is available on GitHub. It should work in headless environment. (I noticed that the test doesn't have `@key headful` where it must have been there.) I added saving the images captured if the test fails, which should help in analyzing the failure.
> 
> This version of the test fails for me on builds without the fix and passes on the build with the fix included. @alisenchung, you can cherry-pick the changes from my branch into yours.
> 
> Probably it's enough to capture only the second image and then check for the color of the border.

> I updated the test using @aivanov-jdk final version of the test, it should fail before the fix and pass after the fix.

Could you please issue `/contributor add aivanov` command? This will record that I contributed code to this PR.

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

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


From serb at openjdk.java.net  Tue Jan 11 05:44:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:44:26 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <uuK5svog9pn3o50Ovi9iFnGMsuwzFAuCPoPSHMO2n50=.88d07c22-1da4-4545-a105-178eb14d7e62@github.com>

On Mon, 10 Jan 2022 05:25:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 65:

> 63: 
> 64:     /**
> 65:      * Returns the imaga capabilities of the front buffer

Please add a dot after the first sentence, it is used as a summary doc for the method.
Why the text about "displayed" buffer is removed? is it some special "term" like "intermediate" below?

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 134:

> 132: 
> 133:     /**
> 134:      * Returns whether or not

I am not sure that preserving such a format style is a good thing.

src/java.desktop/share/classes/java/awt/Component.java line 4697:

> 4695: 
> 4696:     /**
> 4697:      * Checks whether or not paint messages received from the operating system

In the change above the "Returns whether or not" text is used. It is better to use the same new text, or just use the old one.

src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:

> 651:     /* For European keyboards */
> 652:     /**
> 653:      * Constant for the DEAD_GRAVE function key.

I do not know, are all the keys here actually "function keys"?

src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 150:

> 148:     /************************************************************************/
> 149: 
> 150:     /**

This will add many statements to the specification which could be verified by the TCK. DO we really want to say all of that? Especially about serialization. Same question for other changes below.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1686:

> 1684: 
> 1685:         /**
> 1686:          * Returns HTMLDocument of given <code>JEditorPane</code>.

Should we wrap the HTMLDocument by the <code>?

src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 213:

> 211: 
> 212:     /**
> 213:      * Return the line number of the line currently being parsed.

In some other places above the "Returns xxx" was used.

src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:

> 148: 
> 149:     /**
> 150:      * Start UndoableEdit.

What does it mean? Is it clear enough for the class which "managing <code>UndoableEdit</code> listeners"?

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

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


From serb at openjdk.java.net  Tue Jan 11 05:46:23 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:46:23 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
Message-ID: <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>

On Sat, 8 Jan 2022 00:42:18 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Tests are based on SwingSet2 application. 
> Test instructions are loaded from HTML files. 
> 
> See readme for more info.

An initial question, which look and feel are we expected to test? Do we need to cover the default one, or it is up to someone to pass the correct L&F?

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

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


From serb at openjdk.java.net  Tue Jan 11 05:47:19 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:47:19 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <JHbEGklDVSrTfMO6t6UJWCIeEO-hr3EWCLhg0uleuJs=.f686e2bc-46af-4dff-9c5c-bfd8e7b91287@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

If it is not a problem now can we close this PR?

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

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


From serb at openjdk.java.net  Tue Jan 11 05:48:29 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:48:29 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <nDgccXF9b0eH0s0RlQ6Enkf5MEqsVxW7FaMDHPG5DYQ=.ad23b607-ac88-455e-9acf-85c8b5fb047f@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Tue Jan 11 05:51:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:51:40 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v12]
In-Reply-To: <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
Message-ID: <jqVErex11Ho7YCM2F57TGMHwObbzEYT1Zhrz-TOI8X0=.879599cd-899e-4f7d-a483-23d8c54e3669@github.com>

On Mon, 10 Jan 2022 16:59:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:alisenchung/jdk into 8190264
>  - updated test
>  - added check for other L&Fs, added newline to test
>  - removed todo comment
>  - finished test
>  - fixed test 2
>  - fixed test
>  - need to fix comparison of BufferedImages
>  - removed robot mouse moves, use pixel colors to check
>  - removed manual tag
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/0dc86ffd...ee57b8ac

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Tue Jan 11 05:54:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:54:27 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <pMOTZI5A2kISIaJH8EgDPCWjvfjevZln6XVAsb5zSRo=.773d5f19-7025-4d54-8d06-b3b38ef27753@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Just to clarify, according to your investigation the "CFStringNormalize" is not needed to use for the file names?

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

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


From psadhukhan at openjdk.java.net  Tue Jan 11 06:13:23 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 11 Jan 2022 06:13:23 GMT
Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java
 fails in macos12
In-Reply-To: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
References: <NIiUwv0S9Luwx-Cr3f59GSllTUVRsa96rRxonSLk0Sk=.6e3cd774-13fd-47ff-badf-0655a4d1ad99@github.com>
Message-ID: <AVGu4x3hT6Lro0ptE7zS9qpmJHv9aToO7Y_0iuLYl0k=.f2d6d25c-1076-412f-85db-c67c082b12f4@github.com>

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

it is a problem in 12.0.1

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

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


From prr at openjdk.java.net  Tue Jan 11 07:08:26 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 11 Jan 2022 07:08:26 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
 <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>
Message-ID: <sdQwOU6v7xIyzViwS3F6i_tHRtpTGC1pXlV5DKJkXj0=.06a8253d-d740-42ff-bce7-c22fc550ac09@github.com>

On Tue, 11 Jan 2022 05:43:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> An initial question, which look and feel are we expected to test? Do we need to cover the default one, or it is up to someone to pass the correct L&F?

Need in what context ? Who is "we"  ? 
Test which ever L&Fs your distro wants to certify as accessible. It isn't like a TCK test.
It is optional as far as JDK is concerned but maybe not for some hypothetical consumer of your release.

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

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


From dbatrak at openjdk.java.net  Tue Jan 11 08:31:31 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Tue, 11 Jan 2022 08:31:31 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <pMOTZI5A2kISIaJH8EgDPCWjvfjevZln6XVAsb5zSRo=.773d5f19-7025-4d54-8d06-b3b38ef27753@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
 <pMOTZI5A2kISIaJH8EgDPCWjvfjevZln6XVAsb5zSRo=.773d5f19-7025-4d54-8d06-b3b38ef27753@github.com>
Message-ID: <7Qs-sy_j1lSkAhxwDmYgCZyeMp2b74RBItBRZkKyPcs=.462a71f0-88f0-4f27-92db-2ddc8120ea00@github.com>

On Tue, 11 Jan 2022 05:51:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just to clarify, according to your investigation the "CFStringNormalize" is not needed to use for the file names?

I didn't state that. AFAIU, in most typical cases, file names come from OS in NFD form, and `CFStringNormalize` does convert them to NFC form, so it's not a no-op. Whether that conversion is actually needed - I don't know, so I wouldn't touch it without a reason.

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

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


From mbaesken at openjdk.java.net  Tue Jan 11 08:35:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 11 Jan 2022 08:35:58 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15 [v2]
In-Reply-To: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
Message-ID: <YUa7r71R4I46apBK-3GxEa7SC9goKQNPPRU3cIY5-Ag=.4e7f8edb-6939-40b5-a2ee-4d968d5290ee@github.com>

> Hello, please review this adjustment for recent SUSE Linux 15.
> The font coding on UNIX, see setOsNameAndVersion in files 
> 
> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
> 
> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
> 
> Example content of /etc/os-release
> NAME="SLES"
> VERSION="12-SP2"
> VERSION_ID="12.2"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
> 
> There the name and version information is stored (NAME=... , VERSION_ID=...).
> 
> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
> 
> Thanks, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  suggestions by mdoerr

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6956/files
  - new: https://git.openjdk.java.net/jdk/pull/6956/files/b7822bd7..45e2fad2

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

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

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


From mbaesken at openjdk.java.net  Tue Jan 11 08:36:00 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 11 Jan 2022 08:36:00 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15
In-Reply-To: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
Message-ID: <ImKgVzaKXB9_tkf7VTW9aFQPma_EHcZJyqTXyP_UMSA=.070513c4-aac8-4151-ae16-38cb6547031c@github.com>

On Tue, 4 Jan 2022 14:14:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this adjustment for recent SUSE Linux 15.
> The font coding on UNIX, see setOsNameAndVersion in files 
> 
> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
> 
> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
> 
> Example content of /etc/os-release
> NAME="SLES"
> VERSION="12-SP2"
> VERSION_ID="12.2"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
> 
> There the name and version information is stored (NAME=... , VERSION_ID=...).
> 
> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
> 
> Thanks, Matthias

Hi Martin, thanks for your suggestions. I renamed the function and removed the whitespace.
Best regards, Matthias

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

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


From mbaesken at openjdk.java.net  Tue Jan 11 12:13:49 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 11 Jan 2022 12:13:49 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15 [v3]
In-Reply-To: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
Message-ID: <t3V3wIAzV7OwpfVBprYtfmP9--WOBrD1OinZd1r8ziU=.01dc4643-d173-449b-8fad-4eb2d31a7f34@github.com>

> Hello, please review this adjustment for recent SUSE Linux 15.
> The font coding on UNIX, see setOsNameAndVersion in files 
> 
> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
> 
> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
> 
> Example content of /etc/os-release
> NAME="SLES"
> VERSION="12-SP2"
> VERSION_ID="12.2"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
> 
> There the name and version information is stored (NAME=... , VERSION_ID=...).
> 
> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
> 
> Thanks, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  suggestions by mdoerr for MFontConfiguration.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6956/files
  - new: https://git.openjdk.java.net/jdk/pull/6956/files/45e2fad2..a385a1c3

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

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

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


From mbaesken at openjdk.java.net  Tue Jan 11 12:13:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 11 Jan 2022 12:13:53 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15 [v2]
In-Reply-To: <YUa7r71R4I46apBK-3GxEa7SC9goKQNPPRU3cIY5-Ag=.4e7f8edb-6939-40b5-a2ee-4d968d5290ee@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
 <YUa7r71R4I46apBK-3GxEa7SC9goKQNPPRU3cIY5-Ag=.4e7f8edb-6939-40b5-a2ee-4d968d5290ee@github.com>
Message-ID: <P7xwvik9dCLJho5WhUxdPFjQvfUMjGleQeGbiTeibXY=.18c55a2b-efe4-4ca1-b6a2-af9cd14cfd9c@github.com>

On Tue, 11 Jan 2022 08:35:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this adjustment for recent SUSE Linux 15.
>> The font coding on UNIX, see setOsNameAndVersion in files 
>> 
>> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
>> 
>> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
>> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
>> 
>> Example content of /etc/os-release
>> NAME="SLES"
>> VERSION="12-SP2"
>> VERSION_ID="12.2"
>> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
>> 
>> There the name and version information is stored (NAME=... , VERSION_ID=...).
>> 
>> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestions by mdoerr

I adjusted MFontConfiguration.java as well.
Best regards, Matthias

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

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


From aivanov at openjdk.java.net  Tue Jan 11 15:31:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 15:31:46 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts -> Constructs
Message-ID: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>

Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.

I also organised the imports which replaced all wildcard imports with specific class imports.

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

Commit messages:
 - 8279795: Fix typo in BasicFileChooserUI: Constucts -> Constructs

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

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


From aivanov at openjdk.java.net  Tue Jan 11 15:37:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 15:37:40 GMT
Subject: RFR: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent
Message-ID: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>

A number of methods in BasicTabbedPaneUI uses the imperative form of the verb in the documentation instead of the third-person form which describes what the method does.

For consistency, I updated such descriptions to use the third-person form of the verb.

I fixed a couple of typos as well.

I also expanded all the wildcard imports into the specific ones.

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

Commit messages:
 - Revert the change for assureRectsCreated: it'll be updated in a follow-up issue
 - 8279798: Javadoc for BasicTabbedPaneUI is inconsistent

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

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


From aivanov at openjdk.java.net  Tue Jan 11 15:42:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 15:42:51 GMT
Subject: RFR: 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical
 scroll bar
Message-ID: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>

Fixed the typo in the layout methods: ?Laysouts a?? ? ?Lays out a??.

The doc for `layoutHScrollbar` incorrectly referred to _vertical_ scroll bar rather than horizontal one.


I also expanded the wildcard imports.

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

Commit messages:
 - 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical scroll bar

Changes: https://git.openjdk.java.net/jdk/pull/7032/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7032&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279794
  Stats: 49 lines in 1 file changed: 37 ins; 9 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7032.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7032/head:pull/7032

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


From mdoerr at openjdk.java.net  Tue Jan 11 15:53:34 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 11 Jan 2022 15:53:34 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15 [v3]
In-Reply-To: <t3V3wIAzV7OwpfVBprYtfmP9--WOBrD1OinZd1r8ziU=.01dc4643-d173-449b-8fad-4eb2d31a7f34@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
 <t3V3wIAzV7OwpfVBprYtfmP9--WOBrD1OinZd1r8ziU=.01dc4643-d173-449b-8fad-4eb2d31a7f34@github.com>
Message-ID: <veQb4N3Su5e0RhxJ4XgRhgbLBdhL9UGG-zVGug7JBio=.735d744d-80cc-4333-845b-023be2b4d342@github.com>

On Tue, 11 Jan 2022 12:13:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this adjustment for recent SUSE Linux 15.
>> The font coding on UNIX, see setOsNameAndVersion in files 
>> 
>> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
>> 
>> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
>> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
>> 
>> Example content of /etc/os-release
>> NAME="SLES"
>> VERSION="12-SP2"
>> VERSION_ID="12.2"
>> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
>> 
>> There the name and version information is stored (NAME=... , VERSION_ID=...).
>> 
>> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestions by mdoerr for MFontConfiguration.java

Thanks for fixing it. I don't know if "JDK-" prefix is allowed in the bug title. Otherwise, looks good.,

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

Marked as reviewed by mdoerr (Reviewer).

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


From aivanov at openjdk.java.net  Tue Jan 11 15:57:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 15:57:39 GMT
Subject: RFR: JDK-8279861: Clarify 'rect' parameters and description of
 paintTabBorder method in BasicTabbedPaneUI
Message-ID: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>

The protected methods `paintTab` and `paintFocusIndicator` accept the `rect` parameter which is documented as _?rectangles?_. I suggest updating this description to a more descriptive: _?the tab rectangles?_ as the array contains the coordinates of the tabs.

Similarly, the documentation for `assureRectsCreated` method could be updated to clarify which rectangles are created.

The documentation for `paintTabBorder` is inconsistent with other paint methods, it has no ending punctuation. I updated it to be consistent.

I split out these changes from [JDK-8279798](https://bugs.openjdk.java.net/browse/JDK-8279798) and #7031 because this issue will likely require a CSR.

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

Commit messages:
 - JDK-8279861: Clarify 'rect' parameters and description of paintTabBorder method in BasicTabbedPaneUI

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

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


From shurailine at openjdk.java.net  Tue Jan 11 19:07:24 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Tue, 11 Jan 2022 19:07:24 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <sdQwOU6v7xIyzViwS3F6i_tHRtpTGC1pXlV5DKJkXj0=.06a8253d-d740-42ff-bce7-c22fc550ac09@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
 <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>
 <sdQwOU6v7xIyzViwS3F6i_tHRtpTGC1pXlV5DKJkXj0=.06a8253d-d740-42ff-bce7-c22fc550ac09@github.com>
Message-ID: <aYdRQ4Vpp9ssx6Y7IM-cahcAk8gd1aaUzWjsglsE6bg=.61f769ee-b195-4e49-b1b3-d2c379bf9899@github.com>

On Tue, 11 Jan 2022 07:04:51 GMT, Phil Race <prr at openjdk.org> wrote:

> An initial question, which look and feel are we expected to test? Do we need to cover the default one, or it is up to someone to pass the correct L&F?

This current implementation does not do anything to support different LAFs.

A test executor can still specify the LAF through -vmoption:"-Dswing.defaultlaf=..." JTReg option.

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

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


From achung at openjdk.java.net  Tue Jan 11 19:34:36 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 11 Jan 2022 19:34:36 GMT
Subject: RFR: 8279879: [TESTBUG] [macos] ActionEvent triggered when
 right-clicking TrayIcon
Message-ID: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>

fixed test bug, removed extra ActionEvent from TrayIcon

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

Commit messages:
 - 8279879: [TESTBUG] [macos] ActionEvent triggered when right-clicking TrayIcon

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

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


From achung at openjdk.java.net  Tue Jan 11 19:34:36 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 11 Jan 2022 19:34:36 GMT
Subject: RFR: 8279879: [TESTBUG] [macos] ActionEvent triggered when
 right-clicking TrayIcon
In-Reply-To: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
Message-ID: <zew-8-IA4-iUqBGFn5eRXtlXiVOf_IARK_WGP0IavTY=.958b3cd3-af54-4d45-8661-96b9e17868f5@github.com>

On Tue, 11 Jan 2022 19:29:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed test bug, removed extra ActionEvent from TrayIcon

Hi @prrace, please review

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

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


From aivanov at openjdk.java.net  Tue Jan 11 19:44:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 19:44:35 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v12]
In-Reply-To: <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
Message-ID: <Xon4M_G1_6SpX-7-mdhKf3woc6Gq1MS6LNC3f_wyQJo=.64403082-7dce-4d0f-9632-5c10a31b476f@github.com>

On Mon, 10 Jan 2022 16:59:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:alisenchung/jdk into 8190264
>  - updated test
>  - added check for other L&Fs, added newline to test
>  - removed todo comment
>  - finished test
>  - fixed test 2
>  - fixed test
>  - need to fix comparison of BufferedImages
>  - removed robot mouse moves, use pixel colors to check
>  - removed manual tag
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/ec72e278...ee57b8ac

Have we resolved all the questions already?

The copyright year for AquaScrollBarUI.java should be updated to the current year as well as for the test.

The question about *vertical insets* remains unanswered.

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

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


From aivanov at openjdk.java.net  Tue Jan 11 19:47:49 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 11 Jan 2022 19:47:49 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v12]
In-Reply-To: <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <RQa4syjLiXwGC4oyR1xG6a-2KGnbg4jrB22AzYz2254=.405dd855-d8b0-4183-a330-ffc017f01e92@github.com>
Message-ID: <HmBG4Nm9b-3duj4RK7ofkS4zBoT5sIUi87AR_6pX3d8=.97c01472-e32a-43f3-84b2-1dfe21d76a87@github.com>

On Mon, 10 Jan 2022 16:59:28 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:alisenchung/jdk into 8190264
>  - updated test
>  - added check for other L&Fs, added newline to test
>  - removed todo comment
>  - finished test
>  - fixed test 2
>  - fixed test
>  - need to fix comparison of BufferedImages
>  - removed robot mouse moves, use pixel colors to check
>  - removed manual tag
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/f166bd7b...ee57b8ac

Please update the copyright year in both files to include 2022.

I suggest expanding all the wildcard imports for AquaScrollBarUI.java, which is usually done.

And most importantly: the new code handle horizontal insets. What about the *vertical insets?* It looks a vertical scroll bar has the same issue if there's vertical border.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Probably, the copyright year should now contain 2022 too:
Suggestion:

 * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

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

Changes requested by aivanov (Reviewer).

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


From vdyakov at openjdk.java.net  Tue Jan 11 19:51:20 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 11 Jan 2022 19:51:20 GMT
Subject: RFR: 8279879: [TESTBUG] [macos] ActionEvent triggered when
 right-clicking TrayIcon
In-Reply-To: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
Message-ID: <bHQiyjqm0_-XQ3TXrmrIkFoRJSAyLTohlecAX9Fx5UE=.c49e0dbf-f2a4-4d1b-955d-4cb75afa56b3@github.com>

On Tue, 11 Jan 2022 19:29:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed test bug, removed extra ActionEvent from TrayIcon

@azvegint please review

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

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


From achung at openjdk.java.net  Tue Jan 11 20:58:05 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 11 Jan 2022 20:58:05 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v13]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <d31ehkqdQ8BShQ6_7M9-LlfAI6458G1LL-bkZ4PnBZ8=.0ef37c2c-61ea-4a7c-a977-b82cf1b960d6@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright dates, updated test and fix to also check vertical borders

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/ee57b8ac..9d2f71ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=11-12

  Stats: 75 lines in 2 files changed: 57 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6374/head:pull/6374

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


From serb at openjdk.java.net  Wed Jan 12 02:35:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 12 Jan 2022 02:35:27 GMT
Subject: RFR: 8279879: [TESTBUG] [macos] ActionEvent triggered when
 right-clicking TrayIcon
In-Reply-To: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
Message-ID: <GOwq4x_drzYXZjYTdDGC_T1zKsnntrmjj5Ig1Dn8l9s=.8fd9590c-849b-41dd-9a02-5ae166fea209@github.com>

On Tue, 11 Jan 2022 19:29:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed test bug, removed extra ActionEvent from TrayIcon

Why it is marked as a test bug if the JDK code changed?

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

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


From serb at openjdk.java.net  Wed Jan 12 02:43:21 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 12 Jan 2022 02:43:21 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs
In-Reply-To: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
Message-ID: <U5jIa9QlCxqulEKEV3b7iXA8umLewioTYcomqKlAjOQ=.049c2434-5a78-4434-a24f-a65297726037@github.com>

On Tue, 11 Jan 2022 15:25:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
> 
> I also organised the imports which replaced all wildcard imports with specific class imports.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 73:

> 71: import javax.swing.plaf.FileChooserUI;
> 72: import javax.swing.plaf.UIResource;
> 73: 

I see that you added a line between different top packages, I use the same style, but then it will make sense to do the same for java -> javax above.

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

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


From serb at openjdk.java.net  Wed Jan 12 03:06:21 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 12 Jan 2022 03:06:21 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <aYdRQ4Vpp9ssx6Y7IM-cahcAk8gd1aaUzWjsglsE6bg=.61f769ee-b195-4e49-b1b3-d2c379bf9899@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
 <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>
 <sdQwOU6v7xIyzViwS3F6i_tHRtpTGC1pXlV5DKJkXj0=.06a8253d-d740-42ff-bce7-c22fc550ac09@github.com>
 <aYdRQ4Vpp9ssx6Y7IM-cahcAk8gd1aaUzWjsglsE6bg=.61f769ee-b195-4e49-b1b3-d2c379bf9899@github.com>
Message-ID: <4edkc2WK9jhpncIu4sAMjvSv8D363xzfTW8DwZD5RE4=.1d3d72ac-ee06-47da-8018-7670f98ca5a4@github.com>

On Tue, 11 Jan 2022 19:04:42 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> This current implementation does not do anything to support different LAFs.
Even if it is do nothing for the L&F by itself it is expected that these test passed on the

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

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


From serb at openjdk.java.net  Wed Jan 12 03:29:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 12 Jan 2022 03:29:26 GMT
Subject: RFR: 8279879: [TESTBUG] [macos] ActionEvent triggered when
 right-clicking TrayIcon
In-Reply-To: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
Message-ID: <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>

On Tue, 11 Jan 2022 19:29:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed test bug, removed extra ActionEvent from TrayIcon

test/jdk/java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.java line 113:

> 111:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
> 112:         robot.delay(1000);
> 113:         robot.waitForIdle();

The purpose of the test is to check the action event while the balloon is visible after the left click (the balloon is shown on the mouse click event), so removing the left click does not seem correct, no?

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

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


From serb at openjdk.java.net  Wed Jan 12 03:29:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 12 Jan 2022 03:29:27 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <c_MvFiU6rjz9tynb11s71emGKrORYamJmRZvdImDv38=.b01d4afe-6908-4816-90d7-3fc7e8106721@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Marked as reviewed by serb (Reviewer).

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

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


From duke at openjdk.java.net  Wed Jan 12 05:30:25 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 12 Jan 2022 05:30:25 GMT
Subject: RFR: 6496103: isFileHidingEnabled return false by default [v3]
In-Reply-To: <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
 <hgUMCet8jzlF6nTqCeDTzq3XXMfM8R0jLaeONIYqkmI=.4fdfd154-55c7-4599-bf9b-6ac4626a509b@github.com>
Message-ID: <YwjTpZOvFEiS1GJpQe405NFP2_cPNpKiKOL-fGBKipc=.803f2780-0c50-4d83-9f87-f6bd3e51b831@github.com>

On Mon, 20 Dec 2021 06:54:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The default value of this property is derived from native platform. The same is updated in the documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6496103: isFileHidingEnabled return false by default

CSR is approved.

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

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


From duke at openjdk.java.net  Wed Jan 12 05:42:34 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 12 Jan 2022 05:42:34 GMT
Subject: Integrated: 6496103: isFileHidingEnabled return false by default
In-Reply-To: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
References: <_C3lDw9NYzxbZtUdu44cRMEHaa6NhTV6fJWB-ho59yo=.eeda6bb0-81b0-4f0d-9c3b-58fbaa1c433d@github.com>
Message-ID: <3bHaJBXAASf_GrQOuCPN3Zz1-Bh3ht74bhyzW3QRCks=.1ad6f3f0-4eb0-432e-9c63-07bd4943fce3@github.com>

On Thu, 9 Dec 2021 09:40:38 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> The default value of this property is derived from native platform. The same is updated in the documentation.

This pull request has now been integrated.

Changeset: 13bfb497
Author:    TejeshR13 <tejesh.r at oracle.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13bfb4972543d87677b693b7a1b82ffdbdb45e00
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

6496103: isFileHidingEnabled return false by default

Reviewed-by: serb, aivanov, prr

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

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


From myano at openjdk.java.net  Wed Jan 12 06:46:37 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 12 Jan 2022 06:46:37 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>
Message-ID: <_tfkXlWHqZpj83HYixIueY83_QWZ5imLv1tKPGNXk_Q=.bebee5ff-b0fd-429e-9509-a768956a131f@github.com>

On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> I'll check it, let me some time.

@mrserb Could you please commit this fix as a sponsor?

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

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


From myano at openjdk.java.net  Wed Jan 12 06:53:29 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 12 Jan 2022 06:53:29 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <oR0R_Nn0yww5pG-JC91BnS2Y9OHZJ6-n4p8Q3d6cwEE=.c5245ec8-9144-4f56-97ab-d8c94f7c3966@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb How long will it take to review this fix?

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

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


From myano at openjdk.java.net  Wed Jan 12 07:01:36 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 12 Jan 2022 07:01:36 GMT
Subject: Integrated: 8277463: JFileChooser with Metal L&F doesn't show
 non-canonical UNC path in - Look in
In-Reply-To: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
References: <uSw3NYRPNAWqigOS5ToIbZEa0W6Jktn5CNd74Pik08I=.588ac555-5cda-4630-8fd2-e2f5d1e31765@github.com>
Message-ID: <W-mLkjbce7xYLTgo1fiPQ0TAqm48uSLmgyJHwqWVOtw=.05ba1db1-a274-4c0a-ab6a-8ee5fca5e8d6@github.com>

On Fri, 10 Dec 2021 08:59:55 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I would like to fix the bug reported in JDK-8277463.
> 
> As reporter's investigation, ShellFolder.getNormalizedFile() returns incorrect value for non-canonical Windows UNC path. getNormalizedFile() is used for symbolic link path, but Windows environment does not handle symbolic link. And, getCanonicalFile() returns correct path for a directory link in Windows which is made with `mklink` command. So getNormalizedFile() should perform to return getCanonicalFile() like WindowsFileChooserUI.addItem() at Windows environment.

This pull request has now been integrated.

Changeset: 319d2303
Author:    Masanori Yano <myano at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/319d23033f4a814935f10885aef725c818b0baed
Stats:     126 lines in 2 files changed: 125 ins; 0 del; 1 mod

8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in

Reviewed-by: psadhukhan

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

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


From shurailine at openjdk.java.net  Wed Jan 12 15:41:22 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 12 Jan 2022 15:41:22 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <4edkc2WK9jhpncIu4sAMjvSv8D363xzfTW8DwZD5RE4=.1d3d72ac-ee06-47da-8018-7670f98ca5a4@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
 <DiI3h1L55HecrvhIAUHRnQeyhg_wuC4vF5pbQj2dsEU=.58572242-f859-4e6f-a4d5-eb8f854866b4@github.com>
 <sdQwOU6v7xIyzViwS3F6i_tHRtpTGC1pXlV5DKJkXj0=.06a8253d-d740-42ff-bce7-c22fc550ac09@github.com>
 <aYdRQ4Vpp9ssx6Y7IM-cahcAk8gd1aaUzWjsglsE6bg=.61f769ee-b195-4e49-b1b3-d2c379bf9899@github.com>
 <4edkc2WK9jhpncIu4sAMjvSv8D363xzfTW8DwZD5RE4=.1d3d72ac-ee06-47da-8018-7670f98ca5a4@github.com>
Message-ID: <AYaTKoMiMomXmdft8-i375h7NkVnlTKuUAzjbDRduO8=.7c6542aa-f3ff-4438-b95c-9b73994c26e4@github.com>

On Wed, 12 Jan 2022 03:03:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > This current implementation does not do anything to support different LAFs.
> 
> Even if the tests do nothing it is expected that these tests will pass on the default L&Fs like Aqua/Metal. If it is expected to pass on all L&F why not iterate over all installed L&F and prove that?

Changes suggested by this review only cover default LAF by default, unless LAF is specified explicitly. There may be improvements later which would suggest rotating LAFs, that would be a subject of a follow-up reviews.

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

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


From achung at openjdk.java.net  Wed Jan 12 16:56:24 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 12 Jan 2022 16:56:24 GMT
Subject: RFR: 8279879: [macos] ActionEvent triggered when right-clicking
 TrayIcon
In-Reply-To: <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
 <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>
Message-ID: <VNKJoFtKrKYFQT8e9wAbDkNdHgvkXQM_BTuSAeuuaIU=.ea50b53e-746e-410a-8390-c16f6a45377b@github.com>

On Wed, 12 Jan 2022 03:25:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> fixed test bug, removed extra ActionEvent from TrayIcon
>
> test/jdk/java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.java line 113:
> 
>> 111:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>> 112:         robot.delay(1000);
>> 113:         robot.waitForIdle();
> 
> The purpose of the test is to check the action event while the balloon is visible after the left click (the balloon is shown on the mouse click event), so removing the left click does not seem correct, no?

Oh, I misunderstood the test. Based on a previous version of this test that was failing I thought the issue was the ActionEvent firing on a TrayIcon right-click that also brought up the balloon message..

I have a few questions about the expected behavior of TrayIcon:
Should ActionEvent be triggered on a normal left-click? How about a normal right-click?
When should ActionEvent not be triggered? Not on right-click during a balloon message? What about left-click during a balloon message?

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

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


From achung at openjdk.java.net  Wed Jan 12 16:57:26 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 12 Jan 2022 16:57:26 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v13]
In-Reply-To: <d31ehkqdQ8BShQ6_7M9-LlfAI6458G1LL-bkZ4PnBZ8=.0ef37c2c-61ea-4a7c-a977-b82cf1b960d6@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <d31ehkqdQ8BShQ6_7M9-LlfAI6458G1LL-bkZ4PnBZ8=.0ef37c2c-61ea-4a7c-a977-b82cf1b960d6@github.com>
Message-ID: <Y0xMbOA7ZKHThbW9UD066DkGfzrqmAtozrhmZB2Sv4M=.37e5fe14-24c5-47eb-8894-00604abbdfa6@github.com>

On Tue, 11 Jan 2022 20:58:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright dates, updated test and fix to also check vertical borders

> Please update the copyright year in both files to include 2022.
> 
> I suggest expanding all the wildcard imports for AquaScrollBarUI.java, which is usually done.
> 
> And most importantly: the new code handle horizontal insets. What about the _vertical insets?_ It looks a vertical scroll bar has the same issue if there's vertical border.

The recent push should handle vertical insets.

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

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


From cushon at openjdk.java.net  Wed Jan 12 18:14:45 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 12 Jan 2022 18:14:45 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
Message-ID: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>

> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge master
 - Write serialized objects at test-time in BadSerializationTest
 - Merge branch 'master' into JDK-8277817
 - Revert WIP
 - Add a few more missing calls to LookAndFeel.uninstallColors
 - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
 - Add @since 19 to new methods
 - Add uninstallColorsAndFont
 - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

Changes: https://git.openjdk.java.net/jdk/pull/6603/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6603&range=09
  Stats: 50 lines in 8 files changed: 14 ins; 12 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6603/head:pull/6603

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


From cushon at openjdk.java.net  Wed Jan 12 18:14:46 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 12 Jan 2022 18:14:46 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]
In-Reply-To: <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <49gYRPX_QAzZcEsFovkzHbBn2I28lXo-3fYDHmYSUD0=.cf6525da-c24b-406f-ad90-2eabcbd840c3@github.com>
Message-ID: <3qgUX5DNFOFFsmxR9RMzE-vKLG-qn_0ZjnnZ0U3sXwA=.18bf3f5c-3c1e-4dae-bc32-432ebe0a03b8@github.com>

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

I have modified the test to create the serialized objects at test-time, instead of relying on checking in the serialized files.

> I wonder if it's possible to modify the value of the field using reflection via `setAccessible(true)`

Done: the test now creates valid objects, and then uses reflection to set the fields to `null` after the constructor has executed.

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

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


From azvegint at openjdk.java.net  Wed Jan 12 22:57:25 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 12 Jan 2022 22:57:25 GMT
Subject: RFR: 8279879: [macos] ActionEvent triggered when right-clicking
 TrayIcon
In-Reply-To: <VNKJoFtKrKYFQT8e9wAbDkNdHgvkXQM_BTuSAeuuaIU=.ea50b53e-746e-410a-8390-c16f6a45377b@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
 <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>
 <VNKJoFtKrKYFQT8e9wAbDkNdHgvkXQM_BTuSAeuuaIU=.ea50b53e-746e-410a-8390-c16f6a45377b@github.com>
Message-ID: <Rd3vbeISyDCnCumAMzK5f4Qc9kqsueLkEbaIyI-G7oE=.7aa3a3c1-5a68-4fc1-8e73-4f9e25b79977@github.com>

On Wed, 12 Jan 2022 16:53:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.java line 113:
>> 
>>> 111:         robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>>> 112:         robot.delay(1000);
>>> 113:         robot.waitForIdle();
>> 
>> The purpose of the test is to check the action event while the balloon is visible after the left click (the balloon is shown on the mouse click event), so removing the left click does not seem correct, no?
>
> Oh, I misunderstood the test. Based on a previous version of this test that was failing I thought the issue was the ActionEvent firing on a TrayIcon right-click that also brought up the balloon message..
> 
> I have a few questions about the expected behavior of TrayIcon:
> Should ActionEvent be triggered on a normal left-click? How about a normal right-click?
> When should ActionEvent not be triggered? Not on right-click during a balloon message? What about left-click during a balloon message?

It is platform dependent:
https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/share/classes/java/awt/TrayIcon.java#L565-L566
Current behavior of OpenJDK is:
* Linux sends it on left button click
* macOS send it on right button click.
* On Windows it can be triggered by a second mouse click on a tray icon(doesn't matter which mouse key is used), left mouse click on the balloon, or enter keypress on it.

https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L412-L457

[JDK-8195991](https://bugs.openjdk.java.net/browse/JDK-8195991) introduced this test, but its description does not conform with its code:

> Right clicking on TrayIcon shouldn't trigger ActionEvent when balloon is displayed.

Given the info above this will be true only for Linux, which does not trigger `ACTION_PERFORMED` on right mouse click. 

> int actionPerformedCount = -1;
...
if (actionPerformedCount > 0

So the test code expects to receive 0 or 1  `ACTION_PERFORMED` events. It allows the test to pass with our current implementation.



The original test was written along with a fix for Windows back in [2005](https://bugs.openjdk.java.net/browse/JDK-6271624). 

The Windows UI have changed since this time, so may be the expectation of not receiving of `ACTION_PERFORMED` is no longer valid.

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

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


From serb at openjdk.java.net  Thu Jan 13 02:26:24 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 13 Jan 2022 02:26:24 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
Message-ID: <FyaXS-DIzlGkpOYJtmCHL34UKgX9rLOv9f3D1JVG50g=.bbee78c8-670a-4f8d-80fc-7fb6b231de18@github.com>

On Sat, 8 Jan 2022 00:42:18 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Tests are based on SwingSet2 application. 
> Test instructions are loaded from HTML files. 
> 
> See readme for more info.

Marked as reviewed by serb (Reviewer).

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

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


From cushon at openjdk.java.net  Thu Jan 13 02:40:27 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 13 Jan 2022 02:40:27 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
Message-ID: <NMs0EoNvcuYXy8cqIWDNufG5N07BzrzpnA7C8oKRhSE=.dfac64f9-2d7a-4a3b-8c09-7d2ad9ce37d8@github.com>

On Wed, 12 Jan 2022 18:14:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - Write serialized objects at test-time in BadSerializationTest
>  - Merge branch 'master' into JDK-8277817
>  - Revert WIP
>  - Add a few more missing calls to LookAndFeel.uninstallColors
>  - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
>  - Add @since 19 to new methods
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

> only Reviewers can determine that a CSR is not needed.

I marked this as requiring a CSR when the PR included a fix for https://bugs.openjdk.java.net/browse/JDK-8278620 that added new methods to `LookAndFeel`. This fix is now only changing the test, which should not require a CSR.

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

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


From serb at openjdk.java.net  Thu Jan 13 02:44:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 13 Jan 2022 02:44:27 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
Message-ID: <UaoJD5eINpYIdJ3xiBwpKnIOWbjVz9L9ZavpJZIKeLM=.bb1b1719-ff0d-4366-9b38-f44f78f4757f@github.com>

On Wed, 12 Jan 2022 18:14:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - Write serialized objects at test-time in BadSerializationTest
>  - Merge branch 'master' into JDK-8277817
>  - Revert WIP
>  - Add a few more missing calls to LookAndFeel.uninstallColors
>  - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
>  - Add @since 19 to new methods
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

I would like to bring the discussion back to possibility to fix the JDK-8277817 first and then just regenerate the data in this test. The reason is that it found two different product issues, but the new version will not be able to do so.

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

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


From cushon at openjdk.java.net  Thu Jan 13 02:49:29 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 13 Jan 2022 02:49:29 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <UaoJD5eINpYIdJ3xiBwpKnIOWbjVz9L9ZavpJZIKeLM=.bb1b1719-ff0d-4366-9b38-f44f78f4757f@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
 <UaoJD5eINpYIdJ3xiBwpKnIOWbjVz9L9ZavpJZIKeLM=.bb1b1719-ff0d-4366-9b38-f44f78f4757f@github.com>
Message-ID: <lR5aRO7oEmvqbjhEHtSnFneI0UoG4X-ZEQrs5_Rehc8=.6cd99e11-d331-4af2-879e-dcda1824f5f2@github.com>

On Thu, 13 Jan 2022 02:41:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> just regenerate the data in this test

Based on https://github.com/openjdk/jdk/pull/6603#issuecomment-991295599 and https://github.com/openjdk/jdk/pull/6603#issuecomment-991311158, I thought we didn't want to rely on checking in the serialized data.

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

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


From psadhukhan at openjdk.java.net  Thu Jan 13 07:51:54 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 13 Jan 2022 07:51:54 GMT
Subject: RFR: 8279894: javax/swing/JInternalFrame/8020708/bug8020708.java
 timeouts on Windows 11
Message-ID: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>

Test is timing out on slower windows11 CI system. Increased the timeout and also adjusted autodelay time to more consistent time with other headful tests which makes test pass in windows11.
Test job link in JBS.

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

Commit messages:
 - 8279894: javax/swing/JInternalFrame/8020708/bug8020708.java timeouts on Windows 11

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

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


From prappo at openjdk.java.net  Thu Jan 13 10:35:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 10:35:39 GMT
Subject: RFR: 8279918: Fix various doc typos
Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>

- Most of the typos are of a trivial kind: missing whitespace.
- If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
- As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
- &#39; is an apostrophe, which does not require to be encoded.

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

Commit messages:
 - Initial commit

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

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


From kevinw at openjdk.java.net  Thu Jan 13 10:49:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 10:49:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:

> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
> 73:  * positions never occur before ignore characters.</p>

"before ignored characters"

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

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


From prappo at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>

On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
> 
>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>> 73:  * positions never occur before ignore characters.</p>
> 
> "before ignored characters"

I believe it's the name of a concept, so I will leave it as is:

> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

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

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


From kevinw at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:

> 56:  * A JDBC driver implementation should use
> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of

While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
Similarly at line 81, 118, 151, 247, 277, 318, 354.

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

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


From prappo at openjdk.java.net  Thu Jan 13 11:07:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:07:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>

On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
> 
>> 56:  * A JDBC driver implementation should use
>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
> 
> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
> Similarly at line 81, 118, 151, 247, 277, 318, 354.

I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

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

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


From kevinw at openjdk.java.net  Thu Jan 13 11:21:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:21:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/Statement.java line 784:

> 782:      * statement returns a {@code ResultSet} object, the second argument
> 783:      * supplied to this method is not an
> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a

Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

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

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


From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
Message-ID: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>

On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>> 
>>> 56:  * A JDBC driver implementation should use
>>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
>> 
>> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
>> Similarly at line 81, 118, 151, 247, 277, 318, 354.
>
> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
I'll leave it up to you. 8-)

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

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


From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <pjHWjVnBclRVnojpj7BEIAYuSdlwTLMEkAYhI3iPovw=.6e4cd7fe-f085-4572-856d-44d6ecace75c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Marked as reviewed by kevinw (Committer).

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

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


From prappo at openjdk.java.net  Thu Jan 13 11:33:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:33:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>

On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/Statement.java line 784:
> 
>> 782:      * statement returns a {@code ResultSet} object, the second argument
>> 783:      * supplied to this method is not an
>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
> 
> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

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

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


From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Overall this looks good, thanks for the clean up :-)

A few comments below

src/java.base/share/classes/java/io/DataInput.java line 496:

> 494:      * ceases. If the character {@code '\r'}
> 495:      * is encountered, it is discarded and, if
> 496:      * the following byte converts to the

The above is a bit confusing as it reads(same in ImageInputStream.java).  I think that that can be looked at later.

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

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


From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
Message-ID: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>

On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
>
> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
> I'll leave it up to you. 8-)

I think that can be a follow on clean up.

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

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


From lancea at openjdk.java.net  Thu Jan 13 11:46:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
Message-ID: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>

On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/Statement.java line 784:
>> 
>>> 782:      * statement returns a {@code ResultSet} object, the second argument
>>> 783:      * supplied to this method is not an
>>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
>> 
>> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.
>
> You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

Yes an "or" is probably worthwhile to add.

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

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


From prappo at openjdk.java.net  Thu Jan 13 12:40:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 12:40:45 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
Message-ID: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>

On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.

Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

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

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


From mullan at openjdk.java.net  Thu Jan 13 13:45:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 13:45:30 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <GoTfQ0njQABWrD7SFvPbmOPuKBIMNKsS3jJHnHMZfDY=.b11b8d73-4c8b-4eb1-8078-33dcd70b013c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

The change in the one security class (KeyStoreLoginModule) looks fine.

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

Marked as reviewed by mullan (Reviewer).

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


From prappo at openjdk.java.net  Thu Jan 13 13:51:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 13:51:34 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>

On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Yes an "or" is probably worthwhile to add.

I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:

* java/sql/Statement.java:59
* java/sql/Statement.java:85
* java/sql/Statement.java:346
* java/sql/Statement.java:524
* java/sql/Statement.java:745
* java/sql/Statement.java:814
* java/sql/Statement.java:860
* java/sql/Statement.java:913
* java/sql/Statement.java:962
* java/sql/Statement.java:1225
* java/sql/Statement.java:1269
* java/sql/Statement.java:1314

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

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


From prappo at openjdk.java.net  Thu Jan 13 14:01:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 14:01:04 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Additional typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7063/files
  - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f

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

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

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


From sspitsyn at openjdk.java.net  Thu Jan 13 16:53:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 13 Jan 2022 16:53:27 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <Ibur44h4Co3CBFiirsNKloOUVl2G0KUC1pCEbFz5DII=.80447fd1-effd-4cba-9d5c-572ebcf12e72@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Hi Pavel,
Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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


From lancea at openjdk.java.net  Thu Jan 13 17:18:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:18:23 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
 <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
Message-ID: <irVQg_VsXH7St95vPZp8vVD3oaWCefUdqLxDETFhN5I=.ebbbb6d8-eba8-4e17-996d-32ffb15716f3@github.com>

On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
> 
> Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

Yes I am.  It just does not flow as well as it could IMHO

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

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


From naoto at openjdk.java.net  Thu Jan 13 17:25:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:30 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <CmrsmcEGepottkt6pPurYZ3cPdM7oK7v1DInHe5jqbQ=.d9dd81e5-18b2-4e2c-9881-97d586442a35@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by naoto (Reviewer).

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

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


From naoto at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
 <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com>

On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>> 
>>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>>> 73:  * positions never occur before ignore characters.</p>
>> 
>> "before ignored characters"
>
> I believe it's the name of a concept, so I will leave it as is:
> 
>> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

Yes, that is correct.

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

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


From lancea at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
 <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com>

On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Yes an "or" is probably worthwhile to add.
> 
> I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:
> 
> * java/sql/Statement.java:59
> * java/sql/Statement.java:85
> * java/sql/Statement.java:346
> * java/sql/Statement.java:524
> * java/sql/Statement.java:745
> * java/sql/Statement.java:814
> * java/sql/Statement.java:860
> * java/sql/Statement.java:913
> * java/sql/Statement.java:962
> * java/sql/Statement.java:1225
> * java/sql/Statement.java:1269
> * java/sql/Statement.java:1314

I am fine with that.  I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed

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

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


From lancea at openjdk.java.net  Thu Jan 13 17:35:25 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:35:25 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <wFh5PNvl7A_Oui3iDHyjFGEYyurAzJmGjVKD2bEF1tg=.e962af55-7886-4678-8a7b-39d1a695ae22@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by lancea (Reviewer).

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

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


From lucy at openjdk.java.net  Thu Jan 13 21:17:32 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 13 Jan 2022 21:17:32 GMT
Subject: RFR: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15 [v3]
In-Reply-To: <t3V3wIAzV7OwpfVBprYtfmP9--WOBrD1OinZd1r8ziU=.01dc4643-d173-449b-8fad-4eb2d31a7f34@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
 <t3V3wIAzV7OwpfVBprYtfmP9--WOBrD1OinZd1r8ziU=.01dc4643-d173-449b-8fad-4eb2d31a7f34@github.com>
Message-ID: <11R37hV2CZBjAO0dCAj5wpRz_h9rZz9TQjvC24NHluQ=.1920246b-34c2-45d0-9ca2-d809ea72ad66@github.com>

On Tue, 11 Jan 2022 12:13:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this adjustment for recent SUSE Linux 15.
>> The font coding on UNIX, see setOsNameAndVersion in files 
>> 
>> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
>> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
>> 
>> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
>> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
>> 
>> Example content of /etc/os-release
>> NAME="SLES"
>> VERSION="12-SP2"
>> VERSION_ID="12.2"
>> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
>> 
>> There the name and version information is stored (NAME=... , VERSION_ID=...).
>> 
>> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestions by mdoerr for MFontConfiguration.java

Marked as reviewed by lucy (Reviewer).

Changes look good to me. 
Thanks for making the OS detection "future-proof".

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

PR: https://git.openjdk.java.net/jdk/pull/6956Marked as reviewed by lucy (Reviewer).


From jjg at openjdk.java.net  Thu Jan 13 23:01:28 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 13 Jan 2022 23:01:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
 <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
Message-ID: <euQ2BZTUg-jsd4LJYaF9nTXRLsnozIsFNI3en-iH6a0=.1fb0785a-886c-41e7-870f-87b941bb82f6@github.com>

On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
>> I'll leave it up to you. 8-)
>
> I think that can be a follow on clean up.

The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup.

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

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


From achung at openjdk.java.net  Thu Jan 13 23:26:19 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 13 Jan 2022 23:26:19 GMT
Subject: RFR: 8279879: [macos] ActionEvent triggered when right-clicking
 TrayIcon
In-Reply-To: <Rd3vbeISyDCnCumAMzK5f4Qc9kqsueLkEbaIyI-G7oE=.7aa3a3c1-5a68-4fc1-8e73-4f9e25b79977@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
 <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>
 <VNKJoFtKrKYFQT8e9wAbDkNdHgvkXQM_BTuSAeuuaIU=.ea50b53e-746e-410a-8390-c16f6a45377b@github.com>
 <Rd3vbeISyDCnCumAMzK5f4Qc9kqsueLkEbaIyI-G7oE=.7aa3a3c1-5a68-4fc1-8e73-4f9e25b79977@github.com>
Message-ID: <HoNxYEhWjRB35EOpI23w5hMmKH2Kxr8Qgk_IMduHPWI=.6082e95c-dcf3-4b2c-b4fd-850273bdb75c@github.com>

On Wed, 12 Jan 2022 22:54:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Oh, I misunderstood the test. Based on a previous version of this test that was failing I thought the issue was the ActionEvent firing on a TrayIcon right-click that also brought up the balloon message..
>> 
>> I have a few questions about the expected behavior of TrayIcon:
>> Should ActionEvent be triggered on a normal left-click? How about a normal right-click?
>> When should ActionEvent not be triggered? Not on right-click during a balloon message? What about left-click during a balloon message?
>
> It is platform dependent:
> https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/share/classes/java/awt/TrayIcon.java#L565-L566
> Current behavior of OpenJDK is:
> * Linux sends it on left button click
> * macOS send it on right button click.
> * On Windows it can be triggered by a second mouse click on a tray icon(doesn't matter which mouse key is used), left mouse click on the balloon, or enter keypress on it.
> 
> https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L412-L457
> 
> [JDK-8195991](https://bugs.openjdk.java.net/browse/JDK-8195991) introduced this test, but its description does not conform with its code:
> 
>> Right clicking on TrayIcon shouldn't trigger ActionEvent when balloon is displayed.
> 
> Given the info above this will be true only for Linux, which does not trigger `ACTION_PERFORMED` on right mouse click. 
> 
>> int actionPerformedCount = -1;
> ...
> if (actionPerformedCount > 0
> 
> So the test code expects to receive 0 or 1  `ACTION_PERFORMED` events. It allows the test to pass with our current implementation.
> 
> 
> 
> The original test was written along with a fix for Windows back in [2005](https://bugs.openjdk.java.net/browse/JDK-6271624). 
> 
> The Windows UI have changed since this time, so may be the expectation of not receiving of `ACTION_PERFORMED` is no longer valid.

Thanks!
@mrserb could I also get your input on this?
Should I close the PR and resolve the report as "not an issue"?

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

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


From serb at openjdk.java.net  Thu Jan 13 23:43:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 13 Jan 2022 23:43:27 GMT
Subject: RFR: 8279879: [macos] ActionEvent triggered when right-clicking
 TrayIcon
In-Reply-To: <HoNxYEhWjRB35EOpI23w5hMmKH2Kxr8Qgk_IMduHPWI=.6082e95c-dcf3-4b2c-b4fd-850273bdb75c@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
 <toYda-4iP7mqozr5fJbOZ3eAaqz4ZW4yLP10BrZ_E0g=.91d7e3a3-8411-4785-88ac-d21c1466f135@github.com>
 <VNKJoFtKrKYFQT8e9wAbDkNdHgvkXQM_BTuSAeuuaIU=.ea50b53e-746e-410a-8390-c16f6a45377b@github.com>
 <Rd3vbeISyDCnCumAMzK5f4Qc9kqsueLkEbaIyI-G7oE=.7aa3a3c1-5a68-4fc1-8e73-4f9e25b79977@github.com>
 <HoNxYEhWjRB35EOpI23w5hMmKH2Kxr8Qgk_IMduHPWI=.6082e95c-dcf3-4b2c-b4fd-850273bdb75c@github.com>
Message-ID: <H2EGT6Qa7ygPfJQM1gcUHampddWv3JlOkUe8hI_lzdQ=.dd850974-c839-425d-a06f-861d6b796af3@github.com>

On Thu, 13 Jan 2022 23:23:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> It is platform dependent:
>> https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/share/classes/java/awt/TrayIcon.java#L565-L566
>> Current behavior of OpenJDK is:
>> * Linux sends it on left button click
>> * macOS send it on right button click.
>> * On Windows it can be triggered by a second mouse click on a tray icon(doesn't matter which mouse key is used), left mouse click on the balloon, or enter keypress on it.
>> 
>> https://github.com/openjdk/jdk/blob/d70545d71080d534fefd3c9652656549f689f620/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L412-L457
>> 
>> [JDK-8195991](https://bugs.openjdk.java.net/browse/JDK-8195991) introduced this test, but its description does not conform with its code:
>> 
>>> Right clicking on TrayIcon shouldn't trigger ActionEvent when balloon is displayed.
>> 
>> Given the info above this will be true only for Linux, which does not trigger `ACTION_PERFORMED` on right mouse click. 
>> 
>>> int actionPerformedCount = -1;
>> ...
>> if (actionPerformedCount > 0
>> 
>> So the test code expects to receive 0 or 1  `ACTION_PERFORMED` events. It allows the test to pass with our current implementation.
>> 
>> 
>> 
>> The original test was written along with a fix for Windows back in [2005](https://bugs.openjdk.java.net/browse/JDK-6271624). 
>> 
>> The Windows UI have changed since this time, so may be the expectation of not receiving of `ACTION_PERFORMED` is no longer valid.
>
> Thanks!
> @mrserb could I also get your input on this?
> Should I close the PR and resolve the report as "not an issue"?

Yes I think this is not an issue.

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

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


From achung at openjdk.java.net  Fri Jan 14 01:30:25 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 14 Jan 2022 01:30:25 GMT
Subject: Withdrawn: 8279879: [macos] ActionEvent triggered when right-clicking
 TrayIcon
In-Reply-To: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
References: <mDiTp4LcsYdkieM97SgIR8WBC-z385EI0SGSTMECPi8=.5f2bf38a-1ca3-497f-a4c7-19eea7fb594e@github.com>
Message-ID: <MAo8xiUkQGxYzuLU7uEw0zzzqkMb2MOKxS9HwkwGJgI=.9e35b4a9-1e45-4e8d-9cba-362524535ace@github.com>

On Tue, 11 Jan 2022 19:29:11 GMT, Alisen Chung <achung at openjdk.org> wrote:

> fixed test bug, removed extra ActionEvent from TrayIcon

This pull request has been closed without being integrated.

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

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


From serb at openjdk.java.net  Fri Jan 14 02:07:29 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 14 Jan 2022 02:07:29 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
Message-ID: <oIOjvpRUhPfyk_wb4AcGs6oQoJVelLj0hJSTQYeNRdU=.b3f408d8-3699-4f37-bfe3-b92280d72000@github.com>

On Wed, 12 Jan 2022 18:14:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - Write serialized objects at test-time in BadSerializationTest
>  - Merge branch 'master' into JDK-8277817
>  - Revert WIP
>  - Add a few more missing calls to LookAndFeel.uninstallColors
>  - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
>  - Add @since 19 to new methods
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

I do not see a problem to have that serialized data since it have a good coverage and proved to be able find bugs. Note that every time this test fails were unrelated to the versioning of Swing, so I do not see a reason why we should change that to the version which will not be able find that bugs.

I agree that it would be better to have a tests which will found such issue, but looks like we do not have such. For example for the current issue I think nobody could imaging that there are a cleaning issue of fonts/colors/etc.

Since we found a real bugs, I suggest to thinking about an opposite solution and save the data not only on mac but on all platforms, and then load all of them during test execution, eventually this is a test for DnD in AWT which may also some issue related to peers and native objects.

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

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


From lbourges at openjdk.java.net  Fri Jan 14 06:42:30 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 14 Jan 2022 06:42:30 GMT
Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes
 Bezier control points in bounding box [v12]
In-Reply-To: <i8wNF6CsEhC-9p88qf8vH9nSdhDDwcFjY7Z2QMpvz4Y=.81f1d2ff-d730-4e43-8782-329736fe78e2@github.com>
References: <rAU1PGRagzXz9AW0Blp4wwtLg2YyihsDtGP9I4_uASU=.bc88afb0-f230-4b98-87c7-7133b26727f2@github.com>
 <pkujGIpXv0UwX2gxeX6kOzKXHiqoImRI9BuglmWbHbE=.a4801fee-2fc4-4a78-97b6-4ea27396492a@github.com>
 <i8wNF6CsEhC-9p88qf8vH9nSdhDDwcFjY7Z2QMpvz4Y=.81f1d2ff-d730-4e43-8782-329736fe78e2@github.com>
Message-ID: <KnT6whRRSiVDGtVIVbDg_cHJdV91K5dI9bHGA-YsVYo=.7576eb92-f14d-4e6e-81a2-2b733a1916e0@github.com>

On Wed, 5 Jan 2022 22:48:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box
>>   
>>   This is a second follow-up response to prrace's code review feedback about method modifiers.
>>   
>>   This commit more carefully preserves the getBounds2D() method modifiers for all 3 classes: the Path2D.Double, the Path2D.Float, and the Path2D itself.
>>   
>>   It is possible (if unlikely) that someone previously extended the Path2D class and overrode getBounds2D(), because the Path2D#getBounds2D() method was *not* final. So with this commit: any such existing code will not break. Meanwhile the subclasses (Double and Float) preserve their previous modifiers (final, synchronized).
>>   
>>   This is in response to prrace's code review:
>>   
>>   >    You are changing the signature of public API
>>   >    src/java.desktop/share/classes/java/awt/geom/Path2D.java
>>   >    public final synchronized Rectangle2D getBounds2D() => public Rectangle2D getBounds2D() {
>>   >
>>   > So no longer final, and no longer synchronized.
>>   > This means a CSR is required and we need to think about it ..
>>   > the intention was that the subclass not over-ride.
>>   > And why remove synchronized ? I am fairly sure it was there to
>>   > make sure no one was mutating the Path whilst
>>   > bounds are being calculated.
>>   > And you are using getPathIterator(AffineTransform) and the docs
>>   > for that say it isn't thread safe.
>>   > So I think this implementation needs to be thought about very carefully.
>
> I still recommend a CSR since
> 1) Although "compatible", this visibly moves the specs for getBounds2D() from copies on the Float and Double nested sub-classes to the enclosing parent class
> 2) Although in the spirit of what getBounds2D() is supposed to do  .. it actually hasn't for over 20 years. We like to document such behavioural changes via a CSR.
> 
> Actually regarding (1) there's also a real change there too since now The Float subclass will return a Rectangle2D.Double .. I am not sure that we should actually do that.

@prrace how to proceed ? Could you manage the CSR in JBS ? I never had to do it.

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

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


From mbaesken at openjdk.java.net  Fri Jan 14 09:54:33 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 14 Jan 2022 09:54:33 GMT
Subject: Integrated: JDK-8278549: UNIX sun/font coding misses SUSE distro
 detection on recent distro SUSE 15
In-Reply-To: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
References: <OzSi4TtRy1AHsqcxS69MZUuvV2RdInKfQacq17DCeto=.2fc33d64-5cdf-46a4-8ce3-c2cc6deb6dd9@github.com>
Message-ID: <kiMlpjCLGLlJYFGnv0n55ZeEW4N6lcZlrelHJE02QWo=.8c9766ea-3403-4468-af2b-cb1fbd485ffc@github.com>

On Tue, 4 Jan 2022 14:14:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this adjustment for recent SUSE Linux 15.
> The font coding on UNIX, see setOsNameAndVersion in files 
> 
> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
> src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
> 
> uses the file /etc/SuSE-release to detect SUSE Linux. However on SUSE Linux 15 this file does not exist any more.
> Instead /etc/os-release can be used as a replacement on SLES12 and SLES15 :
> 
> Example content of /etc/os-release
> NAME="SLES"
> VERSION="12-SP2"
> VERSION_ID="12.2"
> PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
> 
> There the name and version information is stored (NAME=... , VERSION_ID=...).
> 
> Additionally I noticed that there is some code duplication in FcFontConfiguration.java and MFontConfiguration.java , what do you think about moving this to some common place ?
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 84976b45
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/84976b45315feb6c37a9f3db6e1e62812c9b0a37
Stats:     34 lines in 2 files changed: 32 ins; 0 del; 2 mod

8278549: UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15

Reviewed-by: mdoerr, lucy

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

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


From jlahoda at openjdk.java.net  Fri Jan 14 11:22:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 14 Jan 2022 11:22:36 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <mHTQhslPgaefsXLYiV_SvYHyzjK_ugDhBIpWzkdua3o=.d6cc09e9-9eb6-4dbb-9b9a-64b743d7eb37@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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


From azvegint at openjdk.java.net  Fri Jan 14 12:19:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 14 Jan 2022 12:19:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Client changes looks good to me.

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

Marked as reviewed by azvegint (Reviewer).

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


From duke at openjdk.java.net  Fri Jan 14 12:21:54 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 12:21:54 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
Message-ID: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>

`Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

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

Commit messages:
 - [PATCH] Remove double buffering of InputStream for Properties.load
 - [PATCH] Remove double buffering of InputStream for Properties.load

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

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


From serb at openjdk.java.net  Fri Jan 14 12:21:55 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 14 Jan 2022 12:21:55 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <rlzE5LP1GvYmJokJSX217LG9ZDiZ19UwpgjxaqEVIgw=.6ba07765-b53f-4e9a-ba4f-75dcce6a03e0@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

The code change looks fine, but can you please check the actual performance impact, will the perf be the same after the change?

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

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


From duke at openjdk.java.net  Fri Jan 14 12:21:56 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 12:21:56 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <ZyprBFZv-TtabE3aKYr6Zm5jVYMv4Axxz_Ky26hmtg0=.4675e14d-13b6-4901-931e-a99895f950b1@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Checked. `BufferedInputStream` add a bit of overhead.

Benchmark

@BenchmarkMode(value = Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 6, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Benchmark)
public class PropertiesLoad {

    Properties properties;
    private InputStream arrayInputStream;
    private InputStream fileInputStream;
    private Path filePath;

    @Setup
    public void setupStrings() throws IOException {
        properties = new Properties();
        String content = """
                currentVersion=IdealGraphVisualizer {0}
                LBL_splash_window_title=Starting IdealGraphVisualizer
                SPLASH_WIDTH=475
                SplashProgressBarBounds=0,273,475,6
                SplashProgressBarColor=0xFFFFFF
                SplashRunningTextBounds=10,283,460,12
                SplashRunningTextColor=0xFFFFFF
                """;
        filePath = Files.createTempFile("benchmark", ".properties");
        Files.writeString(filePath, content);
        arrayInputStream = new ByteArrayInputStream(content.getBytes(StandardCharsets.UTF_8));
        fileInputStream = Files.newInputStream(filePath);
    }

    @TearDown
    public void tearDown() throws IOException {
        fileInputStream.close();
        Files.delete(filePath);
    }

    @Benchmark
    public Properties plain_ByteStream() throws IOException {
        properties.load(arrayInputStream);
        return properties;
    }

    @Benchmark
    public Properties plain_fileStream() throws IOException {
        properties.load(fileInputStream);
        return properties;
    }

    @Benchmark
    public Properties buffered_ByteStream() throws IOException {
        properties.load(new BufferedInputStream(arrayInputStream));
        return properties;
    }

    @Benchmark
    public Properties buffered_fileStream() throws IOException {
        properties.load(new BufferedInputStream(fileInputStream));
        return properties;
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(PropertiesLoad.class.getSimpleName())
                .build();

        new Runner(opt).run();
    }
}

Results:

Benchmark                           Mode  Cnt     Score     Error  Units
PropertiesLoad.buffered_ByteStream  avgt    5  2416,364 ?  46,209  ns/op
PropertiesLoad.buffered_fileStream  avgt    5  4276,015 ? 139,094  ns/op
PropertiesLoad.plain_ByteStream     avgt    5  1445,864 ? 649,779  ns/op
PropertiesLoad.plain_fileStream     avgt    5  3183,012 ? 198,974  ns/op

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

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


From egahlin at openjdk.java.net  Fri Jan 14 12:42:32 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 12:42:32 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <V_tZ6iUCrtIDCAbwbWr8Pnj-hACcC7UbdEStP17e3BA=.5c64f1d4-9df7-4d9f-8bbc-f59b2748505f@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by egahlin (Reviewer).

The JFR related changes looks OK.

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

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


From amenkov at openjdk.java.net  Fri Jan 14 13:15:22 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 14 Jan 2022 13:15:22 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <BJ_TakGdqnUA_KqyNNzOjx2OHWDBJPWs-qx02dOm0wU=.ef481020-fd17-4f9b-9240-a92bacfed170@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by amenkov (Reviewer).

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

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


From dfuchs at openjdk.java.net  Fri Jan 14 14:51:23 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 14 Jan 2022 14:51:23 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <AjckcFhVCs6vyjv3G2rXoN6xc72qk4fg739kj6BW2wc=.cbf3e695-d333-4540-b7ae-75a02844e909@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Changes to `java.util.logging` look fine.

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

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


From alexsch at openjdk.java.net  Fri Jan 14 15:11:27 2022
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 14 Jan 2022 15:11:27 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3]
In-Reply-To: <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
Message-ID: <Y3GE9e01dL7-33C7CyMMUmlmJv2T7N8kbxjKXjt3leA=.d99c9f3e-d511-4f02-b358-46b1fea45172@github.com>

On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>> 
>> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
>> 
>> import javax.print.*;
>> import javax.swing.*;
>> 
>> public class Hello {
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
>> 
>>             StringBuilder builder = new StringBuilder();
>>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>>             int size = services.length;
>>             for (int i = 0; i < size; i++) {
>>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>>             }
>>             JOptionPane.showMessageDialog(null, builder.toString());
>>         });
>>     }
>> }
>> 
>> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
>> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
>> 
>> The problem has been discussed on  2d-dev mail list:
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
>> 
>> According to the discussion:
>> 
>>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>>> Their unofficial position is that java should be connecting to the cups interface returned
>>> by the cupsServer() function and not changing the interface string to "localhost".
>>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>>> network-client access with print access.  They don't seem interested in loosening that change.
>> 
>> 
>> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return null if printers are not found in sandboxed app on MacOS

I see that the fix has been inactive for several months.
Is there something that I missed and should update from my side (add comments, answer on questions, update commits, or something else)?

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

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


From jjg at openjdk.java.net  Fri Jan 14 16:08:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 Jan 2022 16:08:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

jdk.compiler and jdk.javadoc look good

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

Marked as reviewed by jjg (Reviewer).

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


From prappo at openjdk.java.net  Fri Jan 14 16:13:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 14 Jan 2022 16:13:34 GMT
Subject: Integrated: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <iRT0-D_kHCqoTOO_tqTh0WH4UU1j-7Ju2SV6oLUBLhU=.73b73e8f-5608-4fc1-a147-bc569d647428@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

This pull request has now been integrated.

Changeset: f1805309
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224
Stats:     88 lines in 35 files changed: 0 ins; 0 del; 88 mod

8279918: Fix various doc typos

Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg

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

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


From duke at openjdk.java.net  Fri Jan 14 17:31:09 2022
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 14 Jan 2022 17:31:09 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
Message-ID: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>

> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.

Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:

  Fix converting coordinates when getting GC at point
  
  Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/72/files
  - new: https://git.openjdk.java.net/jdk18/pull/72/files/52327942..b0c20376

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

  Stats: 95 lines in 1 file changed: 66 ins; 7 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/72.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/72/head:pull/72

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Fri Jan 14 17:37:34 2022
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Fri, 14 Jan 2022 17:37:34 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
Message-ID: <FV84nJuqpv65S7NXM3GBcC-zZ-cKMPcNBOqg-ZemCYI=.475925fb-db40-41d7-8078-5ffda8a30ca5@github.com>

On Fri, 14 Jan 2022 17:31:09 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix converting coordinates when getting GC at point
>   
>   Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

I've fixed receiving GC at given point and now hit-test and frame bounds seem to be calculated correctly. But it looks like NVDA does not work correctly with HiDPI itself, to it (at least v. 2021.3.1) has to be started in compatibility mode, see the attached picture

![image](https://user-images.githubusercontent.com/3617329/149559638-97df15dd-6178-4f02-b210-2cd625936c50.png)

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From sspitsyn at openjdk.java.net  Fri Jan 14 17:59:29 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 14 Jan 2022 17:59:29 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <svTyMZjHhPPqYKFtRqAV4uiCY1cTzGj7hAj5jQ4QksU=.aab322cc-5262-4b24-9cca-566d3264622b@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by sspitsyn (Reviewer).

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

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


From duke at openjdk.java.net  Fri Jan 14 18:00:59 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 18:00:59 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom
 where applicable
Message-ID: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>

Method `Class.isAssignableFrom` is often used in form of:

    if (clazz.isAssignableFrom(obj.getClass())) {
Such condition could be simplified to more shorter and performarnt code

    if (clazz.isInstance(obj)) {
    
Replacement is equivalent if it's known that `obj != null`.
In JDK codebase there are many such places.

I tried to measure performance via JMH

    Class<?> integerClass = Integer.class;
    Class<?> numberClass = Number.class;

    Object integerObject = 45666;
    Object doubleObject = 8777d;

    @Benchmark
    public boolean integerInteger_isInstance() {
        return integerClass.isInstance(integerObject);
    }

    @Benchmark
    public boolean integerInteger_isAssignableFrom() {
        return integerClass.isAssignableFrom(integerObject.getClass());
    }

    @Benchmark
    public boolean integerDouble_isInstance() {
        return integerClass.isInstance(doubleObject);
    }

    @Benchmark
    public boolean integerDouble_isAssignableFrom() {
        return integerClass.isAssignableFrom(doubleObject.getClass());
    }

    @Benchmark
    public boolean numberDouble_isInstance() {
        return numberClass.isInstance(doubleObject);
    }

    @Benchmark
    public boolean numberDouble_isAssignableFrom() {
        return numberClass.isAssignableFrom(doubleObject.getClass());
    }

    @Benchmark
    public boolean numberInteger_isInstance() {
        return numberClass.isInstance(integerObject);
    }

    @Benchmark
    public boolean numberInteger_isAssignableFrom() {
        return numberClass.isAssignableFrom(integerObject.getClass());
    }

    @Benchmark
    public void numberIntegerDouble_isInstance(Blackhole bh) {
        bh.consume(numberClass.isInstance(integerObject));
        bh.consume(numberClass.isInstance(doubleObject));
    }

    @Benchmark
    public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
        bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
        bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
    }

`isInstance` is a bit faster than `isAssignableFrom`

Benchmark                              Mode  Cnt  Score   Error  Units
integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

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

Commit messages:
 - [PATCH] Use Class.isInstance instead of Class.isAssignableFrom where applicable

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

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


From duke at openjdk.java.net  Fri Jan 14 18:01:01 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 14 Jan 2022 18:01:01 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
Message-ID: <SVab__NRaA7GuYhKESH27YoUlkAWrJ5YqhLimTeoqlg=.bafda227-7734-4bd2-9c25-e63619bc1264@github.com>

On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Method `Class.isAssignableFrom` is often used in form of:
> 
>     if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
> 
>     if (clazz.isInstance(obj)) {
>     
> Replacement is equivalent if it's known that `obj != null`.
> In JDK codebase there are many such places.
> 
> I tried to measure performance via JMH
> 
>     Class<?> integerClass = Integer.class;
>     Class<?> numberClass = Number.class;
> 
>     Object integerObject = 45666;
>     Object doubleObject = 8777d;
> 
>     @Benchmark
>     public boolean integerInteger_isInstance() {
>         return integerClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean integerInteger_isAssignableFrom() {
>         return integerClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isInstance() {
>         return integerClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isAssignableFrom() {
>         return integerClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isInstance() {
>         return numberClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isAssignableFrom() {
>         return numberClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isInstance() {
>         return numberClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isAssignableFrom() {
>         return numberClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>         bh.consume(numberClass.isInstance(integerObject));
>         bh.consume(numberClass.isInstance(doubleObject));
>     }
> 
>     @Benchmark
>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>     }
> 
> `isInstance` is a bit faster than `isAssignableFrom`
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405:

> 403:                         Object res = m.invoke(a, new Object[0]);
> 404:                         if (res instanceof Annotation[]) {
> 405:                             for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) {

BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead?

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

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


From prr at openjdk.java.net  Fri Jan 14 19:15:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 14 Jan 2022 19:15:43 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu
 21.10
Message-ID: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>

Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 

See the bug for more info.

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

Commit messages:
 - 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10

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

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


From myano at openjdk.java.net  Sat Jan 15 02:21:31 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Sat, 15 Jan 2022 02:21:31 GMT
Subject: Integrated: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <hNWIh1kbnM2zvlaZUMHSDjinMPdHciAinc7BZ7-fWKk=.33a835ed-f549-4b42-8cbb-2fca2ffd0492@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

This pull request has now been integrated.

Changeset: 22b7295e
Author:    Masanori Yano <myano at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22b7295e75d3bc7ba2c2cd7b871bb2bb5bf290eb
Stats:     59 lines in 2 files changed: 13 ins; 38 del; 8 mod

7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Sat Jan 15 02:27:28 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 15 Jan 2022 02:27:28 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
Message-ID: <Wwdx4SOcjTlMbhb8RK9hd5tqhrpw9jE8hBtlqbYhpV4=.dde02fc1-7f1d-47e5-b07e-91630268e807@github.com>

On Fri, 14 Jan 2022 19:09:53 GMT, Phil Race <prr at openjdk.org> wrote:

> Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 
> 
> See the bug for more info.

Maybe we can ask some ppl from the hotspot team about this issue, is it a critical thing that these handlers are overwritten by probably GTK3? Can it cause a crash or something?

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

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


From serb at openjdk.java.net  Sat Jan 15 02:29:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 15 Jan 2022 02:29:32 GMT
Subject: RFR: 8279894: javax/swing/JInternalFrame/8020708/bug8020708.java
 timeouts on Windows 11
In-Reply-To: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
References: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
Message-ID: <vGXPGjhTXQi6zvGdFBUrbQBB_lnSnYhaZKeQYMGlxH0=.523383ff-61ce-4ee7-9877-7245c72b655e@github.com>

On Thu, 13 Jan 2022 07:44:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is timing out on slower windows11 CI system. Increased the timeout and also adjusted autodelay time to more consistent time with other headful tests which makes test pass in windows11.
> Test job link in JBS.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Sat Jan 15 02:32:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 15 Jan 2022 02:32:32 GMT
Subject: RFR: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <YUDWGMcJWVXt0_z2KnNBNd4DCnA4kZOTLF4CKs8M2lA=.f56bafef-e12a-4595-ac9a-b7405b69b637@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

Marked as reviewed by serb (Reviewer).

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

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


From mikael at openjdk.java.net  Sat Jan 15 03:23:53 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 15 Jan 2022 03:23:53 GMT
Subject: Integrated: 8280048: Missing comma in copyright header
Message-ID: <UEu5TDaN-3iTedPoQ4fpy2bZ8MdF0TMXjaVL5yLxRI4=.883d2cbc-376d-4b51-8c74-8e3b64ae82de@github.com>

Missing comma in test/jdk/java/awt/Graphics2D/CopyAreaOOB.java after JDK-7001973.

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

Commit messages:
 - Update CopyAreaOOB.java

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

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


From prr at openjdk.java.net  Sat Jan 15 03:23:54 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 15 Jan 2022 03:23:54 GMT
Subject: Integrated: 8280048: Missing comma in copyright header
In-Reply-To: <UEu5TDaN-3iTedPoQ4fpy2bZ8MdF0TMXjaVL5yLxRI4=.883d2cbc-376d-4b51-8c74-8e3b64ae82de@github.com>
References: <UEu5TDaN-3iTedPoQ4fpy2bZ8MdF0TMXjaVL5yLxRI4=.883d2cbc-376d-4b51-8c74-8e3b64ae82de@github.com>
Message-ID: <_CkEtiVEODq-rhF0wUydQKiUAsWxGCWqeoc9iwE_XHM=.cfc654e2-a651-4583-a038-a3a38b784163@github.com>

On Sat, 15 Jan 2022 03:14:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Missing comma in test/jdk/java/awt/Graphics2D/CopyAreaOOB.java after JDK-7001973.

Marked as reviewed by prr (Reviewer).

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

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


From mikael at openjdk.java.net  Sat Jan 15 03:23:55 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 15 Jan 2022 03:23:55 GMT
Subject: Integrated: 8280048: Missing comma in copyright header
In-Reply-To: <UEu5TDaN-3iTedPoQ4fpy2bZ8MdF0TMXjaVL5yLxRI4=.883d2cbc-376d-4b51-8c74-8e3b64ae82de@github.com>
References: <UEu5TDaN-3iTedPoQ4fpy2bZ8MdF0TMXjaVL5yLxRI4=.883d2cbc-376d-4b51-8c74-8e3b64ae82de@github.com>
Message-ID: <mm7uQ7eCcdRU0mYTxX1rS6LLGHT0ndAq2TiRb_frrIA=.9a14f74b-5535-474f-8e85-3b4ec47c8c93@github.com>

On Sat, 15 Jan 2022 03:14:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Missing comma in test/jdk/java/awt/Graphics2D/CopyAreaOOB.java after JDK-7001973.

This pull request has now been integrated.

Changeset: 9a18190a
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a18190a4f8e31801d1442d97f247f074a3fd5c0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8280048: Missing comma in copyright header

Reviewed-by: prr

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

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


From stuefe at openjdk.java.net  Sat Jan 15 07:27:25 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 15 Jan 2022 07:27:25 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
Message-ID: <1ku-ueWDkIBHos6bWPobQfh5GM34f8p3phW9Djyll0M=.021807de-9d8e-4729-a425-0ef9ea19d470@github.com>

On Fri, 14 Jan 2022 19:09:53 GMT, Phil Race <prr at openjdk.org> wrote:

> Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 
> 
> See the bug for more info.

In hotspot, we want to explicitly ignore SIGPIPE and SIGXFSZ (see https://bugs.openjdk.java.net/browse/JDK-4229104 and https://bugs.openjdk.java.net/browse/JDK-6499219). But we don't do SIG_IGN, since we still need to give chained handlers the opportunity to handle them. See https://github.com/openjdk/jdk/blob/fef8f2d30004ea75c663752ae6c61b214fb8abc8/src/hotspot/os/posix/signals_posix.cpp#L618-L623.

So now, from the OS perspective, we handle SIGPIPE. We just don't do anything but return from the signal handler (ignoring chained handlers for now). If someone outside sets SIGPIPE to SIG_IGN, then we get subtle changes:
- IO calls would now yield EPIPE, whereas now I am not sure what happens? Does the IO call report success?
- Also, chained handlers would not get called.

It's all pretty unexciting. Nothing would crash. There may be an argument for skipping the test on SIGPIPE if it is SIG_IGN and we don't have chained handlers. If it seems such a standard thing to do for third party libraries. Idk. Maybe open a separate bug?

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

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


From cushon at openjdk.java.net  Sat Jan 15 23:28:44 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Sat, 15 Jan 2022 23:28:44 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy
Message-ID: <rlwasPohJ8GF9X1_VT4k5fnUxLp6SKb3c1Da1pHGcUg=.5bcce64c-3ef4-4f37-9f3e-b72ff3e5ed7e@github.com>

This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).

It also contains a fix for the subset of [JDK-8278620](https://bugs.openjdk.java.net/browse/JDK-8278620) necessary for the test to pass with the updated serialized objects.

See also discussion in https://git.openjdk.java.net/jdk/pull/6603

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

Commit messages:
 - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

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

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


From cushon at openjdk.java.net  Sat Jan 15 23:29:39 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Sat, 15 Jan 2022 23:29:39 GMT
Subject: RFR: 8277817:
 java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed:
 ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v10]
In-Reply-To: <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
References: <r7uugMTz9-3VuqeD0-esug9L3oPRxMsiOAU6_jrJKRg=.0ca8106c-e3b3-4b6e-829e-201191dcb107@github.com>
 <W2s9WCAQ0PrTJ6_74UYEZKrNcArdyqeqFjPDL60ugsU=.ddb42dc6-f07c-48cb-bf69-0625ac3e5ea4@github.com>
Message-ID: <ZSF-u9VmeOeq5zaBucfq_27khGumj3q2iwQUwFUQstA=.7bf81d0c-8d55-411d-8848-8ee01febc6a1@github.com>

On Wed, 12 Jan 2022 18:14:45 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - Write serialized objects at test-time in BadSerializationTest
>  - Merge branch 'master' into JDK-8277817
>  - Revert WIP
>  - Add a few more missing calls to LookAndFeel.uninstallColors
>  - Use LookAndFeel.uninstallColorsAndFont in BasicListUI
>  - Add @since 19 to new methods
>  - Add uninstallColorsAndFont
>  - 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy

I don't have a strong preference between the current approach in the PR of not persisting serialized objects, and of updating the existing serialized objects; whichever the `client-libs` group prefers is fine with me.

I restored the earlier version of the PR that updated the existing serialized data as https://github.com/openjdk/jdk/pull/7100

> > I wonder if it's possible to modify the value of the field using reflection via `setAccessible(true)`
>
> Done: the test now creates valid objects, and then uses reflection to set the fields to `null` after the constructor has executed.

@aivanov-jdk I spun that cleanup out into a separate issue, since I think it's a worthwhile improvement regardless of which fix is accepted here: https://github.com/openjdk/jdk/pull/7099

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

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


From psadhukhan at openjdk.java.net  Mon Jan 17 05:31:00 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 05:31:00 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v2]
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <MNDCgDC6RsrQTW48vM1551nTAm3eUf0M1AaLUIkCviM=.260eb86b-54be-4549-8d3f-9bf3f9988a2d@github.com>

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  review fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7004/files
  - new: https://git.openjdk.java.net/jdk/pull/7004/files/97d0232a..765c4147

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

  Stats: 43 lines in 7 files changed: 12 ins; 0 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004

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


From psadhukhan at openjdk.java.net  Mon Jan 17 05:31:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 05:31:08 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v2]
In-Reply-To: <uuK5svog9pn3o50Ovi9iFnGMsuwzFAuCPoPSHMO2n50=.88d07c22-1da4-4545-a105-178eb14d7e62@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <uuK5svog9pn3o50Ovi9iFnGMsuwzFAuCPoPSHMO2n50=.88d07c22-1da4-4545-a105-178eb14d7e62@github.com>
Message-ID: <5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>

On Tue, 11 Jan 2022 05:19:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review fix
>
> src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 65:
> 
>> 63: 
>> 64:     /**
>> 65:      * Returns the imaga capabilities of the front buffer
> 
> Please add a dot after the first sentence, it is used as a summary doc for the method.
> Why the text about "displayed" buffer is removed? is it some special "term" like "intermediate" below?

Done

> src/java.desktop/share/classes/java/awt/Component.java line 4697:
> 
>> 4695: 
>> 4696:     /**
>> 4697:      * Checks whether or not paint messages received from the operating system
> 
> In the change above the "Returns whether or not" text is used. It is better to use the same new text, or just use the old one.

Done

> src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:
> 
>> 651:     /* For European keyboards */
>> 652:     /**
>> 653:      * Constant for the DEAD_GRAVE function key.
> 
> I do not know, are all the keys here actually "function keys"?

Remove function keyword as it seems dead keys are combination of keys.

> src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 150:
> 
>> 148:     /************************************************************************/
>> 149: 
>> 150:     /**
> 
> This will add many statements to the specification which could be verified by the TCK. DO we really want to say all of that? Especially about serialization. Same question for other changes below.

ok. only added relevant info

> src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
> 
>> 148: 
>> 149:     /**
>> 150:      * Start UndoableEdit.
> 
> What does it mean? Is it clear enough for the class which "managing <code>UndoableEdit</code> listeners"?

It seems it other places like CompoundEdit class, "assemble little UndoableEdits " statement is used so it seems ok to use UndoableEdit here. At least it's better than (to me)

"DEADLOCK WARNING: Calling this method may call
     * <code>undoableEditHappened</code> in all listeners."

   
 used in endUpdate...

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

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


From psadhukhan at openjdk.java.net  Mon Jan 17 06:32:44 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 06:32:44 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs
Message-ID: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>

Fixed the broken link with appropriate link to swing document.

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

Commit messages:
 - 8280047: Broken link to Swing Connection document from javax.swing package docs

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

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


From psadhukhan at openjdk.java.net  Mon Jan 17 06:45:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 06:45:26 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <-SUJQ0fsn1Uw6ls00cWFSRW2JyXfwxe7xJLQA6-tjMc=.37d2820c-2830-4ed9-8de4-94476fcf42ee@github.com>

On Mon, 17 Jan 2022 06:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed the broken link with appropriate link to swing document.

It seems "Swing connection" used to point to group of swing articles but is removed long back 
https://community.oracle.com/tech/developers/discussion/1214597/where-is-swing-connection
I guess it's better to point to Swing architecture overview instead.

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

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


From egahlin at openjdk.java.net  Mon Jan 17 08:31:26 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Mon, 17 Jan 2022 08:31:26 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <SVab__NRaA7GuYhKESH27YoUlkAWrJ5YqhLimTeoqlg=.bafda227-7734-4bd2-9c25-e63619bc1264@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <SVab__NRaA7GuYhKESH27YoUlkAWrJ5YqhLimTeoqlg=.bafda227-7734-4bd2-9c25-e63619bc1264@github.com>
Message-ID: <mqWSG40J80uEpBaCNRxl7pediBJJgR9lSkP3S6YRsi4=.72cbec13-6e35-445d-9d95-8651c9a24a25@github.com>

On Thu, 13 Jan 2022 08:39:04 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405:
> 
>> 403:                         Object res = m.invoke(a, new Object[0]);
>> 404:                         if (res instanceof Annotation[]) {
>> 405:                             for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) {
> 
> BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead?

It looks unnecessary. Please feel free to fix.

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

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


From myano at openjdk.java.net  Mon Jan 17 10:13:25 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 17 Jan 2022 10:13:25 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <Te1ERCGnFVRNHolruCemNwLzN50v9_sxR8ZFlPm8dnE=.26d0c2db-902d-406c-8b47-d09836f69cfe@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb Could you please review this PR again?

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

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


From aivanov at openjdk.java.net  Mon Jan 17 10:26:27 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 17 Jan 2022 10:26:27 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v13]
In-Reply-To: <d31ehkqdQ8BShQ6_7M9-LlfAI6458G1LL-bkZ4PnBZ8=.0ef37c2c-61ea-4a7c-a977-b82cf1b960d6@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <d31ehkqdQ8BShQ6_7M9-LlfAI6458G1LL-bkZ4PnBZ8=.0ef37c2c-61ea-4a7c-a977-b82cf1b960d6@github.com>
Message-ID: <NVfaq14OLlOPrsN36Q29cuxYTN75BldyIxk0EliB9kI=.af3499fb-1131-4fc1-947a-b6bf928aaa6d@github.com>

On Tue, 11 Jan 2022 20:58:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright dates, updated test and fix to also check vertical borders

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved.

The must be a comma after the second year, it was there previously.
Suggestion:

 * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 239:

> 237:         syncState(fScrollBar);
> 238:         Insets insets = fScrollBar.getInsets();
> 239:         return JRSUIUtils.HitDetection.getHitForPoint(painter.getControl(), 0, 0,

Probably these zeroes should rather be `insets.left` and `insets.top` correspondingly.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved.

There must be a comma after the second year.
Suggestion:

 * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 33:

> 31: import java.io.File;
> 32: import java.io.IOException;
> 33: import java.lang.reflect.InvocationTargetException;

Neither `ImageObserver` nor `InvocationTargetException` are used. These two imports must be removed.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 55:

> 53:     public static final int HEIGHT = 20;
> 54: 
> 55:     private static void setLookAndFeel(UIManager.LookAndFeelInfo laf) {

I'd suggest moving the `main` here, and placing the helper `setLookAndFeel` after both `test*` methods. This way a reader would know right away what the test does, the test methods follow `main` to see the actual test code.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 88:

> 86:         // check border for thumb
> 87:         for (int i = WIDTH - BORDER_WIDTH; i < WIDTH; i++) {
> 88:             for (int j = 0; j < HEIGHT; j++) {

Now that there are two test methods, I'd suggest using `x` and `y` as loop variables:
Suggestion:

        for (int x = WIDTH - BORDER_WIDTH; x < WIDTH; x++) {
            for (int y = 0; y < HEIGHT; y++) {


This would make it clearer how comparison works.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 90:

> 88:             for (int j = 0; j < HEIGHT; j++) {
> 89:                 int c1 = image1.getRGB(i,j);
> 90:                 int c2 = image2.getRGB(i,j);

Please put a space after the commas in parameter list.
Suggestion:

                int c1 = image1.getRGB(i, j);
                int c2 = image2.getRGB(i, j);

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 91:

> 89:                 int c1 = image1.getRGB(i,j);
> 90:                 int c2 = image2.getRGB(i,j);
> 91:                 if(c1 != c2) {

Please put a space between the keywords and an opening parenthesis.
 ```suggestion
                if (c1 != c2) {

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 126:

> 124:         // check border for thumb
> 125:         for (int i = WIDTH - BORDER_WIDTH; i < WIDTH; i++) {
> 126:             for (int j = 0; j < HEIGHT; j++) {

Using `x` and `y` would make the loops clearer:
Suggestion:

        for (int y = WIDTH - BORDER_WIDTH; y < WIDTH; y++) {
            for (int x = 0; x < HEIGHT; x++) {

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 129:

> 127:                 int c1 = image1.getRGB(j,i);
> 128:                 int c2 = image2.getRGB(j,i);
> 129:                 if(c1 != c2) {

Missing spaces
Suggestion:

                int c1 = image1.getRGB(j, i);
                int c2 = image2.getRGB(j, i);
                if (c1 != c2) {

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 133:

> 131:                                        + Integer.toHexString(c1));
> 132:                     System.out.println(i + " " + j + " " + "Color2: "
> 133:                                        + Integer.toHexString(c2));

The coordinates must be reversed in the case of vertical scrollbar.
However, if you rename the loop variables to `x` and `y` as suggested above, `getRGB` and the error messages would be the same and would use the natural order for `x` and `y`.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 160:

> 158: 
> 159:     // custom border
> 160:     private static class HorizontalCustomBorder implements Border {

Both `HorizontalCustomBorder` and `VerticalCustomBorder` could be implemented as a single parametrised class. However, it's okay to keep them separate, there's not much code; introducing a new superclass wouldn't make the code clearer.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 161:

> 159:     // custom border
> 160:     private static class HorizontalCustomBorder implements Border {
> 161:         public void paintBorder(Component c, Graphics g, int x, int y, int width, int height) {

I suggest adding `@Override` annotation to the methods implementing `Border` interface, that is to all the methods in both Both `HorizontalCustomBorder` and `VerticalCustomBorder` classes.

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 167:

> 165: 
> 166:         public Insets getBorderInsets(Component c) {
> 167:             return new Insets(0, 0, 0, 150);

Suggestion:

            return new Insets(0, 0, 0, BORDER_WIDTH);

test/jdk/java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java line 183:

> 181: 
> 182:         public Insets getBorderInsets(Component c) {
> 183:             return new Insets(0, 0, 150, 0);

Suggestion:

            return new Insets(0, 0, BORDER_WIDTH, 0);

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

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


From kcr at openjdk.java.net  Mon Jan 17 13:38:28 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 17 Jan 2022 13:38:28 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <vdsKjgI1BwGGlKiSGgsi2Bqkm8jXROS4AYu7YhI-Rjo=.04baaa6b-23e4-4b9c-9bed-5a30b643b150@github.com>

On Mon, 17 Jan 2022 06:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed the broken link with appropriate link to swing document.

This looks like a good replacement, but you have a typo in the HTML link. Once fixed, please run `make docs` and check the generated html page.

src/java.desktop/share/classes/javax/swing/package-info.java line 135:

> 133:  * please see:
> 134:  * <ul>
> 135:  *     <li><a href=""https://www.oracle.com/java/technologies/a-swing-architecture.html"

Typo: you have an extra `"` on this line.

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

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


From kcr at openjdk.java.net  Mon Jan 17 13:38:28 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 17 Jan 2022 13:38:28 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs
In-Reply-To: <vdsKjgI1BwGGlKiSGgsi2Bqkm8jXROS4AYu7YhI-Rjo=.04baaa6b-23e4-4b9c-9bed-5a30b643b150@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <vdsKjgI1BwGGlKiSGgsi2Bqkm8jXROS4AYu7YhI-Rjo=.04baaa6b-23e4-4b9c-9bed-5a30b643b150@github.com>
Message-ID: <cq4iM6mEWILyhztGSrzdjrFMVfpOgCv65skShqjKINM=.82c24f81-b240-4f0b-b077-4007174e8e50@github.com>

On Mon, 17 Jan 2022 13:33:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> ...you have a typo in the HTML link.

I see that the GitHub actions run failed for the same reason.

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

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


From psadhukhan at openjdk.java.net  Mon Jan 17 14:32:59 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 14:32:59 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v2]
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>

> Fixed the broken link with appropriate link to swing document.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Typo fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7104/files
  - new: https://git.openjdk.java.net/jdk/pull/7104/files/7dc37263..efcf062c

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

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

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


From kcr at openjdk.java.net  Mon Jan 17 14:33:00 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 17 Jan 2022 14:33:00 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v2]
In-Reply-To: <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>
Message-ID: <z5WXRsrUEDDgz7_IhRY1avXvkwfZ3zVECVqi1e-wTD0=.4b9c710c-b3e0-48c5-be93-dfd50c7179cf@github.com>

On Mon, 17 Jan 2022 14:30:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

Marked as reviewed by kcr (Author).

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

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


From psadhukhan at openjdk.java.net  Mon Jan 17 14:33:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 14:33:02 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v2]
In-Reply-To: <vdsKjgI1BwGGlKiSGgsi2Bqkm8jXROS4AYu7YhI-Rjo=.04baaa6b-23e4-4b9c-9bed-5a30b643b150@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <vdsKjgI1BwGGlKiSGgsi2Bqkm8jXROS4AYu7YhI-Rjo=.04baaa6b-23e4-4b9c-9bed-5a30b643b150@github.com>
Message-ID: <k1loFqRTy1iF1KNL6SdHfmr824X1YJIvYd2g4KneA1A=.3980146c-d0e1-4250-bab8-bee46dfa41fc@github.com>

On Mon, 17 Jan 2022 13:31:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix
>
> src/java.desktop/share/classes/javax/swing/package-info.java line 135:
> 
>> 133:  * please see:
>> 134:  * <ul>
>> 135:  *     <li><a href=""https://www.oracle.com/java/technologies/a-swing-architecture.html"
> 
> Typo: you have an extra `"` on this line.

Checked..

![image](https://user-images.githubusercontent.com/43534309/149787569-d29ca513-c380-4f30-a207-a30aae7721e7.png)

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

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


From aivanov at openjdk.java.net  Mon Jan 17 14:59:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 17 Jan 2022 14:59:33 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v2]
In-Reply-To: <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>
Message-ID: <Y-fvTPQbCK78wJQvC3vqh174dUI8snN-KtjiAO9ALLM=.7b453a13-d352-4338-b437-955569ab9282@github.com>

On Mon, 17 Jan 2022 14:32:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/package-info.java line 139:

> 137:  *     <li><a href="https://docs.oracle.com/javase/tutorial/"
> 138:  *     target="_top">The Java Tutorial</a></li>
> 139:  *     <li><a href="http://www.oracle.com/technetwork/java/javase/training/index.html"

While links are updated, shall the following links be updated too?
The links redirect to another page which have different titles.

?Online Training at the Java Developer Connection? now points to ?Java SE Training and Certification? page: https://www.oracle.com/java/technologies/javase/training-support.html

?Java Foundation Classes (JFC) home page? leads to ?Java SE Desktop Overview?: https://www.oracle.com/java/technologies/javase/desktop-overview.html

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

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


From ant at openjdk.java.net  Mon Jan 17 16:28:34 2022
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 17 Jan 2022 16:28:34 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
Message-ID: <hMyQbAXfMbJc7x4a6HiDhS4a2ikYONwlJk1oRiN8BIU=.139e0fec-7b16-406d-b14a-453d43e3fcad@github.com>

On Fri, 14 Jan 2022 17:31:09 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix converting coordinates when getting GC at point
>   
>   Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

Tested your patch with NVDA 2021.3.1 and it worked well for me.

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From ant at openjdk.java.net  Mon Jan 17 16:41:37 2022
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 17 Jan 2022 16:41:37 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <FV84nJuqpv65S7NXM3GBcC-zZ-cKMPcNBOqg-ZemCYI=.475925fb-db40-41d7-8078-5ffda8a30ca5@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
 <FV84nJuqpv65S7NXM3GBcC-zZ-cKMPcNBOqg-ZemCYI=.475925fb-db40-41d7-8078-5ffda8a30ca5@github.com>
Message-ID: <2fPSObxod21vM3Awc8ofgTzCUfiS7ofPjgDE8zAZctM=.00c84e47-8565-47e1-9896-73994e68fea9@github.com>

On Fri, 14 Jan 2022 17:34:11 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> I've fixed receiving GC at given point and now hit-test and frame bounds seem to be calculated correctly. But it looks like NVDA does not work correctly with different DPI on the second display, so it (at least v. 2021.3.1) has to be started in compatibility mode, see the attached picture
> 
Seems worth reporting this to NVDA (https://github.com/nvaccess/nvda/#communication-channels).

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From kizune at openjdk.java.net  Tue Jan 18 03:19:32 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 18 Jan 2022 03:19:32 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
Message-ID: <7SSKs4MAkQrsqrETrtvqG4-Lmox2274aOGvGtk3j9vg=.cf152b10-f4fb-47b9-8998-3b52cc0f0db2@github.com>

On Fri, 14 Jan 2022 17:31:09 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix converting coordinates when getting GC at point
>   
>   Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

Tested on Windows 10 and Windows 11 with dual monitor configuration with different scale factors - last version of the fix seems to be working fine.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/72


From psadhukhan at openjdk.java.net  Tue Jan 18 05:10:57 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 05:10:57 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>

> Fixed the broken link with appropriate link to swing document.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix other links

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7104/files
  - new: https://git.openjdk.java.net/jdk/pull/7104/files/efcf062c..edcb840a

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

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 05:10:59 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 05:10:59 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v2]
In-Reply-To: <Y-fvTPQbCK78wJQvC3vqh174dUI8snN-KtjiAO9ALLM=.7b453a13-d352-4338-b437-955569ab9282@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <CVct2Ct9RCDgheSBGxKlQsXT4osntxGcOxQGhOOz_ls=.d729de3c-14da-480a-8dbb-52a968e1c31d@github.com>
 <Y-fvTPQbCK78wJQvC3vqh174dUI8snN-KtjiAO9ALLM=.7b453a13-d352-4338-b437-955569ab9282@github.com>
Message-ID: <fvlPIma6rvqk_IeZGufvyHT_06gR0PUq5zSOnyc2EFE=.4a8b6b85-ddce-4660-92ed-4d26e42d8092@github.com>

On Mon, 17 Jan 2022 14:55:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix
>
> src/java.desktop/share/classes/javax/swing/package-info.java line 139:
> 
>> 137:  *     <li><a href="https://docs.oracle.com/javase/tutorial/"
>> 138:  *     target="_top">The Java Tutorial</a></li>
>> 139:  *     <li><a href="http://www.oracle.com/technetwork/java/javase/training/index.html"
> 
> While links are updated, shall the following links be updated too?
> The links redirect to another page which have different titles.
> 
> ?Online Training at the Java Developer Connection? now points to ?Java SE Training and Certification? page: https://www.oracle.com/java/technologies/javase/training-support.html
> 
> ?Java Foundation Classes (JFC) home page? leads to ?Java SE Desktop Overview?: https://www.oracle.com/java/technologies/javase/desktop-overview.html

fixed other links

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

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


From aivanov at openjdk.java.net  Tue Jan 18 11:44:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 11:44:28 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
Message-ID: <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>

On Tue, 18 Jan 2022 05:10:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix other links

src/java.desktop/share/classes/javax/swing/package-info.java line 143:

> 141:  *     at the Java Developer Connection <sup>SM</sup></li>
> 142:  *     <li><a href="https://www.oracle.com/java/technologies/java-foundation-classes.html"
> 143:  *     target="_top">Java Foundation Classes (JFC)</a> home page</li>

Hm, I think this page is too outdated by now. It talks about JDK 1.4.0. It's completely irrelevant for JDK 19, is it?

Shall this link be dropped altogether?

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 11:51:24 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 11:51:24 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
Message-ID: <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>

On Tue, 18 Jan 2022 11:41:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix other links
>
> src/java.desktop/share/classes/javax/swing/package-info.java line 143:
> 
>> 141:  *     at the Java Developer Connection <sup>SM</sup></li>
>> 142:  *     <li><a href="https://www.oracle.com/java/technologies/java-foundation-classes.html"
>> 143:  *     target="_top">Java Foundation Classes (JFC)</a> home page</li>
> 
> Hm, I think this page is too outdated by now. It talks about JDK 1.4.0. It's completely irrelevant for JDK 19, is it?
> 
> Shall this link be dropped altogether?

Maybe we can use https://www.oracle.com/java/technologies/foundation-classes-faq.html

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

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


From aivanov at openjdk.java.net  Tue Jan 18 12:01:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 12:01:23 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
Message-ID: <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>

On Tue, 18 Jan 2022 11:48:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/package-info.java line 143:
>> 
>>> 141:  *     at the Java Developer Connection <sup>SM</sup></li>
>>> 142:  *     <li><a href="https://www.oracle.com/java/technologies/java-foundation-classes.html"
>>> 143:  *     target="_top">Java Foundation Classes (JFC)</a> home page</li>
>> 
>> Hm, I think this page is too outdated by now. It talks about JDK 1.4.0. It's completely irrelevant for JDK 19, is it?
>> 
>> Shall this link be dropped altogether?
>
> Maybe we can use https://www.oracle.com/java/technologies/foundation-classes-faq.html

Yeah, this looks better. JFC is Swing, so the FAQ page uses an outdated term. Related links at the bottom of the page leads to J2SE 1.4.2 as a popular downloads.

Thus, I'm for removing the link.

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 12:10:21 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 12:10:21 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
 <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
Message-ID: <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>

On Tue, 18 Jan 2022 11:58:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Maybe we can use https://www.oracle.com/java/technologies/foundation-classes-faq.html
>
> Yeah, this looks better. JFC is Swing, so the FAQ page uses an outdated term. Related links at the bottom of the page leads to J2SE 1.4.2 as a popular downloads.
> 
> Thus, I'm for removing the link.

Yes, the page looks outdated.. I don't think any new content has been added post jdk1.4.2.
I can remove the link. 
In fact, I think the "JavaSE Training" link also is not relevant in this swing package, maybe it should be put in overall parent overview page.

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 12:18:55 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 12:18:55 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v4]
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <HRP6FlyEj1_duw7c2JOf3JyWUypKTWGkFaHd0Yhk8oc=.6c0382c3-7d3d-4423-bde7-c3a21ddae8d4@github.com>

> Fixed the broken link with appropriate link to swing document.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove JFC link

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7104/files
  - new: https://git.openjdk.java.net/jdk/pull/7104/files/edcb840a..2d1a478e

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

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

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


From aivanov at openjdk.java.net  Tue Jan 18 12:25:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 12:25:23 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
 <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
 <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>
Message-ID: <fai8ASx5ntpK4fYVcRGpgccWkw8TafNlNViN5iFs5S8=.ead80c61-913e-4581-8669-fa69a1d10665@github.com>

On Tue, 18 Jan 2022 12:07:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In fact, I think the "JavaSE Training" link also is not relevant in this swing package, maybe it should be put in overall parent overview page.

Yeah, I agree it's not relevant for Swing.

Do you refer to [Java SE at a Glance](https://www.oracle.com/java/technologies/java-se-glance.html)?

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

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


From aivanov at openjdk.java.net  Tue Jan 18 12:29:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 12:29:23 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <fai8ASx5ntpK4fYVcRGpgccWkw8TafNlNViN5iFs5S8=.ead80c61-913e-4581-8669-fa69a1d10665@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
 <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
 <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>
 <fai8ASx5ntpK4fYVcRGpgccWkw8TafNlNViN5iFs5S8=.ead80c61-913e-4581-8669-fa69a1d10665@github.com>
Message-ID: <-2YhU6y36mCmNvDZeJEiUQ964x6oXoxAsc5DXayykas=.f298bb9a-3e41-4bb5-8fc5-29d51be0bf67@github.com>

On Tue, 18 Jan 2022 12:22:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, the page looks outdated.. I don't think any new content has been added post jdk1.4.2.
>> I can remove the link. 
>> In fact, I think the "JavaSE Training" link also is not relevant in this swing package, maybe it should be put in overall parent overview page.
>
>> In fact, I think the "JavaSE Training" link also is not relevant in this swing package, maybe it should be put in overall parent overview page.
> 
> Yeah, I agree it's not relevant for Swing.
> 
> Do you refer to [Java SE at a Glance](https://www.oracle.com/java/technologies/java-se-glance.html)?

[Java SE Desktop Overview](https://www.oracle.com/java/technologies/javase/desktop-overview.html) is relevant as the overview of all desktop related technologies in Java. Yet it's not specifically about Swing. As such, this page fits for java.desktop module description better.

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 12:29:23 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 12:29:23 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <-2YhU6y36mCmNvDZeJEiUQ964x6oXoxAsc5DXayykas=.f298bb9a-3e41-4bb5-8fc5-29d51be0bf67@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
 <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
 <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>
 <fai8ASx5ntpK4fYVcRGpgccWkw8TafNlNViN5iFs5S8=.ead80c61-913e-4581-8669-fa69a1d10665@github.com>
 <-2YhU6y36mCmNvDZeJEiUQ964x6oXoxAsc5DXayykas=.f298bb9a-3e41-4bb5-8fc5-29d51be0bf67@github.com>
Message-ID: <N8aWPODyKfjEef8mq9toLdCJfimhntOTW825okSUVCY=.5b98bbe7-32a3-45ab-87da-e6965bcf5c9b@github.com>

On Tue, 18 Jan 2022 12:25:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> In fact, I think the "JavaSE Training" link also is not relevant in this swing package, maybe it should be put in overall parent overview page.
>> 
>> Yeah, I agree it's not relevant for Swing.
>> 
>> Do you refer to [Java SE at a Glance](https://www.oracle.com/java/technologies/java-se-glance.html)?
>
> [Java SE Desktop Overview](https://www.oracle.com/java/technologies/javase/desktop-overview.html) is relevant as the overview of all desktop related technologies in Java. Yet it's not specifically about Swing. As such, this page fits for java.desktop module description better.

I guess in same way, it's more relevant to https://docs.oracle.com/en/java/javase/17/docs/api/index.html page

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

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


From aivanov at openjdk.java.net  Tue Jan 18 12:41:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 12:41:25 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v4]
In-Reply-To: <HRP6FlyEj1_duw7c2JOf3JyWUypKTWGkFaHd0Yhk8oc=.6c0382c3-7d3d-4423-bde7-c3a21ddae8d4@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <HRP6FlyEj1_duw7c2JOf3JyWUypKTWGkFaHd0Yhk8oc=.6c0382c3-7d3d-4423-bde7-c3a21ddae8d4@github.com>
Message-ID: <E6FOHp5VGYlNlUzeQvAF2sWqPJLtIHg_b-T2UmbPeEY=.d8379a79-3011-40f0-a1d5-c8840ca59ff8@github.com>

On Tue, 18 Jan 2022 12:18:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JFC link

Marked as reviewed by aivanov (Reviewer).

Shall the copyright year be updated?

src/java.desktop/share/classes/javax/swing/package-info.java line 141:

> 139:  *     <li><a href="https://www.oracle.com/java/technologies/javase/training-support.html"
> 140:  *     target="_top">Java SE Training and Certification</a>
> 141:  *     at the Java Developer Connection <sup>SM</sup></li>

I don't have a strong opinion whether this link should be here. Maybe not, as you mentioned.

If it's kept, I think the part `at the Java Developer Connection <sup>SM</sup>` should be removed.

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

PR: https://git.openjdk.java.net/jdk/pull/7104Changes requested by aivanov (Reviewer).


From aivanov at openjdk.java.net  Tue Jan 18 12:41:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 12:41:25 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v3]
In-Reply-To: <N8aWPODyKfjEef8mq9toLdCJfimhntOTW825okSUVCY=.5b98bbe7-32a3-45ab-87da-e6965bcf5c9b@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ezGLqa7ZKnurIF2g6_wiXD6RoO8dSO51TlYtUVxhZQg=.423b0ef3-93e5-459c-b6e7-fc9d63efc372@github.com>
 <SM9tr87ZB8DT7EOofxWAuOnYdZVeN-iR8dsHGZ0rDvg=.22a86fe5-dbfa-4e50-8c61-48229263721f@github.com>
 <2i7GielV-GUPeKdvySR5POQF6DBigtr2WZGVdjNG6zA=.ffbfbd3d-cc05-4e23-a794-7de956ef4f27@github.com>
 <TdXZDsxui17SD22eUe0UxM9JOIkGFijkyMiUO-tcJSc=.83879610-4f78-4d7b-91f7-a6008ccf25d7@github.com>
 <4OUUmtsfNSzrGLbQWlS6S0DoqI_1VGoN3iF2GewpRyM=.b886a342-64bb-4790-b1ad-9d8f56085a57@github.com>
 <fai8ASx5ntpK4fYVcRGpgccWkw8TafNlNViN5iFs5S8=.ead80c61-913e-4581-8669-fa69a1d10665@github.com>
 <-2YhU6y36mCmNvDZeJEiUQ964x6oXoxAsc5DXayykas=.f298bb9a-3e41-4bb5-8fc5-29d51be0bf67@github.com>
 <N8aWPODyKfjEef8mq9toLdCJfimhntOTW825okSUVCY=.5b98bbe7-32a3-45ab-87da-e6965bcf5c9b@github.com>
Message-ID: <ocmUjk8C9d5SJwbBOeJ09MZt_tQfVgvD7w_faYKME30=.a52e7798-1da9-4a40-bc79-f334f0c9d2cf@github.com>

On Tue, 18 Jan 2022 12:26:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess in same way, it's more relevant to https://docs.oracle.com/en/java/javase/17/docs/api/index.html page

Yep!

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

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


From dmarkov at openjdk.java.net  Tue Jan 18 12:59:41 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 18 Jan 2022 12:59:41 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
Message-ID: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>

When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.

Fix:
It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).

Testing:
mach5 green

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

Commit messages:
 - 8274751: Drag And Drop hangs on Windows

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

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


From psadhukhan at openjdk.java.net  Tue Jan 18 13:03:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 18 Jan 2022 13:03:07 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v5]
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <E44F26wotFhYiaO9xllr2gmb_ZUC-gVVylFt5p8JjLc=.894c764c-2de9-4b73-8396-76c50ebb15ca@github.com>

> Fixed the broken link with appropriate link to swing document.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Remove unneeded mentions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7104/files
  - new: https://git.openjdk.java.net/jdk/pull/7104/files/2d1a478e..961158fc

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

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

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


From aivanov at openjdk.java.net  Tue Jan 18 14:11:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 14:11:33 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <wY4_CnkV6MGhCmyMGdPWXJ0lXjOmylHqL8HCKORWOAk=.c26911af-12b7-4db6-ae17-5ae0119a5ee8@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Tue Jan 18 15:14:27 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 15:14:27 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v5]
In-Reply-To: <E44F26wotFhYiaO9xllr2gmb_ZUC-gVVylFt5p8JjLc=.894c764c-2de9-4b73-8396-76c50ebb15ca@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <E44F26wotFhYiaO9xllr2gmb_ZUC-gVVylFt5p8JjLc=.894c764c-2de9-4b73-8396-76c50ebb15ca@github.com>
Message-ID: <slnl08Tq-D9j9tnChRR3XzedhV1C5ZXejarMk8mpbUk=.3df8ff30-41a5-400a-8997-82db11da3e07@github.com>

On Tue, 18 Jan 2022 13:03:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Remove unneeded mentions

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/package-info.java line 140:

> 138:  *     target="_top">The Java Tutorial</a></li>
> 139:  *     <li><a href="https://www.oracle.com/java/technologies/javase/training-support.html"
> 140:  *     target="_top">Java SE Training and Certification</a>

Suggestion:

 *     target="_top">Java SE Training and Certification</a></li>

The closing `</li>` is not required but it's used in other `<li>` elements in this list.

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

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


From aivanov at openjdk.java.net  Tue Jan 18 15:28:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 15:28:37 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
Message-ID: <0dHzHeQGNwvw4Zu8K1p_f2kIqfBtZ7MxgfQNGcWtpsY=.a4bd426a-5461-4ac7-a4af-e6536a4af7ca@github.com>

On Fri, 14 Jan 2022 17:31:09 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix converting coordinates when getting GC at point
>   
>   Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From aturbanov at openjdk.java.net  Tue Jan 18 15:52:31 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 18 Jan 2022 15:52:31 GMT
Subject: Integrated: 8280010: Remove double buffering of InputStream for
 Properties.load
In-Reply-To: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
References: <hvQNz7zmDzGQVW742KM0FiPSODMUsyd6FMYrQYdEyFQ=.476c439f-e60b-40d3-8bcc-e60a799ee12d@github.com>
Message-ID: <c-3BkaHdJ29HMIl0SPYfTIUWgo4A39B4LeoXMZ-HzBk=.17bf155a-85b4-4d6c-8f1f-079861febf26@github.com>

On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant.

This pull request has now been integrated.

Changeset: 9eb50a5e
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9eb50a5ee4a069fbb248748ebee09132e2450420
Stats:     30 lines in 8 files changed: 0 ins; 11 del; 19 mod

8280010: Remove double buffering of InputStream for Properties.load

Reviewed-by: amenkov, sspitsyn, serb

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

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


From aivanov at openjdk.java.net  Tue Jan 18 16:58:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 16:58:39 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v2]
In-Reply-To: <5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <uuK5svog9pn3o50Ovi9iFnGMsuwzFAuCPoPSHMO2n50=.88d07c22-1da4-4545-a105-178eb14d7e62@github.com>
 <5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>
Message-ID: <CBLPoeDXPJHJND52uKOSpix10kserr_L38Vr2_XuKAs=.f4b6bcff-3c16-49c5-85b4-f7f79f72312d@github.com>

On Mon, 17 Jan 2022 05:26:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
>> 
>>> 148: 
>>> 149:     /**
>>> 150:      * Start UndoableEdit.
>> 
>> What does it mean? Is it clear enough for the class which "managing <code>UndoableEdit</code> listeners"?
>
> It seems it other places like CompoundEdit class, "assemble little UndoableEdits " statement is used so it seems ok to use UndoableEdit here. At least it's better than (to me)
> 
> "DEADLOCK WARNING: Calling this method may call
>      * <code>undoableEditHappened</code> in all listeners."
> 
>    
>  used in endUpdate...

Can we update the docs for those methods with a more meaningful description? In a separate issue.

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

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


From aivanov at openjdk.java.net  Tue Jan 18 16:58:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 16:58:39 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v2]
In-Reply-To: <MNDCgDC6RsrQTW48vM1551nTAm3eUf0M1AaLUIkCviM=.260eb86b-54be-4549-8d3f-9bf3f9988a2d@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <MNDCgDC6RsrQTW48vM1551nTAm3eUf0M1AaLUIkCviM=.260eb86b-54be-4549-8d3f-9bf3f9988a2d@github.com>
Message-ID: <hn54hkGxAwRaj89ZFqYCLZyE64JKbwJM6NlSd2r0Z4c=.c2638552-a303-4450-82ea-e6f018b79693@github.com>

On Mon, 17 Jan 2022 05:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 67:

> 65:      * Returns the imaga capabilities of the front (displayed) buffer.
> 66:      *
> 67:      * @return the imaga capabilities of the front (displayed) buffer

Typo
Suggestion:

     * Returns the image capabilities of the front (displayed) buffer.
     *
     * @return the image capabilities of the front (displayed) buffer

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 75:

> 73:     /**
> 74:      * Returns the image capabilities of all back buffers (intermediate buffers
> 75:      * are considered back buffers)

Missing full stop.
Suggestion:

     * Returns the image capabilities of all back buffers (intermediate buffers
     * are considered back buffers).

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 85:

> 83: 
> 84:     /**
> 85:      * Returns whether or not the buffer strategy uses page flipping; a set of

I am for simplified form which implies the same:
Suggestion:

     * Returns whether the buffer strategy uses page flipping; a set of


Probably there should be full stop after ?flipping?. Javadoc uses the first sentence to provide a short summary of the method description. Without the full stop, the description is overly detailed. What do you think?

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 92:

> 90:      * buffers uses blitting to copy the contents from one buffer to
> 91:      * another; when this is the case, {@code getFlipContents} returns
> 92:      * {@code null}

Suggestion:

     * {@code null}.

Full stop to end the sentence.

src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 136:

> 134:      * Returns whether or not
> 135:      * page flipping can be performed using more than two buffers (one or more
> 136:      * intermediate buffers as well as the front and back buffer).

I'd rather re-flow both the description and `@return` tag description, the latter could omit the text in the parentheses.

src/java.desktop/share/classes/java/awt/Component.java line 4137:

> 4135:          * Gets direct access to the back buffer, as an image.
> 4136:          *
> 4137:          * @return direct access to the back buffer, as an image.

Suggestion:

         * Provides direct access to the back buffer as an image.
         *
         * @return direct access to the back buffer as an image.


The comma before ?as? makes the description confusing.

src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:

> 651:     /* For European keyboards */
> 652:     /**
> 653:      * Constant for the DEAD_GRAVE key.

A suggestion: use the key description rather than constant.
Suggestion:

     * Constant for the Dead Grave key.

This is more human-friendly in my opinion. The names of the keys could be found at [KeyEvent line 1591](https://github.com/openjdk/jdk/blob/765c414752076cdf5d893364fb648b478d97523f/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L1591). They're really key name with first letters capitalised and spaces instead of underscores.

src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 779:

> 777: 
> 778:     /**
> 779:      * Constant for the BRACELEFT key.

Suggestion:

     * Constant for the "{" key.

src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 785:

> 783: 
> 784:     /**
> 785:      * Constant for the BRACERIGHT key.

Suggestion:

     * Constant for the "}" key.

src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 1018:

> 1016:     /* for Sun keyboards */
> 1017:     /**
> 1018:      * Constant for the "CUT" key.

I'd rather capitalise only the first letter of the key name.

src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 161:

> 159:     /**
> 160:      * protected nested class containing per child information
> 161:      * in the "children" hashtable.

Suggestion:

     * A protected nested class containing per-child information
     * in the {@code children} hashtable.

src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 794:

> 792: 
> 793:     /**
> 794:      * subclasses may subclass this nested class to represent proxy for

Suggestion:

     * Subclasses may subclass this nested class to represent a proxy for

src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java line 309:

> 307:     /**
> 308:      * protected nested class containing per child information
> 309:      * in the "children" hashtable.

Suggestion:

     * A protected nested class containing per-child information
     * in the {@code children} hashtable.

src/java.desktop/share/classes/javax/swing/JApplet.java line 109:

> 107:     /**
> 108:      * The <code>JRootPane</code> instance that manages the
> 109:      * <code>contentPane</code>

Suggestion:

     * <code>contentPane</code>.

src/java.desktop/share/classes/javax/swing/JDialog.java line 115:

> 113:     /**
> 114:      * The <code>JRootPane</code> instance that manages the
> 115:      * <code>contentPane</code>

Suggestion:

     * <code>contentPane</code>.

src/java.desktop/share/classes/javax/swing/JScrollBar.java line 111:

> 109: 
> 110:     /**
> 111:      * Orientation for this scrollBar

Suggestion:

     * Orientation of this scrollbar.

src/java.desktop/share/classes/javax/swing/JScrollBar.java line 120:

> 118:     /**
> 119:      * Amount to change the scrollbar's value by,
> 120:      * given a unit up/down request.

Suggestion:

     * The amount to change the value of the scrollbar by,
     * given a unit up/down request.

However, this still looks cumbersome and is not as clear.

src/java.desktop/share/classes/javax/swing/JScrollBar.java line 129:

> 127:     /**
> 128:      * Amount to change the scrollbar's value by,
> 129:      * given a block (usually "page") up/down request.

Suggestion:

     * The amount to change the value of the scrollbar by,
     * given a block (usually "page") up/down request.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:

> 351:      * File(parent, fileName)</code> except when parent and child are both
> 352:      * special folders, in which case the <code>File</code> is a wrapper containing
> 353:      * a <code>ShellFolder</code> object.

Suggestion:

     * Returns a <code>File</code> object which is normally constructed with <code>new
     * File(parent, fileName)</code> except when the parent and child are both
     * special folders in which case the <code>File</code> is a wrapper containing
     * a <code>ShellFolder</code> object.

Does it make sense to simplify the description of `@return` tag?

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 928:

> 926: 
> 927:     /**
> 928:      * The class represents the border of a {@code JTextField}.

Suggestion:

     * Border for a {@code JTextField}.

Such a description is used for other classes which aren't public.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1029:

> 1027: 
> 1028:     /**
> 1029:      * The class represents the border of a {@code JToggleButton}.

Suggestion:

     * Border for a {@code JToggleButton}.

src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java line 32:

> 30: /**
> 31:  * Highlighter interface to mark up the background of leaf views
> 32:  * with colored areas.

Suggestion:

 * Implementation of {@code Highlighter} interface to mark up the background of leaf views
 * with colored areas.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1686:

> 1684: 
> 1685:         /**
> 1686:          * Returns <code>HTMLDocument</code> of given <code>JEditorPane</code>.

Suggestion:

         * Returns <code>HTMLDocument</code> of the given <code>JEditorPane</code>.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1700:

> 1698: 
> 1699:         /**
> 1700:          * Returns HTMLEditorKit of given <code>JEditorPane</code>.

Suggestion:

         * Returns HTMLEditorKit of the given <code>JEditorPane</code>.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 113:

> 111: 
> 112:     /**
> 113:      * Return the attribute name.

Suggestion:

     * Returns the attribute name.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 122:

> 120: 
> 121:     /**
> 122:      * Return the attribute type.

Suggestion:

     * Returns the attribute type.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 132:

> 130: 
> 131:     /**
> 132:      * Return attribute modifier.

Suggestion:

     * Returns the attribute modifier.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 142:

> 140: 
> 141:     /**
> 142:      * Return possible attribute values.

Suggestion:

     * Returns possible attribute values.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 151:

> 149: 
> 150:     /**
> 151:      * Return default attribute value.

Suggestion:

     * Returns the default attribute value.

src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 160:

> 158: 
> 159:     /**
> 160:      * Return the next attribute in the list.

Suggestion:

     * Returns the next attribute in the list.

src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:

> 148: 
> 149:     /**
> 150:      * Start UndoableEdit.

Suggestion:

     * Starts a compound update.

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

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


From aivanov at openjdk.java.net  Tue Jan 18 17:14:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 17:14:33 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs
In-Reply-To: <U5jIa9QlCxqulEKEV3b7iXA8umLewioTYcomqKlAjOQ=.049c2434-5a78-4434-a24f-a65297726037@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
 <U5jIa9QlCxqulEKEV3b7iXA8umLewioTYcomqKlAjOQ=.049c2434-5a78-4434-a24f-a65297726037@github.com>
Message-ID: <NosPNZYXghkiSZtgHechbqtw-oi01RLFfnKff0J3yII=.39e26572-f43f-4915-8cf3-2230a766cb0e@github.com>

On Wed, 12 Jan 2022 02:40:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
>> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
>> 
>> I also organised the imports which replaced all wildcard imports with specific class imports.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 73:
> 
>> 71: import javax.swing.plaf.FileChooserUI;
>> 72: import javax.swing.plaf.UIResource;
>> 73: 
> 
> I see that you added a line between different top packages, I use the same style, but then it will make sense to do the same for java -> javax above.

Hm? Usually, there's no blank line between java- and javax- packages. Or I may have missed that it's the common practice.

In fact, I was thinking about adding a blank line in this case because the list of classes imported from either package is large.

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

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


From aivanov at openjdk.java.net  Tue Jan 18 17:28:59 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 17:28:59 GMT
Subject: RFR: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent [v2]
In-Reply-To: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
References: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
Message-ID: <_cWedB2n1mwbAj8LpAXhGfNRXq5urm8Hl3KIanQ3qtk=.f3fe5d77-476b-4fa8-9d41-33685b76a2c0@github.com>

> A number of methods in BasicTabbedPaneUI uses the imperative form of the verb in the documentation instead of the third-person form which describes what the method does.
> 
> For consistency, I updated such descriptions to use the third-person form of the verb.
> 
> I fixed a couple of typos as well.
> 
> I also expanded all the wildcard imports into the specific ones.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Add a blank line between java- and javax-package classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7031/files
  - new: https://git.openjdk.java.net/jdk/pull/7031/files/9c0ec1ce..16230b72

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

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

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


From aivanov at openjdk.java.net  Tue Jan 18 17:29:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 17:29:07 GMT
Subject: RFR: 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical
 scroll bar [v2]
In-Reply-To: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
References: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
Message-ID: <3wi2kDHqmbcSHfe0Q6PGD4sWHLjQ2o4_saALPipQMqE=.336472cc-6584-434e-ba4d-df6a06ba41a2@github.com>

> Fixed the typo in the layout methods: ?Laysouts a?? ? ?Lays out a??.
> 
> The doc for `layoutHScrollbar` incorrectly referred to _vertical_ scroll bar rather than horizontal one.
> 
> 
> I also expanded the wildcard imports.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Add a blank line between java- and javax-package classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7032/files
  - new: https://git.openjdk.java.net/jdk/pull/7032/files/f5f6be2b..c1806007

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

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

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


From aivanov at openjdk.java.net  Tue Jan 18 17:29:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 17:29:11 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs [v2]
In-Reply-To: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
Message-ID: <Jm1w5ZVocLQHdqMIHqPIkN4t3ZycHhfU_JFE3Lk_wj0=.21f6ad61-c92e-4637-97a7-1101bb80f541@github.com>

> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
> 
> I also organised the imports which replaced all wildcard imports with specific class imports.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Add a blank line between java- and javax-package classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7030/files
  - new: https://git.openjdk.java.net/jdk/pull/7030/files/5b3e30f3..a705befd

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

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

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


From prr at openjdk.java.net  Tue Jan 18 17:55:32 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 18 Jan 2022 17:55:32 GMT
Subject: RFR: 6465404: some problems in CellEditor related API docs [v6]
In-Reply-To: <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
 <WRC9Z9m84KB7ziLtEnd7X9qV27QZpc78F4fOvGGkkXs=.e5dc3308-d589-4a65-a82e-9d06073e33f8@github.com>
Message-ID: <KDY1UA0D3RWjlE50P-KrqMilbDjNAohCbbed9pBdr4I=.9fde2c28-c42b-4e1e-95e2-fd788d4a9100@github.com>

On Wed, 22 Dec 2021 11:13:56 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6465404: some problems in CellEditor related API docs

Marked as reviewed by prr (Reviewer).

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

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


From ant at openjdk.java.net  Tue Jan 18 18:23:39 2022
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 18 Jan 2022 18:23:39 GMT
Subject: [jdk18] RFR: 8279227: Access Bridge: Wrong frame position and hit
 test result on HiDPI display [v4]
In-Reply-To: <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
 <9SrlrZDlspZZHQWwQ7fCQiTQLCZExLkr6JsFAiAdK1Q=.1a731e33-8a12-4ac4-b357-a583e6379f73@github.com>
Message-ID: <lzyEVfL7AJ6Ep4rwl5KEs_br0Jw0DGWn6SZolnwk3WU=.fb5062d5-dffb-4a69-a14d-265a0bfae2f1@github.com>

On Fri, 14 Jan 2022 17:31:09 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

>> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.
>
> Aleksandr Veselov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix converting coordinates when getting GC at point
>   
>   Also move GraphicsConfiguration search into AccessibilityGraphicsEnvironment

Based on 2 reviews and successful testing I'm integrating this fix (we are approaching RDP2 for JDK18).

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From duke at openjdk.java.net  Tue Jan 18 18:55:26 2022
From: duke at openjdk.java.net (Aleksandr Veselov)
Date: Tue, 18 Jan 2022 18:55:26 GMT
Subject: [jdk18] Integrated: 8279227: Access Bridge: Wrong frame position and
 hit test result on HiDPI display
In-Reply-To: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
References: <A2bWRcf8m0ixumLSQtfLWEXpqZCTPdt0b6SqZ1xM-I8=.b8a9f590-859e-4926-aa7a-bd27cf0ae9f0@github.com>
Message-ID: <rTuVwjjKy7aAqN8fkVj1pZVETQD26U-jLB3vPy-CJCE=.3d2494f7-f289-41e7-bdc0-c7e0011a0bac@github.com>

On Fri, 24 Dec 2021 09:51:14 GMT, Aleksandr Veselov <duke at openjdk.java.net> wrote:

> Perform scaling while converting sizes and coordinates to provide correct positions of accessible elements on HiDPI screen and make hit-test work properly. It uses FontRenderContext to receive display scale without API changes.

This pull request has now been integrated.

Changeset: 20ef9541
Author:    Aleksandr Veselov <aleksandr.veselov at jetbrains.com>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/20ef954158bc5a339118640946b39047fe853ae4
Stats:     185 lines in 1 file changed: 185 ins; 0 del; 0 mod

8279227: Access Bridge: Wrong frame position and hit test result on HiDPI display

Reviewed-by: ant, kizune, aivanov

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

PR: https://git.openjdk.java.net/jdk18/pull/72


From achung at openjdk.java.net  Tue Jan 18 18:59:58 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Tue, 18 Jan 2022 18:59:58 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v14]
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <wJuKBa_mpAZcGOHqhGD4AIew-Q53uglSI0_-ogFH07w=.1e77eb93-dd81-4741-af2c-0bfee1eeb793@github.com>

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  made suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6374/files
  - new: https://git.openjdk.java.net/jdk/pull/6374/files/9d2f71ba..4ae530be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6374&range=12-13

  Stats: 56 lines in 2 files changed: 18 ins; 14 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6374.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6374/head:pull/6374

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


From cushon at openjdk.java.net  Tue Jan 18 21:02:44 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 18 Jan 2022 21:02:44 GMT
Subject: RFR: 8280054: BadSerializationTest and
 DragGestureEvent/DragGestureRecognizer constructors
Message-ID: <hYkHCEJK_Hi2MR2trNzd0ZWWHk51VzvTvddIB9COzPs=.74cc983b-d21b-4370-af18-32dd61f8efb7@github.com>

Please consider this enhancement to `test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java`, which simplifies the process of manually generating serialized test data by using reflection to generate invalid instances of `DragGestureEvent` and `DragGestureRecognizer`, instead of relying on patching the constructors of those classes to disable validation checks.

This cleanup was proposed in the review for a possible fix for [JDK-8277817](https://bugs.openjdk.java.net/browse/JDK-8277817): https://git.openjdk.java.net/jdk/pull/6603#issuecomment-997054470

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

Commit messages:
 - 8280054: BadSerializationTest and DragGestureEvent/DragGestureRecognizer constructors

Changes: https://git.openjdk.java.net/jdk/pull/7099/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7099&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280054
  Stats: 57 lines in 1 file changed: 25 ins; 11 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7099.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7099/head:pull/7099

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


From kizune at openjdk.java.net  Wed Jan 19 04:44:30 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 19 Jan 2022 04:44:30 GMT
Subject: RFR: 8279894: javax/swing/JInternalFrame/8020708/bug8020708.java
 timeouts on Windows 11
In-Reply-To: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
References: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
Message-ID: <yr_qQVnAPLXXB9gsR6ZOGzy5tQtN1z4-chU0r4vKdPg=.a1f0cafd-fc16-487a-8dc8-4fbb8dc8a68a@github.com>

On Thu, 13 Jan 2022 07:44:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is timing out on slower windows11 CI system. Increased the timeout and also adjusted autodelay time to more consistent time with other headful tests which makes test pass in windows11.
> Test job link in JBS.

Marked as reviewed by kizune (Reviewer).

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

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


From duke at openjdk.java.net  Wed Jan 19 05:36:31 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 19 Jan 2022 05:36:31 GMT
Subject: Integrated: 6465404: some problems in CellEditor related API docs
In-Reply-To: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
References: <15Kvi9XA-JBxlPt7OAn_G3_NWVuWC7T1fZ8w5gJEQtg=.7755e774-4347-41d9-987a-0c02dc78fa84@github.com>
Message-ID: <_RFpPguKsbARUHNp80NDx8b7diS45x83TQ3lj7cKlno=.6e1ebab9-c5a1-46ee-9530-2822945cb8b8@github.com>

On Tue, 30 Nov 2021 08:49:19 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> JListBox is invalid component. CellTableEditor Interface doesn't support JComboBox and JTree components. Hence its removed from Documentation.

This pull request has now been integrated.

Changeset: 44fe958c
Author:    TejeshR13 <tejesh.r at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/44fe958c8a924dda436125716b164a335199e22b
Stats:     6 lines in 1 file changed: 0 ins; 2 del; 4 mod

6465404: some problems in CellEditor related API docs

Reviewed-by: psadhukhan, aivanov, kizune, serb, prr

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

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


From psadhukhan at openjdk.java.net  Wed Jan 19 06:21:04 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 19 Jan 2022 06:21:04 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v6]
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <ONAGj3BVSzAJs75LtYyC2OHylMJgATFCOKQenvkVPjg=.2f72ba3a-eaff-47ce-941f-d08f41eff744@github.com>

> Fixed the broken link with appropriate link to swing document.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add closing tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7104/files
  - new: https://git.openjdk.java.net/jdk/pull/7104/files/961158fc..47056ac2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7104&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7104&range=04-05

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

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


From psadhukhan at openjdk.java.net  Wed Jan 19 06:21:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 19 Jan 2022 06:21:08 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v5]
In-Reply-To: <slnl08Tq-D9j9tnChRR3XzedhV1C5ZXejarMk8mpbUk=.3df8ff30-41a5-400a-8997-82db11da3e07@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <E44F26wotFhYiaO9xllr2gmb_ZUC-gVVylFt5p8JjLc=.894c764c-2de9-4b73-8396-76c50ebb15ca@github.com>
 <slnl08Tq-D9j9tnChRR3XzedhV1C5ZXejarMk8mpbUk=.3df8ff30-41a5-400a-8997-82db11da3e07@github.com>
Message-ID: <HSPdy068xg-pa4-VT5Q4_QzlSJroxXKoLAcyHCAfeY0=.59685255-5670-451a-a914-3da23160b437@github.com>

On Tue, 18 Jan 2022 15:10:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Remove unneeded mentions
>
> src/java.desktop/share/classes/javax/swing/package-info.java line 140:
> 
>> 138:  *     target="_top">The Java Tutorial</a></li>
>> 139:  *     <li><a href="https://www.oracle.com/java/technologies/javase/training-support.html"
>> 140:  *     target="_top">Java SE Training and Certification</a>
> 
> Suggestion:
> 
>  *     target="_top">Java SE Training and Certification</a></li>
> 
> The closing `</li>` is not required but it's used in other `<li>` elements in this list.

done

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

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


From mbaesken at openjdk.java.net  Wed Jan 19 09:25:40 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 19 Jan 2022 09:25:40 GMT
Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests
Message-ID: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>

Very small change fixing wrong strings "Falied" in a couple of tests.

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

Commit messages:
 - JDK-8280157

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

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


From dbatrak at openjdk.java.net  Wed Jan 19 10:31:27 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 19 Jan 2022 10:31:27 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <JmYLOyPlaFN04xrnQ82kKRUofpCTt9KWK_pylwcthjU=.8b9df173-86af-41c1-aa39-e586b332d00f@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Needs one more review, please.

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

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


From aivanov at openjdk.java.net  Wed Jan 19 10:52:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 10:52:25 GMT
Subject: RFR: 8280047: Broken link to Swing Connection document from
 javax.swing package docs [v6]
In-Reply-To: <ONAGj3BVSzAJs75LtYyC2OHylMJgATFCOKQenvkVPjg=.2f72ba3a-eaff-47ce-941f-d08f41eff744@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
 <ONAGj3BVSzAJs75LtYyC2OHylMJgATFCOKQenvkVPjg=.2f72ba3a-eaff-47ce-941f-d08f41eff744@github.com>
Message-ID: <tEXWLxhcQv2J77OUkII8wUB6xa69KOo-hotjOYswKAE=.454425b1-8236-447d-9bb7-8bc8ea9de01b@github.com>

On Wed, 19 Jan 2022 06:21:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fixed the broken link with appropriate link to swing document.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add closing tag

Marked as reviewed by aivanov (Reviewer).

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

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


From egahlin at openjdk.java.net  Wed Jan 19 11:07:26 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 Jan 2022 11:07:26 GMT
Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests
In-Reply-To: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
References: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
Message-ID: <VdrTY8x7A92pCHJWX34yymWxjpiYOx3cE0KpumfiWvo=.4d8aefae-fb1d-4b6d-b89c-65dd941ebe35@github.com>

On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Very small change fixing wrong strings "Falied" in a couple of tests.

Marked as reviewed by egahlin (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Jan 19 11:08:30 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 11:08:30 GMT
Subject: RFR: 8190264: JScrollBar ignores its border when using macOS Mac
 OS X Aqua look and feel [v14]
In-Reply-To: <wJuKBa_mpAZcGOHqhGD4AIew-Q53uglSI0_-ogFH07w=.1e77eb93-dd81-4741-af2c-0bfee1eeb793@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
 <wJuKBa_mpAZcGOHqhGD4AIew-Q53uglSI0_-ogFH07w=.1e77eb93-dd81-4741-af2c-0bfee1eeb793@github.com>
Message-ID: <l3cueLj418WeilRZYBENQWdXMBkPsIqYKs5EQZm8fO0=.42896145-d50e-4294-8553-7d3254663691@github.com>

On Tue, 18 Jan 2022 18:59:58 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made suggested changes

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Jan 19 11:28:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 11:28:23 GMT
Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests
In-Reply-To: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
References: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
Message-ID: <gwRjj6WN8_Sxsg5CRLt5tHrjAmb8I3BFZ2tsa1cgwPs=.0fababac-8c1a-41f1-b16b-6fc1e1e12fc1@github.com>

On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Very small change fixing wrong strings "Falied" in a couple of tests.

Marked as reviewed by aivanov (Reviewer).

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

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


From mbaesken at openjdk.java.net  Wed Jan 19 12:04:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 19 Jan 2022 12:04:36 GMT
Subject: Integrated: JDK-8280157: wrong texts Falied in a couple of tests
In-Reply-To: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
References: <hAzS_0dlrmlfBpq6MVeXbJotTTc95cVpmK2_DohrPL0=.9ae8e3eb-0ad9-4d1c-b298-31d47ade3018@github.com>
Message-ID: <F3N6WvW6UiKd6H3ZjD0lmm_nxR77-ShArWeKzxqQBk8=.cbf76259-f1ab-408e-9247-4dc57b7b10a1@github.com>

On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Very small change fixing wrong strings "Falied" in a couple of tests.

This pull request has now been integrated.

Changeset: 8931c122
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8931c12258a39cabda2cd1b92f54afcb216b882e
Stats:     9 lines in 5 files changed: 0 ins; 0 del; 9 mod

8280157: wrong texts Falied in a couple of tests

Reviewed-by: egahlin, aivanov

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

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


From achung at openjdk.java.net  Wed Jan 19 19:19:01 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 19 Jan 2022 19:19:01 GMT
Subject: Integrated: 8190264: JScrollBar ignores its border when using macOS
 Mac OS X Aqua look and feel
In-Reply-To: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
References: <pOI6v05dOac80OTlvoTUcKqxDaddXQ8TE-7CRzRMSeY=.0ee09c80-cef4-4752-bebc-33f86399e376@github.com>
Message-ID: <gabluUPiindPVHTiLbismIZVjmE1P7SUIXY3Y3bsc84=.fc4d9dad-73d4-4840-9d1b-69da4ce06a24@github.com>

On Fri, 12 Nov 2021 19:48:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Adjusted the AquaLF scrollbar to account for border inset settings when dragging the thumb and clicking on the track.

This pull request has now been integrated.

Changeset: 84fa0d8c
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/84fa0d8c7d0e1be19e48464801d81efa8c263793
Stats:     213 lines in 2 files changed: 206 ins; 0 del; 7 mod

8190264: JScrollBar ignores its border when using macOS Mac OS X Aqua look and feel

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: kizune, serb, aivanov

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

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


From aivanov at openjdk.java.net  Wed Jan 19 20:20:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 20:20:57 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v2]
In-Reply-To: <hn54hkGxAwRaj89ZFqYCLZyE64JKbwJM6NlSd2r0Z4c=.c2638552-a303-4450-82ea-e6f018b79693@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <MNDCgDC6RsrQTW48vM1551nTAm3eUf0M1AaLUIkCviM=.260eb86b-54be-4549-8d3f-9bf3f9988a2d@github.com>
 <hn54hkGxAwRaj89ZFqYCLZyE64JKbwJM6NlSd2r0Z4c=.c2638552-a303-4450-82ea-e6f018b79693@github.com>
Message-ID: <E-Uzx6eJPRBh9whoNo8t0D5d2KahpjmhnElUS-FeXdk=.2b069f09-00be-47c2-9e5e-2e57cf3b5b17@github.com>

On Tue, 18 Jan 2022 16:30:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review fix
>
> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 120:
> 
>> 118:     /**
>> 119:      * Amount to change the scrollbar's value by,
>> 120:      * given a unit up/down request.
> 
> Suggestion:
> 
>      * The amount to change the value of the scrollbar by,
>      * given a unit up/down request.
> 
> However, this still looks cumbersome and is not as clear.

What about _Stores the amount by which the value of the scrollbar is changed upon a unit up/down request_?

> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 129:
> 
>> 127:     /**
>> 128:      * Amount to change the scrollbar's value by,
>> 129:      * given a block (usually "page") up/down request.
> 
> Suggestion:
> 
>      * The amount to change the value of the scrollbar by,
>      * given a block (usually "page") up/down request.

Similarly, _Stores the amount by which the value of the scrollbar is changed upon a block (usually "page") up/down request_.

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

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


From aivanov at openjdk.java.net  Wed Jan 19 20:22:07 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 20:22:07 GMT
Subject: [jdk18] Withdrawn: 8278472: Invalid value set to CANDIDATEFORM
 structure
In-Reply-To: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
References: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
Message-ID: <GUItG5py3cL6J0L5GxtvtjwHPUGV0YWeKQAUxsB5_aU=.5737f4ba-61c3-4dee-846e-5100e4003b3c@github.com>

On Tue, 21 Dec 2021 15:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk18/pull/54


From aivanov at openjdk.java.net  Wed Jan 19 20:22:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 20:22:06 GMT
Subject: [jdk18] RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
References: <erLwxQNzoVktLmhb-8HllHRwNwUWzKXkZ9VbL-yHFpg=.d74d8049-6255-472a-8ff2-ac4625fba3a6@github.com>
Message-ID: <b9EeN1a4AAlFfvN4mGmaqrB_5Cx_Nwrgx_wd1KsivGo=.95a976d6-fffe-4208-8fef-21ba41bcbbcb@github.com>

On Tue, 21 Dec 2021 15:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> I've created the PR for jdk18 as it's a low-risk fix. If it's inappropriate at this time, I'll open the PR for mainline jdk.

Submitted a new PR for the mainline.

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

PR: https://git.openjdk.java.net/jdk18/pull/54


From aivanov at openjdk.java.net  Wed Jan 19 20:35:54 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 20:35:54 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
Message-ID: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>

According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.

There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.

Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

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

Commit messages:
 - 8278472: Invalid value set to CANDIDATEFORM structure

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

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


From prr at openjdk.java.net  Wed Jan 19 20:46:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 20:46:50 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
Message-ID: <Ay8npIe5BNuTshfkJEWxmyU9vURWaBAsxpWejOdkta8=.fc9f11f4-506b-48c4-8daa-8ef84dcc1c7e@github.com>

On Wed, 19 Jan 2022 20:14:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

Marked as reviewed by prr (Reviewer).

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

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


From naoto at openjdk.java.net  Wed Jan 19 20:52:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 19 Jan 2022 20:52:15 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
Message-ID: <foXLT0KGHMD31DLXS49n-RzrYC5RT4xYeAkmwq7VxvM=.b5614468-7f95-4f00-be6e-810616a33c80@github.com>

On Wed, 19 Jan 2022 20:14:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

Marked as reviewed by naoto (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jan 19 20:54:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 20:54:49 GMT
Subject: RFR: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
Message-ID: <LgWRe8YmaITdUAGCLTqZBshbNGrl4uKfJt8tUfTPfDM=.1b6cf0f3-a768-4cee-b62d-d83c62133850@github.com>

On Sat, 8 Jan 2022 00:42:18 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Tests are based on SwingSet2 application. 
> Test instructions are loaded from HTML files. 
> 
> See readme for more info.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jan 19 20:56:53 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 20:56:53 GMT
Subject: RFR: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent [v2]
In-Reply-To: <_cWedB2n1mwbAj8LpAXhGfNRXq5urm8Hl3KIanQ3qtk=.f3fe5d77-476b-4fa8-9d41-33685b76a2c0@github.com>
References: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
 <_cWedB2n1mwbAj8LpAXhGfNRXq5urm8Hl3KIanQ3qtk=.f3fe5d77-476b-4fa8-9d41-33685b76a2c0@github.com>
Message-ID: <Yycd0shfaoBI8mq5-dRJYzQBF3WuEX9RAYYesHnRffc=.57f21e13-5f08-4d0f-81e7-ef3ec17be377@github.com>

On Tue, 18 Jan 2022 17:28:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> A number of methods in BasicTabbedPaneUI uses the imperative form of the verb in the documentation instead of the third-person form which describes what the method does.
>> 
>> For consistency, I updated such descriptions to use the third-person form of the verb.
>> 
>> I fixed a couple of typos as well.
>> 
>> I also expanded all the wildcard imports into the specific ones.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jan 19 20:58:49 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 20:58:49 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs [v2]
In-Reply-To: <Jm1w5ZVocLQHdqMIHqPIkN4t3ZycHhfU_JFE3Lk_wj0=.21f6ad61-c92e-4637-97a7-1101bb80f541@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
 <Jm1w5ZVocLQHdqMIHqPIkN4t3ZycHhfU_JFE3Lk_wj0=.21f6ad61-c92e-4637-97a7-1101bb80f541@github.com>
Message-ID: <lNVf0xHkeBsHhgWeN42GhZBWQaKWGwkwm7phjI6Tl6M=.ded7b990-7bfc-484f-a1da-824826b26f10@github.com>

On Tue, 18 Jan 2022 17:29:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
>> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
>> 
>> I also organised the imports which replaced all wildcard imports with specific class imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jan 19 21:00:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 21:00:06 GMT
Subject: RFR: 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical
 scroll bar [v2]
In-Reply-To: <3wi2kDHqmbcSHfe0Q6PGD4sWHLjQ2o4_saALPipQMqE=.336472cc-6584-434e-ba4d-df6a06ba41a2@github.com>
References: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
 <3wi2kDHqmbcSHfe0Q6PGD4sWHLjQ2o4_saALPipQMqE=.336472cc-6584-434e-ba4d-df6a06ba41a2@github.com>
Message-ID: <A8FRZEMQuO9WikzUnf4T5EO1Rbt9VcrD6agIkaoSj10=.b6f1297f-b5a0-4fa6-84f7-0dd77efb59fd@github.com>

On Tue, 18 Jan 2022 17:29:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Fixed the typo in the layout methods: ?Laysouts a?? ? ?Lays out a??.
>> 
>> The doc for `layoutHScrollbar` incorrectly referred to _vertical_ scroll bar rather than horizontal one.
>> 
>> 
>> I also expanded the wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by prr (Reviewer).

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

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


From shurailine at openjdk.java.net  Wed Jan 19 21:06:14 2022
From: shurailine at openjdk.java.net (Alexandre Iline)
Date: Wed, 19 Jan 2022 21:06:14 GMT
Subject: Integrated: JDK-8279641: Create manual JTReg tests for Swing
 accessibility
In-Reply-To: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
References: <rJWdXWdVBymzEZ22TwnlEWrBObrC3eJUZIEEERtMP6s=.2967a56f-4756-412c-989c-c64726f64af5@github.com>
Message-ID: <S35BBICJUYWVXbu2YYB2mMsxpe9CKQhJFo2Q1uzKJRI=.b2db67ac-a0d2-4954-839a-773e9031fed4@github.com>

On Sat, 8 Jan 2022 00:42:18 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Tests are based on SwingSet2 application. 
> Test instructions are loaded from HTML files. 
> 
> See readme for more info.

This pull request has now been integrated.

Changeset: 5523ddeb
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5523ddebd572f38c3f960950d114ffead33266ae
Stats:     1410 lines in 35 files changed: 1410 ins; 0 del; 0 mod

8279641: Create manual JTReg tests for Swing accessibility

Reviewed-by: serb, prr

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

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


From prr at openjdk.java.net  Wed Jan 19 21:06:58 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 21:06:58 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <munfmZMUlliwxQMhEoXHFcQ7QL2ZgpnJPOHTTHtPXHQ=.ac6cf100-f946-498e-9e23-980f7e5b236f@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jan 19 21:09:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 21:09:51 GMT
Subject: RFR: 8279861: Clarify 'rect' parameters and description of
 paintTabBorder method in BasicTabbedPaneUI
In-Reply-To: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
References: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
Message-ID: <P2b3g69wsyMqiDsKZICEPcLZ_x193fplg91TvTAOofQ=.fbd7506a-3c29-4e59-b384-584391bb90c4@github.com>

On Tue, 11 Jan 2022 15:50:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The protected methods `paintTab` and `paintFocusIndicator` accept the `rect` parameter which is documented as _?rectangles?_. I suggest updating this description to a more descriptive: _?the tab rectangles?_ as the array contains the coordinates of the tabs.
> 
> Similarly, the documentation for `assureRectsCreated` method could be updated to clarify which rectangles are created.
> 
> The documentation for `paintTabBorder` is inconsistent with other paint methods, it has no ending punctuation. I updated it to be consistent.
> 
> I split out these changes from [JDK-8279798](https://bugs.openjdk.java.net/browse/JDK-8279798) and #7031 because this issue will likely require a CSR.

I don't think the spec is affected in a way that needs a CSR

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

Marked as reviewed by prr (Reviewer).

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


From prr at openjdk.java.net  Wed Jan 19 21:31:04 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 Jan 2022 21:31:04 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <piXRygmql3Z5IKwJDHdNBkfC7nYoWaFlH0C8kBMmEbM=.4ce25c46-348f-43c8-911b-fab636c36960@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Marked as reviewed by prr (Reviewer).

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

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


From weijun at openjdk.java.net  Wed Jan 19 22:25:18 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 22:25:18 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
Message-ID: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>

Two edits.

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

Commit messages:
 - Another year
 - year
 - Update DigestMD5Base.java
 - 8279796: Fix typo: Constucts -> Constructs

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

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


From iris at openjdk.java.net  Wed Jan 19 22:33:56 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 19 Jan 2022 22:33:56 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <QZIPAP3z8kRNlDUG-aLlymTH2SXuWfOh4WE7_Bpg_Ek=.b63864d3-5d10-4e30-b46c-c67a71668551@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

Marked as reviewed by iris (Reviewer).

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

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


From serb at openjdk.java.net  Wed Jan 19 22:55:50 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 19 Jan 2022 22:55:50 GMT
Subject: RFR: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs [v2]
In-Reply-To: <Jm1w5ZVocLQHdqMIHqPIkN4t3ZycHhfU_JFE3Lk_wj0=.21f6ad61-c92e-4637-97a7-1101bb80f541@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
 <Jm1w5ZVocLQHdqMIHqPIkN4t3ZycHhfU_JFE3Lk_wj0=.21f6ad61-c92e-4637-97a7-1101bb80f541@github.com>
Message-ID: <69yCIxu4gw2iPCrXSbDHxsuq1Y-MQqJHq1FtlUZVv3k=.b04deb6a-e26f-4497-84d4-36c644d9362e@github.com>

On Tue, 18 Jan 2022 17:29:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
>> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
>> 
>> I also organised the imports which replaced all wildcard imports with specific class imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Wed Jan 19 22:58:51 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 19 Jan 2022 22:58:51 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <_cZ8ExHbynKqJdAAUyk4VdhDpdlUq7uwjYFB6A-hyso=.c0a76c0d-88a9-48c4-8990-7c34b18158a2@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Is it possible to add a test case for this bug?

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

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


From serb at openjdk.java.net  Wed Jan 19 23:00:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 19 Jan 2022 23:00:49 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 727:

> 725:         Handler handler;
> 726:         /**
> 727:          * Constructs a {@code DoubleClickListener}.

This change is under review here:
https://github.com/openjdk/jdk/pull/7030

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

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


From weijun at openjdk.java.net  Wed Jan 19 23:00:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:00:49 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
 <acD5yK0kHLAFm96czNrmeE1H6DR6r6Q4cnJFmjIBwCQ=.de776db1-5530-41f9-96a6-5135824b7a13@github.com>
Message-ID: <vHf8vjRiyT8TSNblMHqMywc-qrubvuHhrFqTj9sEtPs=.f5d68326-fbe5-4d33-84e0-2a7c5bdcb93f@github.com>

On Wed, 19 Jan 2022 22:57:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Two edits.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 727:
> 
>> 725:         Handler handler;
>> 726:         /**
>> 727:          * Constructs a {@code DoubleClickListener}.
> 
> This change is under review here:
> https://github.com/openjdk/jdk/pull/7030

Oops, I'll remove mine. Thanks.

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

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


From weijun at openjdk.java.net  Wed Jan 19 23:10:31 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:10:31 GMT
Subject: RFR: 8279796: Fix typo: Constucts -> Constructs [v2]
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <HkT457w3Vo_nMABn3BNAbp0DXj6kxUl1D1IzR-is5DA=.0b6ee4ac-0fa8-4b07-852e-429df3a057e5@github.com>

> Two edits.

Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - year
 - Update DigestMD5Base.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7147/files
  - new: https://git.openjdk.java.net/jdk/pull/7147/files/faec0c1d..6df9ccf8

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

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

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


From weijun at openjdk.java.net  Wed Jan 19 23:10:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 Jan 2022 23:10:32 GMT
Subject: Integrated: 8279796: Fix typo: Constucts -> Constructs
In-Reply-To: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
References: <JktmCswLSpsHGLtmiXvj2EhsLZYeL19NFmDwMi9azD4=.5fd316b8-72f8-4e5f-bb98-a38d46b541a7@github.com>
Message-ID: <BQbdDocyZyIxxXqYcZg4ENoDFrY8qACxp9o---bjydk=.4dfa7574-96e5-4598-8f75-3b379ae442ed@github.com>

On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two edits.

This pull request has now been integrated.

Changeset: 98d96a77
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98d96a770756ffe3e7f5e4b82120e9fb484cad9a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8279796: Fix typo: Constucts -> Constructs

Reviewed-by: iris

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

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


From serb at openjdk.java.net  Wed Jan 19 23:16:48 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 19 Jan 2022 23:16:48 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
Message-ID: <BIpadqJr--sTvks3npQeBEE0G0CrqCwZk7kEEdLufgQ=.3fc1fe5f-67cb-4d5a-85fd-5cde41dc319c@github.com>

On Wed, 19 Jan 2022 20:14:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

This change was done under https://bugs.openjdk.java.net/browse/JDK-8147842 where the CFS_CANDIDATEPOS was changed to the CFS_POINT. Please check that the old bug will not be reproduced again.
see http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8d42ecfa68a3

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

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


From jwilhelm at openjdk.java.net  Thu Jan 20 00:40:42 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 00:40:42 GMT
Subject: RFR: Merge jdk18
Message-ID: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl
 - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
 - 8272058: 25 Null pointer dereference defect groups in 4 files
 - 8280234: AArch64 "core" variant does not build after JDK-8270947
 - 8280155: [PPC64, s390] frame size checks are not yet correct
 - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS
 - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE
 - 8278417: Closed test fails after JDK-8276108 on aarch64
 - 8274096: Improve decoding of image files
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/7151/files
  Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151

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


From jwilhelm at openjdk.java.net  Thu Jan 20 01:21:56 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 01:21:56 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
References: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
Message-ID: <y0iAccUwe8WmPHsAzm9zEpWgdTLEzKLHEmBgkiWWrzc=.4fca1b0a-3f93-4ee9-9fc6-6835ebd6d041@github.com>

On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 4616c13c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5
Stats:     1732 lines in 67 files changed: 933 ins; 606 del; 193 mod

Merge

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

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


From duke at openjdk.java.net  Thu Jan 20 01:24:57 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 20 Jan 2022 01:24:57 GMT
Subject: Withdrawn: 8275170: Some jtreg sound tests should be marked headful
In-Reply-To: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
References: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
Message-ID: <wp2cmev8ZXJzxxnTg68vap1ry9QghmfI8VFX3J-Hlbs=.fcc95481-5b26-4fea-9881-bb19ec54e592@github.com>

On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
> 
> The jtreg javax.sound tests are written in such a way that if a needed audio device
> or other platform resource is not available, they just exit with a "pass" for the test.
> It is as if headful tests just swallowed HeadlessException and issued a pass.
> If we allowed that we'd be effectively testing almost nothing of real importance.
> 
> Currently almost  all sound tests have no keyword like "headful" to indicate they
> may need access to a hardware resource to do anything useful so a similar
> situation arises there except when someone runs those tests manually on
> a local system which has audio devices.
> 
> Of course "headful" and "audio device" aren't exactly interchangeable terms
> but if tests are allowed to be run - or worse usually or always run - in a situation
> where they potentially are on a system without an audio device (a headless VM) or are running in
> a session which doesn't have full desktop access - which may in some
> cases be how audio device access is granted, then they are more likely
> to be running in this scenario where the testing isn't valid.
> 
> Another point is that headful tests must be run one at a time - no concurrency because
> you can't have multiple tests moving the mouse at the same time
> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
> When tests that really need access to an audio device are run it is probably safer to consider
> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
> usual for a single app to be able to monopolize access to a speaker, but for input devices
> that is what you'd generally expect.
> 
> By no means am I sure that the tests being updated here are the full set that need tagging.
> There are a lot of tests and they are all known to pass on systems with NO audio
> devices, so the search has been for tests which call APIs which will definitely
> need access to some device in order to do anything useful.
> So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
> Alternatively we could mark ALL sound tests headful .. but given where we are starting from
> that might be erring unnecessarily far in the opposite direction.
> 
> By adding both headful and sound keywords it gives options to someone who
> wants to identify the tests and perhaps run just tests which need "sound" on some
> config they know supports audio but isn't headful.

This pull request has been closed without being integrated.

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

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


From prr at openjdk.java.net  Thu Jan 20 01:37:48 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 Jan 2022 01:37:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
Message-ID: <uksHJqxb2IOTEeiGv1bGVuYlR1vpYwchxNpPKsxnIMA=.a4c5938e-457f-4238-9962-634abcc6a9d0@github.com>

On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Class.isAssignableFrom` is often used in form of:
> 
>     if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
> 
>     if (clazz.isInstance(obj)) {
>     
> Replacement is equivalent if it's known that `obj != null`.
> In JDK codebase there are many such places.
> 
> I tried to measure performance via JMH
> 
>     Class<?> integerClass = Integer.class;
>     Class<?> numberClass = Number.class;
> 
>     Object integerObject = 45666;
>     Object doubleObject = 8777d;
> 
>     @Benchmark
>     public boolean integerInteger_isInstance() {
>         return integerClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean integerInteger_isAssignableFrom() {
>         return integerClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isInstance() {
>         return integerClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isAssignableFrom() {
>         return integerClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isInstance() {
>         return numberClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isAssignableFrom() {
>         return numberClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isInstance() {
>         return numberClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isAssignableFrom() {
>         return numberClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>         bh.consume(numberClass.isInstance(integerObject));
>         bh.consume(numberClass.isInstance(doubleObject));
>     }
> 
>     @Benchmark
>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>     }
> 
> `isInstance` is a bit faster than `isAssignableFrom`
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance and if a non-null instance is used to get a non-null class they are PROBABLY the same but it is far from clear. The implementations of both are at least native and may be instrinsicified. The doc for Class.isAssignableFrom cites JLS 5.1.4 which in what I found is about primitives so I suspect it is woefully out of date 
https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4

What client tests have you run that touch the code you are changing ?

In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it.

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 04:16:52 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 04:16:52 GMT
Subject: Integrated: 8279894:
 javax/swing/JInternalFrame/8020708/bug8020708.java timeouts on Windows 11
In-Reply-To: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
References: <2jiTyfD8VvWMqNUN0J3LtNuRwO-CQ6vwqHtuuM44P_A=.02fa360c-987b-44ee-99b6-57144ace51da@github.com>
Message-ID: <7v3bc97aszow6xgVDKG-wyKS9FOEyyZBPGOfYmGLcQo=.576e06c3-cb1f-4987-8e4b-60a7355a5a6a@github.com>

On Thu, 13 Jan 2022 07:44:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is timing out on slower windows11 CI system. Increased the timeout and also adjusted autodelay time to more consistent time with other headful tests which makes test pass in windows11.
> Test job link in JBS.

This pull request has now been integrated.

Changeset: c4a624d4
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4a624d46332552e7baca8ee09bfdce0e53eef05
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8279894: javax/swing/JInternalFrame/8020708/bug8020708.java timeouts on Windows 11

Reviewed-by: serb, kizune

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 04:19:51 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 04:19:51 GMT
Subject: Integrated: 8280047: Broken link to Swing Connection document from
 javax.swing package docs
In-Reply-To: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
References: <VM_2eVXFekHNwyAAgRrCn9B-ItlghRKQxuI-r5oOSGQ=.93581e83-a4ba-4f89-aea7-73bd3a4c2010@github.com>
Message-ID: <_kFCNzhBMK2nhfsz2xcW7FIv_HmUNxF4ajJdJxvZmQU=.e7a106b5-49bd-4279-a41c-a4ceeaa0fc18@github.com>

On Mon, 17 Jan 2022 06:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed the broken link with appropriate link to swing document.

This pull request has now been integrated.

Changeset: 1022cbdf
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1022cbdf987af846e79b92dfa20b763db7563320
Stats:     8 lines in 1 file changed: 0 ins; 3 del; 5 mod

8280047: Broken link to Swing Connection document from javax.swing package docs

Reviewed-by: kcr, aivanov

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 04:53:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 04:53:49 GMT
Subject: RFR: 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical
 scroll bar [v2]
In-Reply-To: <3wi2kDHqmbcSHfe0Q6PGD4sWHLjQ2o4_saALPipQMqE=.336472cc-6584-434e-ba4d-df6a06ba41a2@github.com>
References: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
 <3wi2kDHqmbcSHfe0Q6PGD4sWHLjQ2o4_saALPipQMqE=.336472cc-6584-434e-ba4d-df6a06ba41a2@github.com>
Message-ID: <PY_OwONArJXcelUQFv2YjBWrFt4M6zoQq-IDBKCVQSA=.4d8a967b-f5d0-4acb-8135-aa59ec0b61ea@github.com>

On Tue, 18 Jan 2022 17:29:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Fixed the typo in the layout methods: ?Laysouts a?? ? ?Lays out a??.
>> 
>> The doc for `layoutHScrollbar` incorrectly referred to _vertical_ scroll bar rather than horizontal one.
>> 
>> 
>> I also expanded the wildcard imports.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 05:00:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 05:00:49 GMT
Subject: RFR: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent [v2]
In-Reply-To: <_cWedB2n1mwbAj8LpAXhGfNRXq5urm8Hl3KIanQ3qtk=.f3fe5d77-476b-4fa8-9d41-33685b76a2c0@github.com>
References: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
 <_cWedB2n1mwbAj8LpAXhGfNRXq5urm8Hl3KIanQ3qtk=.f3fe5d77-476b-4fa8-9d41-33685b76a2c0@github.com>
Message-ID: <CiHceGNH4j-3vkh-01KkQdYawDbzIY4OfUQmIc1VLjo=.6bcd20a7-b0c3-4a47-95cb-a963f3cadb63@github.com>

On Tue, 18 Jan 2022 17:28:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> A number of methods in BasicTabbedPaneUI uses the imperative form of the verb in the documentation instead of the third-person form which describes what the method does.
>> 
>> For consistency, I updated such descriptions to use the third-person form of the verb.
>> 
>> I fixed a couple of typos as well.
>> 
>> I also expanded all the wildcard imports into the specific ones.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a blank line between java- and javax-package classes

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 05:20:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 05:20:49 GMT
Subject: RFR: 8279861: Clarify 'rect' parameters and description of
 paintTabBorder method in BasicTabbedPaneUI
In-Reply-To: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
References: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
Message-ID: <RjIyJAFYnj_0B_dI7esaOIeQeK1v1_X67v1wtRZsI6s=.e7a8260d-7c0d-4036-b498-1ee0a4a918b1@github.com>

On Tue, 11 Jan 2022 15:50:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The protected methods `paintTab` and `paintFocusIndicator` accept the `rect` parameter which is documented as _?rectangles?_. I suggest updating this description to a more descriptive: _?the tab rectangles?_ as the array contains the coordinates of the tabs.
> 
> Similarly, the documentation for `assureRectsCreated` method could be updated to clarify which rectangles are created.
> 
> The documentation for `paintTabBorder` is inconsistent with other paint methods, it has no ending punctuation. I updated it to be consistent.
> 
> I split out these changes from [JDK-8279798](https://bugs.openjdk.java.net/browse/JDK-8279798) and #7031 because this issue will likely require a CSR.

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Thu Jan 20 06:08:22 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 06:08:22 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v3]
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <zB9o82PoJCTo6mEE_qrHNu31eLFjmbRaJgoeIZkGYv8=.c4a2a71e-7984-4f18-8c5e-1ffbf13ea18d@github.com>

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7004/files
  - new: https://git.openjdk.java.net/jdk/pull/7004/files/765c4147..7c98aecf

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

  Stats: 67 lines in 14 files changed: 0 ins; 4 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004

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


From psadhukhan at openjdk.java.net  Thu Jan 20 06:12:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 06:12:29 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7004/files
  - new: https://git.openjdk.java.net/jdk/pull/7004/files/7c98aecf..16d76ed3

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

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

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


From dmarkov at openjdk.java.net  Thu Jan 20 11:56:48 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Thu, 20 Jan 2022 11:56:48 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <_cZ8ExHbynKqJdAAUyk4VdhDpdlUq7uwjYFB6A-hyso=.c0a76c0d-88a9-48c4-8990-7c34b18158a2@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
 <_cZ8ExHbynKqJdAAUyk4VdhDpdlUq7uwjYFB6A-hyso=.c0a76c0d-88a9-48c4-8990-7c34b18158a2@github.com>
Message-ID: <I_xOyztJYUCSDjEy4KlyJkpVSO_DBw4uOKeGaC_MLJY=.4f0baa07-5fd5-4dda-aa75-d8dcdce46d16@github.com>

On Wed, 19 Jan 2022 22:55:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to add a test case for this bug?

The test will require some extra actions such as interaction with a native app, presence of a file to move between Java and native app, etc. I do not think it's really worth it. So I added noreg-hard to the bug.

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

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


From aivanov at openjdk.java.net  Thu Jan 20 15:20:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 15:20:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
Message-ID: <OeqRu4iODXrb78xxWP-GE7Kt_yIRNmqyZ5GxSgqwpUY=.ae17c42c-c248-432b-b395-f6e8708cedf1@github.com>

On Thu, 20 Jan 2022 06:12:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

src/java.desktop/share/classes/java/awt/Component.java line 4137:

> 4135:          * Provides direct access to the back buffer as an image.
> 4136:          *
> 4137:          * @return direct access to the back buffer as an image.

Hm? This doesn't look right.
Suggestion:

         * @return the back buffer as an image.

src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java line 312:

> 310:      */
> 311:     protected class BCSChild implements Serializable {
> 312: 

Shall we indent `serialVersionUID`? It's for `BCSChild` but its indentation suggests it's for the surrounding class.

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

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


From aivanov at openjdk.java.net  Thu Jan 20 15:20:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 15:20:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <OeqRu4iODXrb78xxWP-GE7Kt_yIRNmqyZ5GxSgqwpUY=.ae17c42c-c248-432b-b395-f6e8708cedf1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <OeqRu4iODXrb78xxWP-GE7Kt_yIRNmqyZ5GxSgqwpUY=.ae17c42c-c248-432b-b395-f6e8708cedf1@github.com>
Message-ID: <JPpJC_U02s4gPk5KpltaukDSVko3txQavRnHOwYJYwo=.7f587ede-66a1-43ab-84ae-6b9196eb2f40@github.com>

On Thu, 20 Jan 2022 15:11:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Shall we indent `serialVersionUID`? It's for `BCSChild` but its indentation suggests it's for the surrounding class.

It's right below the class declaration.

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

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


From aivanov at openjdk.java.net  Thu Jan 20 18:15:51 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 18:15:51 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <BIpadqJr--sTvks3npQeBEE0G0CrqCwZk7kEEdLufgQ=.3fc1fe5f-67cb-4d5a-85fd-5cde41dc319c@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
 <BIpadqJr--sTvks3npQeBEE0G0CrqCwZk7kEEdLufgQ=.3fc1fe5f-67cb-4d5a-85fd-5cde41dc319c@github.com>
Message-ID: <HErp8uvAXwQpQ4YcKOW-Xmp9xC3JB3NBXW1EjvhPjDo=.c2cc2643-7a0c-418c-a236-4931e84bca4f@github.com>

On Wed, 19 Jan 2022 23:12:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This change was done under https://bugs.openjdk.java.net/browse/JDK-8147842 where the CFS_CANDIDATEPOS was changed to the CFS_POINT. Please check that the old bug will not be reproduced again. see http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8d42ecfa68a3

Yes, the test works fine, the Chinese-Taiwan CangJie IME window is displayed near the caret as expected.  
![Chinese-Taiwan CangJie IME](https://user-images.githubusercontent.com/70774172/150396714-b039a38d-bef0-42fc-925c-876ebc09b82c.png)

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

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


From serb at openjdk.java.net  Thu Jan 20 19:24:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 Jan 2022 19:24:49 GMT
Subject: RFR: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
Message-ID: <ia4BfvFvOqmjFyoLmseIgCDBebedPtm5Rz6VjJrI-NU=.5843321a-495d-4de5-b376-5e60206cbbd9@github.com>

On Wed, 19 Jan 2022 20:14:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Thu Jan 20 19:32:50 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 20 Jan 2022 19:32:50 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <E0SssMoiZzxcPJkDQ3CeRpZ-I6UxIpFkM9S881KOtxI=.2f6e0ccb-a1a5-4d52-b750-aa7a772d738a@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Just for confirmation - it is not possible to reproduce using the second forked java app instead of the native app?

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

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


From prr at openjdk.java.net  Thu Jan 20 19:34:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 Jan 2022 19:34:50 GMT
Subject: RFR: 8278232: [macos] Wrong chars emitted when entering certain
 char-sequence of Indic language
In-Reply-To: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
References: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
Message-ID: <90w1BN-WVC2gqIM36W6MC0GMhPGPebnvfYRKO64h4ro=.d51792df-5f4e-485d-90a3-603dc2b10ecb@github.com>

On Thu, 6 Jan 2022 11:03:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Devanagiri script was not rendered properly in macos after JDK-8068283 due to incorporated check of utf16 string encoding should be more than 2 bytes is not satisfied. 
> Additional check added in JDK-8132503 to ascertain if utf8 string encoding is complex or not was also not satisfied because of which complex Devanagairi unicode text insertion was not working.
> Fix is to add Devanagiri codePoint to the complex list so that it is rendered properly.

Marked as reviewed by prr (Reviewer).

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m line 962:

> 960:     NSLog(@"insertText kbdlayout %@ ",(NSString *)kbdLayout);
> 961: 
> 962:     NSLog(@"utf8Length %lu utf16Lenght %lu", (unsigned long)utf8Length, (unsigned long)utf16Length);

utf16Lenght -> utf16Length

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

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


From aivanov at openjdk.java.net  Thu Jan 20 20:15:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 20:15:50 GMT
Subject: Integrated: 8278472: Invalid value set to CANDIDATEFORM structure
In-Reply-To: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
References: <P2XJ6-tx2H0LH0RRmxKbe1eGMlvZlxI2nDPeqThAda0=.5e188671-8e06-438d-a6e0-5bb89d907f33@github.com>
Message-ID: <dbzAULPD5L59lBCwTDBh9dDAfM2nkUBY0z6A018fseY=.82f91398-591c-4981-860f-63d21795f7b0@github.com>

On Wed, 19 Jan 2022 20:14:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> According to the Windows API reference, `dwStyle` of [`CANDIDATEFORM`](https://docs.microsoft.com/en-us/windows/win32/api/imm/ns-imm-candidateform) structure should be set to `CFS_CANDIDATEPOS` or `CFS_EXCLUDE`. So, `CFS_POINT` is wrong here.
> 
> There are two instances in `AwtComponent::SetCandidateWindow` in [`awt_Component.cpp`](https://github.com/openjdk/jdk/blob/f90425a1cbbc686045c87086af586e62f05f6c49/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3914) where the incorrect value is used.
> 
> Initially, I created this PR for jdk18. [It was suggested](https://github.com/openjdk/jdk18/pull/54#issuecomment-1006432326) to place this fix into the mainline, so this a continuation to [jdk18/pull/54](https://github.com/openjdk/jdk18/pull/54).

This pull request has now been integrated.

Changeset: 2426d58e
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2426d58e592c54de64ebe0f06448d239aeced082
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8278472: Invalid value set to CANDIDATEFORM structure

Reviewed-by: prr, naoto, serb

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

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


From dmarkov at openjdk.java.net  Thu Jan 20 20:57:46 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Thu, 20 Jan 2022 20:57:46 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <E0SssMoiZzxcPJkDQ3CeRpZ-I6UxIpFkM9S881KOtxI=.2f6e0ccb-a1a5-4d52-b750-aa7a772d738a@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
 <E0SssMoiZzxcPJkDQ3CeRpZ-I6UxIpFkM9S881KOtxI=.2f6e0ccb-a1a5-4d52-b750-aa7a772d738a@github.com>
Message-ID: <B36lSKMbJaarydDr8Asj9-Qise5esHSJ76Shuv1ZwGM=.8c4a00f1-7283-4207-8888-869ae85652a7@github.com>

On Thu, 20 Jan 2022 19:29:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just for confirmation - it is not possible to reproduce using the second forked java app instead of the native app?

I could not reproduce the issue doing DnD between two java windows

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

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


From serb at openjdk.java.net  Fri Jan 21 07:40:48 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 Jan 2022 07:40:48 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <HOhSN4xR4C1aqj2LP9KXPTrwvuArC7mRCmFIde9A9go=.ab5c45e2-68c0-43ab-a096-eccf92c3a7bd@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Fri Jan 21 07:46:53 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 Jan 2022 07:46:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
Message-ID: <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>

On Thu, 20 Jan 2022 06:12:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:

> 351:      * File(parent, fileName)</code> except when the parent and child are both
> 352:      * special folders, in which case the <code>File</code> is a wrapper containing
> 353:      * a <code>ShellFolder</code> object.

Is a "ShellFolder" part of the public API? If not should we mention it in the spec?

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

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


From aturbanov at openjdk.java.net  Fri Jan 21 08:06:49 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 21 Jan 2022 08:06:49 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <aYviuMgsurADRid5Tws82FDeJFHP5fiHkv2ex8jSz30=.f32e0b93-f4af-4ae3-9322-0c3076728ba2@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
 <aYviuMgsurADRid5Tws82FDeJFHP5fiHkv2ex8jSz30=.f32e0b93-f4af-4ae3-9322-0c3076728ba2@github.com>
Message-ID: <f-SkOmprIqroaAn_Mbj3ZyVUsYaezEADqBOGhYRX718=.14f04217-0877-4b13-9844-d80f47088817@github.com>

On Wed, 15 Dec 2021 01:40:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There is possible NPE, when trying to play AudioClip
>> 
>> import java.applet.AudioClip;
>> import java.io.IOException;
>> import java.net.URL;
>> 
>> 
>> public class AudioNpe {
>>     public static void main(String[] args) throws IOException, InterruptedException {
>>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>>         AudioClip content = (AudioClip)url.getContent();
>>         content.play();
>> 
>>         Thread.sleep(10000L);
>>     }
>> }
>> 
>> 
>> 	  at java.lang.Thread.<init>(Thread.java:393)
>> 	  at java.lang.Thread.<init>(Thread.java:760)
>> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
>> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
>> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
>> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
>> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
>> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
>> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
>> 
>> 
>> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
>> 
>> After fix - audio clip plays without problems.
>
> @turbanoff do you plan to update the PR?

@mrserb @prrace  Can you please check the test. It should contain some metadata, (`@bug`, `description`, etc) right?

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

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


From duke at openjdk.java.net  Fri Jan 21 17:07:58 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 21 Jan 2022 17:07:58 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
Message-ID: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>

These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
1. `makeDefaultConfig()` returning `NULL`.
2. A race condition when the number of screens changes.
The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.

The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.

The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.

We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

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

Commit messages:
 - 8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux

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

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


From prr at openjdk.java.net  Fri Jan 21 17:40:43 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 Jan 2022 17:40:43 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <JdWW7tsmg1ShXNWIxzyGrbUhmNM3MILEBA_2OW-T4W8=.9ced77c9-7beb-473f-af11-f1d25bf46734@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 23:

> 21:  * questions.
> 22:  */
> 23: 

The following would work
/*
 * @test
 *  @key headful
 * @bug 8279673
 * @summary Verify no NPE creating threads
 * @run main/othervm DataPusherThreadCheck
 */

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

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


From serb at openjdk.java.net  Fri Jan 21 20:05:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 Jan 2022 20:05:10 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <uWhosaFHojfw-ffARDBeZxrmSHSJnttn3kuZHEuAu1Y=.0b6c5c0b-76e0-470b-9179-f37d2f874be5@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Marked as reviewed by serb (Reviewer).

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

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


From stefan.reich.maker.of.eye at googlemail.com  Fri Jan 21 20:10:34 2022
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 21 Jan 2022 21:10:34 +0100
Subject: Kindly request your attention for a really annoying visual Java bug
 on Linux Mint
Message-ID: <CAC2-jLF=vxvwZPn8n+iWhSGarbMQ-yqEiSDmTtm0-r29gxn0uw@mail.gmail.com>

Dear Sirs or Madams,

I make a visual recognition tool <https://gaz.ai> in Java that would
tremendously benefit from the ability to show translucent windows. Indeed,
Java has such an ability but it is broken on my Linux Mint 19 ThinkPad for
unknown reasons (screenshot <https://botcompany.de/images/1103064>).

All the details are here:

https://github.com/adoptium/adoptium-support/issues/430

I'd love to see this fixed. Not sure how reproducible it is or if there is
anything screwed in my Linux Mint installation. Seems to run fine otherwise
though.

Many greetings,
Stefan Reich


From alexey.ivanov at oracle.com  Fri Jan 21 21:37:43 2022
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Fri, 21 Jan 2022 21:37:43 +0000
Subject: Kindly request your attention for a really annoying visual Java
 bug on Linux Mint
In-Reply-To: <CAC2-jLF=vxvwZPn8n+iWhSGarbMQ-yqEiSDmTtm0-r29gxn0uw@mail.gmail.com>
References: <CAC2-jLF=vxvwZPn8n+iWhSGarbMQ-yqEiSDmTtm0-r29gxn0uw@mail.gmail.com>
Message-ID: <eacfa606-f6e1-9f50-1a67-52bcfcaea65d@oracle.com>

Dear Stefan,

Thank you for reporting the bug.

You could have submitted the bug via https://bugreport.java.com/bugreport/


Anyway, I reproduced the issue and now I've submitted the bug for you:
https://bugs.openjdk.java.net/browse/JDK-8280482
"Window transparency bug on Linux Mint"

I attached a modified version of your testcase which creates all the 
windows on the EDT.


Even though I see the problem, there could be something wrong with the 
test, or possibly window placement. If I add a delay after a window is 
created, I can see that all the screen is getting covered gradually with 
windows and all the windows have the same level of translucency. When 
the bottom of the screen is reached, the new windows get moved above so 
that the newly created window does not cover the taskbar. This creates a 
darker rectangle seen along the bottom of the screen on the main monitor.

In my environment, the dark square area that you have on your screenshot 
is not as large, it covers only the part of the screen on the main 
monitor. At the same time, this area appears only when all the windows 
are created. Again, it could be that some of the windows of the grid get 
misplaced for whatever reason. Perhaps, the calculation of the grid has 
an error or something like that.

Eventually, it may be a bug not in Java but in the sample app. I'll play 
around with it over the weekend if I have time.

On 21/01/2022 20:10, Stefan Reich wrote:
> Dear Sirs or Madams,
>
> I make a visual recognition tool <https://gaz.ai> in Java that would
> tremendously benefit from the ability to show translucent windows. Indeed,
> Java has such an ability but it is broken on my Linux Mint 19 ThinkPad for
> unknown reasons (screenshot <https://botcompany.de/images/1103064>).
>
> All the details are here:
>
> https://github.com/adoptium/adoptium-support/issues/430
>
> I'd love to see this fixed. Not sure how reproducible it is or if there is
> anything screwed in my Linux Mint installation. Seems to run fine otherwise
> though.
>
> Many greetings,
> Stefan Reich
-- 
Regards,
Alexey


From serb at openjdk.java.net  Sat Jan 22 03:56:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 22 Jan 2022 03:56:08 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <Cp9IlvR5jPVHmvB8NCXnuFCvFtEDli_R_TRhShx5NO8=.f81b9314-e5b2-48d8-b583-2d79c9c5d777@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

You can try to reproduce the bug by creating the custom JDK and emulating the native upcalls by the test. It will help to prve that the fix will work.

I am not sure that it is possible to synchronize access to the screen number across the code w/o introducing deadlocks, the current change does not cover all cases where the X11GraphicsDevice.screen is passed around. probably we should follow this [suggestion](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L58) and everywhere the "screen" is used under the awt lock (1)check that it is less than the number of screens and use 0(main screen as a fallback), or (2) some "default value" if the number of screens is zero at that time - something similar was implemented on macOS by the [JDK-8211992](http://hg.openjdk.java.net/jdk/jdk/rev/814c49afb1a7)

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

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


From darcy at openjdk.java.net  Sat Jan 22 21:15:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 22 Jan 2022 21:15:29 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
Message-ID: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>

Use presumed syntax that will be introduced by JDK-8280488.

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

Commit messages:
 - JDK-8280492: Address remaining doclint issues in JDK build

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

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


From darcy at openjdk.java.net  Sat Jan 22 21:38:04 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 22 Jan 2022 21:38:04 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <kn2iP3juEd6Y9A7cfGd9lUCDmBKl3C4gkTl1u7rxV90=.acf5f52f-6c00-4eb8-8478-a3edec778e30@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

This should be the (near) final step to fully enable all doclint checks during the javac portion of the build. The "reference" doclint check is currently disabled in the build command for several modules. The problematic references are cross-module @see and @link tags. This PR changes those tags to use a to a new proposed syntax for cross-module references.

Before this PR is pushed, the javadoc changes need to be made and I'll update the make files to enable the "reference" warning category.

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

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


From iris at openjdk.java.net  Sun Jan 23 04:20:09 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 23 Jan 2022 04:20:09 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <elSYh8XSVzMGrODD1xTqpMl35mEyOjC78W1Gqe3m-M0=.d63584b5-5f34-4dc4-97c4-cbe52537f7a6@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by iris (Reviewer).

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

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


From serb at openjdk.java.net  Sun Jan 23 08:09:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 23 Jan 2022 08:09:08 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <DZZOsElwo_8uVI5dzK50UwOG31kQZPJMxLOR2Yp3AcE=.8b1cf44b-0df0-4e69-b23a-88b3843fdc78@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by serb (Reviewer).

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

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


From lancea at openjdk.java.net  Sun Jan 23 11:48:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 23 Jan 2022 11:48:06 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <2G0jVnCjP0i0VZhKN-fy0jDFtkT3BbBVcBiOJdxT56c=.870ed070-ad3c-4c88-bced-9ccb6155867b@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by lancea (Reviewer).

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

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


From stefan.reich.maker.of.eye at googlemail.com  Sun Jan 23 18:44:15 2022
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sun, 23 Jan 2022 19:44:15 +0100
Subject: Kindly request your attention for a really annoying visual Java
 bug on Linux Mint
In-Reply-To: <eacfa606-f6e1-9f50-1a67-52bcfcaea65d@oracle.com>
References: <CAC2-jLF=vxvwZPn8n+iWhSGarbMQ-yqEiSDmTtm0-r29gxn0uw@mail.gmail.com>
 <eacfa606-f6e1-9f50-1a67-52bcfcaea65d@oracle.com>
Message-ID: <CAC2-jLHk=hqsU=MWRLtNY+p=RiisKvae_32U7-fTU5e=vw0aLQ@mail.gmail.com>

Hello Alexey,

thanks a lot for investigating and submitting the bug. I don't think I can
sign up at bugs.openjdk.java.net directly, right?

I have also done some further testing, for example on an older version of
Peppermint Linux (also on my ThinkPad). Same kind of errors appear. So it
doesn't seem related to the flavor of Linux used.

I have also tried the source code you produced. It gives the same artifacts
as my original version.

> Perhaps, the calculation of the grid has an error or something like that.

I challenge you to show me the bug in that 10 line function... ^^ (Don't
think the problem is in there)

Originally I had simply tried to make a JWindow covering the whole second
screen and it was completely opaque. That's how I discovered the bug in the
first place.

So... judging from the official bug report it seems this is being
investigated by the proper "authorities", right? That's a very good result
for now.

Many greetings,
Stefan



On Fri, 21 Jan 2022 at 22:38, Aleksei Ivanov <alexey.ivanov at oracle.com>
wrote:

> Dear Stefan,
>
> Thank you for reporting the bug.
>
> You could have submitted the bug via https://bugreport.java.com/bugreport/
>
>
> Anyway, I reproduced the issue and now I've submitted the bug for you:
> https://bugs.openjdk.java.net/browse/JDK-8280482
> "Window transparency bug on Linux Mint"
>
> I attached a modified version of your testcase which creates all the
> windows on the EDT.
>
>
> Even though I see the problem, there could be something wrong with the
> test, or possibly window placement. If I add a delay after a window is
> created, I can see that all the screen is getting covered gradually with
> windows and all the windows have the same level of translucency. When
> the bottom of the screen is reached, the new windows get moved above so
> that the newly created window does not cover the taskbar. This creates a
> darker rectangle seen along the bottom of the screen on the main monitor.
>
> In my environment, the dark square area that you have on your screenshot
> is not as large, it covers only the part of the screen on the main
> monitor. At the same time, this area appears only when all the windows
> are created. Again, it could be that some of the windows of the grid get
> misplaced for whatever reason. Perhaps, the calculation of the grid has
> an error or something like that.
>
> Eventually, it may be a bug not in Java but in the sample app. I'll play
> around with it over the weekend if I have time.
>
> On 21/01/2022 20:10, Stefan Reich wrote:
> > Dear Sirs or Madams,
> >
> > I make a visual recognition tool <https://gaz.ai> in Java that would
> > tremendously benefit from the ability to show translucent windows.
> Indeed,
> > Java has such an ability but it is broken on my Linux Mint 19 ThinkPad
> for
> > unknown reasons (screenshot <https://botcompany.de/images/1103064>).
> >
> > All the details are here:
> >
> > https://github.com/adoptium/adoptium-support/issues/430
> >
> > I'd love to see this fixed. Not sure how reproducible it is or if there
> is
> > anything screwed in my Linux Mint installation. Seems to run fine
> otherwise
> > though.
> >
> > Many greetings,
> > Stefan Reich
> --
> Regards,
> Alexey
>


-- 
==    Join the *https://t.me/HumanAscension <https://t.me/HumanAscension>*
 ==
== https://bitchute.com/channel/LxVBAHP3O0Hj ==


From serb at openjdk.java.net  Sun Jan 23 22:57:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 23 Jan 2022 22:57:27 GMT
Subject: RFR: 8280132: Incorrect comparator
 com.sun.beans.introspect.MethodInfo.MethodOrder
Message-ID: <fv-SKNNU3lnv72jX5J7UVmT6X0IfBQ-i-_gEYBLrS-Y=.dadf6fde-06e7-47f9-a00f-2aca67b8ae02@github.com>

In jdk 9 we started to sort the list of methods for each class for two reasons:
 1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified.
 2. We tried to sort methods so the more specific returns types come first, this was done because our logic for selecting the correct method did not work properly. 

The second issue above was fixed by the separate change [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) so now we only need to sort the list of methods in any order and do not care about return types.

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

Commit messages:
 - Initial fix JDK-8280132

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

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


From psadhukhan at openjdk.java.net  Mon Jan 24 06:03:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 06:03:42 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7004/files
  - new: https://git.openjdk.java.net/jdk/pull/7004/files/16d76ed3..752b7a09

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

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

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


From psadhukhan at openjdk.java.net  Mon Jan 24 06:03:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 06:03:45 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
Message-ID: <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>

On Fri, 21 Jan 2022 07:43:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:
> 
>> 351:      * File(parent, fileName)</code> except when the parent and child are both
>> 352:      * special folders, in which case the <code>File</code> is a wrapper containing
>> 353:      * a <code>ShellFolder</code> object.
> 
> Is a "ShellFolder" part of the public API? If not should we mention it in the spec?

It is already mentioned in getSystemDisplayName, getSystemTypeDescription, getSystemIcon, isRoot. Anyways, I have removed the linkage for the new addition as it will not be able to resolve.

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

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


From duke at openjdk.java.net  Mon Jan 24 07:52:07 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Mon, 24 Jan 2022 07:52:07 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
Message-ID: <vnRnq4ILOYd5G59GZuZufMerbayP4qfjJSL5jKGLnUA=.5c1cd241-c53b-4de9-96c0-e381c53aae3c@github.com>

On Fri, 21 Jan 2022 17:02:38 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> These crashes were not reproducible, so the fix is based on a hypothesis that there are two possible reasons for them:
> 1. `makeDefaultConfig()` returning `NULL`.
> 2. A race condition when the number of screens changes.
> The race scenario: `X11GraphisDevice.makeDefaultConfiguration()` is called on EDT so the call can race with `X11GraphisDevice.invalidate()` that re-sets the screen number of the device; the latter is invoked on the `AWT-XAWT` thread from `X11GraphicsEnvironment.rebuildDevices()`. So by the time `makeDefaultConfiguration()` makes a native call with the device's current screen number, the `x11Screens` array maintained by the native code could have become shorter. And the native methods like `Java_sun_awt_X11GraphicsDevice_getConfigColormap()` assume that the number passed to them is always current and valid. The AWT lock only protects against the changes during the native methods invocation and does not protect against them being called with an outdated screen number. With a larger screen number, those methods read past the end of the `x11Screens` array.
> 
> The fix for (1) is to die gracefully instead of crashing in an attempt to de-reference a `NULL` pointer, which might happen upon returning from `makeDefaultConfig()` in `getAllConfigs()`.
> 
> The fix for (2) is to eliminate the race by protecting `X11GraphisDevice.screen` with the AWT lock such that it doesn't change when the native methods working with it are active.
> 
> We've been shipping JetBrains Runtime with this fix for a few months now and there were no crash reports with those specific patterns against the versions with the fix.

Thanks for looking at this!

> You can try to reproduce the bug by creating the custom JDK and emulating the native upcalls by the test. It will help to prve that the fix will work.

Can you elaborate, please? Do you mean that this custom JDK would synthetically change `X11GraphicsDevice.screen` at the "right" time?

> 
> I am not sure that it is possible to synchronize access to the screen number across the code w/o introducing deadlocks, the current change does not cover all cases where the X11GraphicsDevice.screen is passed around. probably we should follow this [suggestion](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L58) and everywhere the "screen" is used under the awt lock (1)check that it is less than the number of screens and use 0(main screen as a fallback), or (2) some "default value" if the number of screens is zero at that time - something similar was implemented on macOS by the [JDK-8211992](http://hg.openjdk.java.net/jdk/jdk/rev/814c49afb1a7)

I agree, returning some default as a fallback should also work. However, that's so radically different from the approach I've taken that a separate PR would be required.

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

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


From psadhukhan at openjdk.java.net  Mon Jan 24 09:45:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 09:45:25 GMT
Subject: RFR: 8264743: Add forRemoval for deprecated classes and method in
 javax/swing/plaf/basic
Message-ID: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>

Few methods and classes were deprecated in JDK-8049700 where it was decided to add forRemoval in jdk19. 
Added "forRemoval" to start the process of removing in near future jdk release.

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

Commit messages:
 - 8264743: Add forRemoval for deprecated classes and method in javax/swing/plaf/basic

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

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


From aivanov at openjdk.java.net  Mon Jan 24 10:54:18 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 10:54:18 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
 <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>
Message-ID: <QQ2ywsvZiWkrep7J0Ei3QDwKH6ZjwuHQD7cn2_e83bc=.b745de7d-465a-429a-8456-6e158f0680c6@github.com>

On Mon, 24 Jan 2022 06:00:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:
>> 
>>> 351:      * File(parent, fileName)</code> except when the parent and child are both
>>> 352:      * special folders, in which case the <code>File</code> is a wrapper containing
>>> 353:      * a <code>ShellFolder</code> object.
>> 
>> Is a "ShellFolder" part of the public API? If not should we mention it in the spec?
>
> It is already mentioned in getSystemDisplayName, getSystemTypeDescription, getSystemIcon, isRoot. Anyways, I have removed the linkage for the new addition as it will not be able to resolve.

If `ShellFolder` remains mentioned, I'd rather use `<code>ShellFolder</code>` as it was done originally.

I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec?

On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`.

I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`.

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

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


From dmarkov at openjdk.java.net  Mon Jan 24 10:59:10 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Mon, 24 Jan 2022 10:59:10 GMT
Subject: Integrated: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <mAJxZH-EYUxDnCVqgg5J1dlLzUZdpKD0l5dGIS0gdT4=.4c257368-5a64-4f72-9c42-db8352827a80@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

This pull request has now been integrated.

Changeset: 7a0a6c95
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a0a6c95a53c6cb3340328d6543a97807320b740
Stats:     19 lines in 4 files changed: 2 ins; 0 del; 17 mod

8274751: Drag And Drop hangs on Windows

Reviewed-by: aivanov, prr, serb

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

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


From dfuchs at openjdk.java.net  Mon Jan 24 11:04:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 Jan 2022 11:04:04 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by dfuchs (Reviewer).

LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`...

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

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


From prappo at openjdk.java.net  Mon Jan 24 11:21:08 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 24 Jan 2022 11:21:08 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
 <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com>
Message-ID: <JDr1FxF8XaSbYJbOn_SrBKrt7hUXDqR6cuYqI1wNjYM=.a1714904-3bec-4099-a3e5-83676054bcb8@github.com>

On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`...

They will do it quicker, if you create new or support existing bugs in their bug trackers.

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

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


From psadhukhan at openjdk.java.net  Mon Jan 24 11:31:11 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 11:31:11 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <QQ2ywsvZiWkrep7J0Ei3QDwKH6ZjwuHQD7cn2_e83bc=.b745de7d-465a-429a-8456-6e158f0680c6@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
 <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>
 <QQ2ywsvZiWkrep7J0Ei3QDwKH6ZjwuHQD7cn2_e83bc=.b745de7d-465a-429a-8456-6e158f0680c6@github.com>
Message-ID: <SwEKSNMl-Oh5TzAZQA2ld4L63yjyJjrZd54Ej8I5CEI=.5aa504c2-3a35-4fb2-a1ed-a3cd7ed35ef5@github.com>

On Mon, 24 Jan 2022 10:51:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is already mentioned in getSystemDisplayName, getSystemTypeDescription, getSystemIcon, isRoot. Anyways, I have removed the linkage for the new addition as it will not be able to resolve.
>
> If `ShellFolder` remains mentioned, I'd rather use `<code>ShellFolder</code>` as it was done originally.
> 
> I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec?
> 
> On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`.
> 
> I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`.

Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it.

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

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


From prappo at openjdk.java.net  Mon Jan 24 11:36:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 24 Jan 2022 11:36:04 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <qDQilLDUaMuHGbC9E9KlqUUbJkj0W5IKPDnYCWcCxwI=.0a0de1c5-58d7-4148-8a75-8d4bb69c4d0c@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags.

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

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


From aivanov at openjdk.java.net  Mon Jan 24 11:39:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 11:39:12 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <SwEKSNMl-Oh5TzAZQA2ld4L63yjyJjrZd54Ej8I5CEI=.5aa504c2-3a35-4fb2-a1ed-a3cd7ed35ef5@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
 <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>
 <QQ2ywsvZiWkrep7J0Ei3QDwKH6ZjwuHQD7cn2_e83bc=.b745de7d-465a-429a-8456-6e158f0680c6@github.com>
 <SwEKSNMl-Oh5TzAZQA2ld4L63yjyJjrZd54Ej8I5CEI=.5aa504c2-3a35-4fb2-a1ed-a3cd7ed35ef5@github.com>
Message-ID: <fwkyM8H9cmkm05Yh8EaLjRMc3qUEboeck65zu-xrevA=.e677add4-1176-4c49-97b5-17518f6b7a56@github.com>

On Mon, 24 Jan 2022 11:28:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If `ShellFolder` remains mentioned, I'd rather use `<code>ShellFolder</code>` as it was done originally.
>> 
>> I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec?
>> 
>> On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`.
>> 
>> I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`.
>
> Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it.

The `<code>` element does not create a link, it uses monospace font to render its contents which implies it's part of computer code. Class names usually marked up with `<code>` HTML element or with `{@code }` javadoc element.

These aren't used consistently. Often classes aren't marked up. So you're right: in the majority of cases, `ShellFolder` isn't marked up. The `<code>` markup is used in two methods only: `isRoot` and `getChild`.

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

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


From aivanov at openjdk.java.net  Mon Jan 24 11:39:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 11:39:12 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4]
In-Reply-To: <fwkyM8H9cmkm05Yh8EaLjRMc3qUEboeck65zu-xrevA=.e677add4-1176-4c49-97b5-17518f6b7a56@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <Vooa0yiEnKqfKjd2JMkkxzBbtGNpofXmEoJKbaWw1Jc=.c60ffd03-82f0-43b6-ba86-6cd4242ef6fc@github.com>
 <sXTdEX3CJb6N4yj0k-B1sEYyZrE5B-h2YtybDgxf9qE=.309f753b-d411-49a9-bd1d-51e38059ce3b@github.com>
 <LEziugVUxnjmsGkD36_LdTEYqYhEsM9z1lXERZc0rwI=.6f0e6a15-5dd0-4095-9da1-6bd50816debe@github.com>
 <QQ2ywsvZiWkrep7J0Ei3QDwKH6ZjwuHQD7cn2_e83bc=.b745de7d-465a-429a-8456-6e158f0680c6@github.com>
 <SwEKSNMl-Oh5TzAZQA2ld4L63yjyJjrZd54Ej8I5CEI=.5aa504c2-3a35-4fb2-a1ed-a3cd7ed35ef5@github.com>
 <fwkyM8H9cmkm05Yh8EaLjRMc3qUEboeck65zu-xrevA=.e677add4-1176-4c49-97b5-17518f6b7a56@github.com>
Message-ID: <L1OHANuGwE_qLmPsqf2FmfwE9oX-pPw-UqNjXl7QcaY=.3dd55073-f114-41c9-bf3d-59b3bf10d762@github.com>

On Mon, 24 Jan 2022 11:34:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it.
>
> The `<code>` element does not create a link, it uses monospace font to render its contents which implies it's part of computer code. Class names usually marked up with `<code>` HTML element or with `{@code }` javadoc element.
> 
> These aren't used consistently. Often classes aren't marked up. So you're right: in the majority of cases, `ShellFolder` isn't marked up. The `<code>` markup is used in two methods only: `isRoot` and `getChild`.

I was referring to removing all the references to `ShellFolder` from public API, under another bugid, if it's to be done.

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

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


From duke at openjdk.java.net  Mon Jan 24 14:32:13 2022
From: duke at openjdk.java.net (svedin)
Date: Mon, 24 Jan 2022 14:32:13 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
Message-ID: <EXc6-RpwQ6EFQ_p7tJ2lBs--exBx4Zbl2jbhk9ftEGA=.bada0238-5f75-4ba5-a37a-7902192b51a3@github.com>

On Tue, 18 Jan 2022 12:51:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> When an object is moved from one window (DnD source) to another window (DnD target) the first window may also be considered as a DnD target and the native OS sends corresponding events to it. That event processing clears isInDoDragDropLoop flag, which is currently used to indicate DnD operation, and causes a hang.
> 
> Fix:
> It is necessary to distinguish events related to the DnD source and events related to the DnD target, (i.e. use two indication flags).
> 
> Testing:
> mach5 green

Will this be backported to java 8 and 11?

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

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


From dmarkov at openjdk.java.net  Mon Jan 24 15:48:10 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Mon, 24 Jan 2022 15:48:10 GMT
Subject: RFR: 8274751: Drag And Drop hangs on Windows
In-Reply-To: <EXc6-RpwQ6EFQ_p7tJ2lBs--exBx4Zbl2jbhk9ftEGA=.bada0238-5f75-4ba5-a37a-7902192b51a3@github.com>
References: <WqpXCc_85vkH7jVsIq0F-NL7P9PcXQfZkbptjj1TeiU=.5c28d91f-805c-4832-8277-4a4f68587b6c@github.com>
 <EXc6-RpwQ6EFQ_p7tJ2lBs--exBx4Zbl2jbhk9ftEGA=.bada0238-5f75-4ba5-a37a-7902192b51a3@github.com>
Message-ID: <nwC1JPjMWRssZ7N9a7EbR8IGiVWNX5XuqgvBDQRe2mg=.adeae6f7-9277-43fb-bfe1-ca451841760a@github.com>

On Mon, 24 Jan 2022 14:26:33 GMT, svedin <duke at openjdk.java.net> wrote:

> Will this be backported to java 8 and 11?

I will port the fix to Oracle JDK 8, 11 and 17

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

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


From aturbanov at openjdk.java.net  Mon Jan 24 18:17:52 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 24 Jan 2022 18:17:52 GMT
Subject: RFR: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher [v2]
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <6FBZWqGt2L2ai7MGeFhKKa5uH8g59m46vEhp7GBchmU=.96fd5023-d1bd-46e0-ab1b-36ac95088289@github.com>

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

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

  8279673: AudioClip.play doesn't work due to NullPointerException when creating DataPusher
  
  add test metadata

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6382/files
  - new: https://git.openjdk.java.net/jdk/pull/6382/files/50ab0d31..ac67b9e2

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

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

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


From darcy at openjdk.java.net  Mon Jan 24 18:25:08 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 24 Jan 2022 18:25:08 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build
In-Reply-To: <qDQilLDUaMuHGbC9E9KlqUUbJkj0W5IKPDnYCWcCxwI=.0a0de1c5-58d7-4148-8a75-8d4bb69c4d0c@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
 <qDQilLDUaMuHGbC9E9KlqUUbJkj0W5IKPDnYCWcCxwI=.0a0de1c5-58d7-4148-8a75-8d4bb69c4d0c@github.com>
Message-ID: <bKU73Xd2TZ0n_rLO9-r27yJipw0eVhMUa6Xlq6-HJ4o=.bae9221e-cbfc-4b25-bb75-0b98b450ed1b@github.com>

On Mon, 24 Jan 2022 11:33:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Use presumed syntax that will be introduced by JDK-8280488.
> 
> Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags.

Ah; thanks Pavel for the additional context. Bug JDK-8280488 will allow (i.e. ignore) cross-module @see/@link references during javac compilation. So while the syntax in this PR is already valid per JDK-8164408, I cannot (yet) enable the "reference" doctlint check in the javac build due to the cross-module situation.

I'll double-check the syntax in this PR generates the expected links in the result of the docs builds, give the bug a more descriptive title, and get these changes pushed. Enabling the reference warning can be done under another bug.

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

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


From aivanov at openjdk.java.net  Mon Jan 24 18:34:17 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 18:34:17 GMT
Subject: Integrated: 8279795: Fix typo in BasicFileChooserUI: Constucts ->
 Constructs
In-Reply-To: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
References: <SYeN74RZy0kjOwnobNablObhCzLpzDVqlKuKcKKZEEQ=.d4805e50-478a-45a1-86f2-56c340aa395d@github.com>
Message-ID: <8lc9upKhjNmi4DxYisSjcf59_tCMqbvZdtEymgFPl1U=.b868f10a-5154-4086-b275-4d9551f31174@github.com>

On Tue, 11 Jan 2022 15:25:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Fix the typo in the constructor for BasicFileChooserUI.DoubleClickListener: ?Constucts? ? ?Constructs?.
> Also fixed the typo in the parameter of the constructor: ?the lsit? ? ?the list?.
> 
> I also organised the imports which replaced all wildcard imports with specific class imports.

This pull request has now been integrated.

Changeset: dae2226a
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dae2226a538f7156056d1f101fb5b4d1c6f72520
Stats:     55 lines in 1 file changed: 38 ins; 0 del; 17 mod

8279795: Fix typo in BasicFileChooserUI: Constucts -> Constructs

Reviewed-by: prr, serb

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

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


From aivanov at openjdk.java.net  Mon Jan 24 18:35:16 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 18:35:16 GMT
Subject: Integrated: 8279794: Fix typos in BasicScrollBarUI: Laysouts a
 vertical scroll bar
In-Reply-To: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
References: <a5nv8yRTjuZ5MC4zsegY8vde4knqtfVJ5u7xQEvC2QU=.c71d3a0c-121b-4f7f-bb9b-064f41e2bcf3@github.com>
Message-ID: <6X0roFD8WsAp-NXsdBriguagOeq8plMTExXv3G7mYFQ=.144262bb-c896-41ed-8bc7-19d10203d9f8@github.com>

On Tue, 11 Jan 2022 15:35:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Fixed the typo in the layout methods: ?Laysouts a?? ? ?Lays out a??.
> 
> The doc for `layoutHScrollbar` incorrectly referred to _vertical_ scroll bar rather than horizontal one.
> 
> 
> I also expanded the wildcard imports.

This pull request has now been integrated.

Changeset: acd98294
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acd98294c628e8e03a036a8e3e08d775147b2fda
Stats:     50 lines in 1 file changed: 38 ins; 9 del; 3 mod

8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical scroll bar

Reviewed-by: prr, psadhukhan

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

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


From aivanov at openjdk.java.net  Mon Jan 24 18:36:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 18:36:12 GMT
Subject: Integrated: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent
In-Reply-To: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
References: <N9Cws7xnqKMGBn-KlsVOgwjgD3qxLspaJO-lzLABj2Q=.6675ed15-8c88-412a-8f5a-370be88b3e1e@github.com>
Message-ID: <Jz3UPFrgdCjv56L5C7o2x1RUVlFMr9DTUcLdSeAjmbY=.d6237a6d-d6f0-4914-aacf-1811c072a0a0@github.com>

On Tue, 11 Jan 2022 15:32:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A number of methods in BasicTabbedPaneUI uses the imperative form of the verb in the documentation instead of the third-person form which describes what the method does.
> 
> For consistency, I updated such descriptions to use the third-person form of the verb.
> 
> I fixed a couple of typos as well.
> 
> I also expanded all the wildcard imports into the specific ones.

This pull request has now been integrated.

Changeset: 0b5c54be
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b5c54be675c63ecac17cd37f6d388fd42f09aa8
Stats:     64 lines in 1 file changed: 39 ins; 0 del; 25 mod

8279798: Javadoc for BasicTabbedPaneUI is inconsistent

Reviewed-by: prr, psadhukhan

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

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


From aivanov at openjdk.java.net  Mon Jan 24 18:39:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 18:39:13 GMT
Subject: Integrated: 8279861: Clarify 'rect' parameters and description of
 paintTabBorder method in BasicTabbedPaneUI
In-Reply-To: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
References: <EEk6HFuUuDzgHXwZLPeCdQfMUfj5AZIhY8X2TSFGHhc=.d41fd54d-492c-4e71-ab66-d1004e654a30@github.com>
Message-ID: <7yiPL_if8Dmv1KtrXZ66Pf7EFT8jFxuOvHg3F55UxRQ=.4144c700-0949-4ca2-82e2-a9bba868aa89@github.com>

On Tue, 11 Jan 2022 15:50:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The protected methods `paintTab` and `paintFocusIndicator` accept the `rect` parameter which is documented as _?rectangles?_. I suggest updating this description to a more descriptive: _?the tab rectangles?_ as the array contains the coordinates of the tabs.
> 
> Similarly, the documentation for `assureRectsCreated` method could be updated to clarify which rectangles are created.
> 
> The documentation for `paintTabBorder` is inconsistent with other paint methods, it has no ending punctuation. I updated it to be consistent.
> 
> I split out these changes from [JDK-8279798](https://bugs.openjdk.java.net/browse/JDK-8279798) and #7031 because this issue will likely require a CSR.

This pull request has now been integrated.

Changeset: a825a4a1
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a825a4a1dba14317547b57bc0188b1e912baa251
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8279861: Clarify 'rect' parameters and description of paintTabBorder method in BasicTabbedPaneUI

Reviewed-by: prr, psadhukhan

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

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


From serb at openjdk.java.net  Mon Jan 24 18:49:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 24 Jan 2022 18:49:10 GMT
Subject: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId,
 XVisualIDFromVisual on Linux
In-Reply-To: <vnRnq4ILOYd5G59GZuZufMerbayP4qfjJSL5jKGLnUA=.5c1cd241-c53b-4de9-96c0-e381c53aae3c@github.com>
References: <JItgqGccX5K-OZOUxGR4b4mbE5v7ZHdeJcVAqfhPyVc=.86740280-09c9-4e84-8ae3-bdd5013cf092@github.com>
 <vnRnq4ILOYd5G59GZuZufMerbayP4qfjJSL5jKGLnUA=.5c1cd241-c53b-4de9-96c0-e381c53aae3c@github.com>
Message-ID: <CqV7x2bv242l3Nh8jx1RwmVTP0rKFyI6xrZWVoA1KUg=.c1b991c1-1ea3-4acd-b41e-1a82931a6533@github.com>

On Mon, 24 Jan 2022 07:49:30 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> Can you elaborate, please? Do you mean that this custom JDK would synthetically change `X11GraphicsDevice.screen` at the "right" time?

Yes, at the "right" time and the "right" number of monitors.

> > I am not sure that it is possible to synchronize access to the screen number across the code w/o introducing deadlocks, the current change does not cover all cases where the X11GraphicsDevice.screen is passed around. probably we should follow this [suggestion](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L58) and everywhere the "screen" is used under the awt lock (1)check that it is less than the number of screens and use 0(main screen as a fallback), or (2) some "default value" if the number of screens is zero at that time - something similar was implemented on macOS by the [JDK-8211992](http://hg.openjdk.java.net/jdk/jdk/rev/814c49afb1a7)
> 
> I agree, returning some default as a fallback should also work. However, that's so radically different from the approach I've taken that a separate PR would be required.

It is better to start from the bug reproducing. As the change - the awt lock always should be the last one, I am not sure that wrapping a bunch of code by that lock is safe.

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

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


From aivanov at openjdk.java.net  Mon Jan 24 18:57:10 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 18:57:10 GMT
Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <w_TvcBl_2CVnlkxIxRgcxFfk_nFMrZL1t30iPYFiBdQ=.ac91d7c6-acf6-4507-baef-17d03320f906@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Mon Jan 24 19:09:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 19:09:11 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
Message-ID: <HJJFCyn-cMVwNNbDqxeedObnLGbK3D42ubYoLCKACE8=.2de490f1-654a-4bd0-9688-ca0fc5781640@github.com>

On Mon, 24 Jan 2022 06:03:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by aivanov (Reviewer).

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

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


From alexey.ivanov at oracle.com  Mon Jan 24 19:33:52 2022
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 24 Jan 2022 19:33:52 +0000
Subject: Kindly request your attention for a really annoying visual Java
 bug on Linux Mint
In-Reply-To: <CAC2-jLHk=hqsU=MWRLtNY+p=RiisKvae_32U7-fTU5e=vw0aLQ@mail.gmail.com>
References: <CAC2-jLF=vxvwZPn8n+iWhSGarbMQ-yqEiSDmTtm0-r29gxn0uw@mail.gmail.com>
 <eacfa606-f6e1-9f50-1a67-52bcfcaea65d@oracle.com>
 <CAC2-jLHk=hqsU=MWRLtNY+p=RiisKvae_32U7-fTU5e=vw0aLQ@mail.gmail.com>
Message-ID: <379cce55-7bd5-7771-7241-34b0a25a1525@oracle.com>

Hello Stefan,

On 23/01/2022 18:44, Stefan Reich wrote:
> Hello Alexey,
>
> thanks a lot for investigating and submitting the bug. I don't think I 
> can sign up at bugs.openjdk.java.net <http://bugs.openjdk.java.net> 
> directly, right?

No, you can't.

You can submit a bug report using https://bugreport.java.com/bugreport/
After evaluation, the bug will be moved to JBS at 
https://bugs.openjdk.java.net/

> I have also done some further testing, for example on an older version 
> of Peppermint Linux (also on my ThinkPad). Same kind of errors appear. 
> So it doesn't seem related to the flavor?of Linux used.

Thank you for additional testing and for confirming other flavours of 
Linux are affected.

> I have also tried the source code you produced. It gives the same 
> artifacts as my original version.

That's good. At least, the modified test reproduces the same problem.

>
> > Perhaps, the calculation of the grid has an error or something like 
> that.
>
> I challenge you to show me the bug in that 10 line function... ^^ 
> (Don't think the problem is in there)

It's not the case. I referred to the change of colour that I saw. I 
posted in my comment: While all the windows were created as one go on 
the EDT, each window was displayed with the right colour initially. Once 
the EDT got unblocked, I saw something like animation where the window 
tiles on the screen changed colours. The colours remained stable 
afterwards. This effect made me think there could be something going on 
with the coordinates.

However, it looks as if processing of some events makes the windows 
change the colour.

A better test would be to create one window in the area that gets darker 
and see what events it receives. Another thing I'd verify is the number 
of the paint events. The window is neither opaque nor transparent. If 
it's painted several times, the same background colour could be painted 
over the existing colour, thus the window could become darker with each 
paint. It's a wild guess, it could be misleading yet it's worth checking.

> Originally I had simply tried to make a JWindow covering the whole 
> second screen and it was completely opaque. That's how I discovered 
> the bug in the first place.
>
> So... judging from the official bug report it seems this is being 
> investigated by the proper "authorities", right? That's a very good 
> result for now.

It's assigned to an engineer. That's all to it at this very moment.

If you can help with pinpointing the root cause or provide the fix for 
the problem, your help and contribution will be appreciated.


Regards,
Alexey

>
> Many greetings,
> Stefan
>
>
>
> On Fri, 21 Jan 2022 at 22:38, Aleksei Ivanov 
> <alexey.ivanov at oracle.com> wrote:
>
>     Dear Stefan,
>
>     Thank you for reporting the bug.
>
>     You could have submitted the bug via
>     https://bugreport.java.com/bugreport/
>     <https://urldefense.com/v3/__https://bugreport.java.com/bugreport/__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBzkWBwWZg$>
>
>
>     Anyway, I reproduced the issue and now I've submitted the bug for you:
>     https://bugs.openjdk.java.net/browse/JDK-8280482
>     "Window transparency bug on Linux Mint"
>
>     I attached a modified version of your testcase which creates all the
>     windows on the EDT.
>
>
>     Even though I see the problem, there could be something wrong with
>     the
>     test, or possibly window placement. If I add a delay after a
>     window is
>     created, I can see that all the screen is getting covered
>     gradually with
>     windows and all the windows have the same level of translucency. When
>     the bottom of the screen is reached, the new windows get moved
>     above so
>     that the newly created window does not cover the taskbar. This
>     creates a
>     darker rectangle seen along the bottom of the screen on the main
>     monitor.
>
>     In my environment, the dark square area that you have on your
>     screenshot
>     is not as large, it covers only the part of the screen on the main
>     monitor. At the same time, this area appears only when all the
>     windows
>     are created. Again, it could be that some of the windows of the
>     grid get
>     misplaced for whatever reason. Perhaps, the calculation of the
>     grid has
>     an error or something like that.
>
>     Eventually, it may be a bug not in Java but in the sample app.
>     I'll play
>     around with it over the weekend if I have time.
>
>     On 21/01/2022 20:10, Stefan Reich wrote:
>     > Dear Sirs or Madams,
>     >
>     > I make a visual recognition tool <https://gaz.ai
>     <https://urldefense.com/v3/__https://gaz.ai__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBzCtp8Vto$>>
>     in Java that would
>     > tremendously benefit from the ability to show translucent
>     windows. Indeed,
>     > Java has such an ability but it is broken on my Linux Mint 19
>     ThinkPad for
>     > unknown reasons (screenshot
>     <https://botcompany.de/images/1103064
>     <https://urldefense.com/v3/__https://botcompany.de/images/1103064__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBz3GvDylE$>>).
>     >
>     > All the details are here:
>     >
>     > https://github.com/adoptium/adoptium-support/issues/430
>     <https://urldefense.com/v3/__https://github.com/adoptium/adoptium-support/issues/430__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBzss3HZh8$>
>     >
>     > I'd love to see this fixed. Not sure how reproducible it is or
>     if there is
>     > anything screwed in my Linux Mint installation. Seems to run
>     fine otherwise
>     > though.
>     >
>     > Many greetings,
>     > Stefan Reich
>     -- 
>     Regards,
>     Alexey
>
>
>
> -- 
> ==? ? Join the _https://t.me/HumanAscension 
> <https://urldefense.com/v3/__https://t.me/HumanAscension__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBzY2f3Z6g$>_? 
> ?==
> == https://bitchute.com/channel/LxVBAHP3O0Hj 
> <https://urldefense.com/v3/__https://bitchute.com/channel/LxVBAHP3O0Hj__;!!ACWV5N9M2RV99hQ!cKbBJVPVj_k3vtI9ThVRGYo8rY4-KtkDz6pN2QBPrYLkgYlHOkZcTe-ALpBzCwpb1Io$> 
> ==



From darcy at openjdk.java.net  Mon Jan 24 20:10:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 24 Jan 2022 20:10:40 GMT
Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links
 [v2]
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <8CLBwHk3ls8ijDaN-6poNrhGMxCulNGrjFvImPGQ-sY=.e8629cdc-b51d-4614-a5af-923f848d0703@github.com>

> Use presumed syntax that will be introduced by JDK-8280488.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Update copyrigths.
 - Merge branch 'master' into JDK-8280492
 - JDK-8280492: Address remaining doclint issues in JDK build

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7189/files
  - new: https://git.openjdk.java.net/jdk/pull/7189/files/b74e7d85..6f3bd429

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

  Stats: 664 lines in 55 files changed: 433 ins; 128 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7189.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189

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


From darcy at openjdk.java.net  Mon Jan 24 20:20:12 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 24 Jan 2022 20:20:12 GMT
Subject: Integrated: JDK-8280492: Use cross-module syntax for cross-module
 links
In-Reply-To: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
References: <GCG7iGABK5QDRVHEx5fXjp0AXqvWNCEfvojZPJ5oC44=.fd40cd7b-2223-4f43-86d3-0ed98a0aa2db@github.com>
Message-ID: <2oUpK1s5mNt-fWdUF5YZP3MlqzjXypdqMMz8QG-3Q5U=.f971fd74-655b-400d-9718-11299edcb7c8@github.com>

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

This pull request has now been integrated.

Changeset: 8e82d002
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e82d0021c119b7793870811fad37d7659c1174d
Stats:     72 lines in 17 files changed: 0 ins; 0 del; 72 mod

8280492: Use cross-module syntax for cross-module links

Reviewed-by: iris, serb, lancea, dfuchs, aivanov

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

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


From serb at openjdk.java.net  Tue Jan 25 03:08:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 25 Jan 2022 03:08:37 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
Message-ID: <LiwporOz9zl-tfcKD3j9WWUrmZnqv-mf48BqwO6nni4=.c12d755f-4d1a-4072-92d7-95e272c8a54a@github.com>

On Mon, 24 Jan 2022 06:03:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by serb (Reviewer).

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

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


From serb at openjdk.java.net  Tue Jan 25 18:24:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 25 Jan 2022 18:24:44 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
Message-ID: <NkdZUaE7SfzEZrIuZDXgpegeVHepYoTAz96ouO00NYM=.a600c34d-0833-445f-baa8-25c84bc1cb99@github.com>

On Mon, 24 Jan 2022 06:03:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

I think we need to file a CSR to document all that new specifications.

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

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


From serb at openjdk.java.net  Tue Jan 25 19:44:31 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 25 Jan 2022 19:44:31 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <UUefTfjh74HKVNkEVHXM_VfGzwX3OVEPeXSTujOu3ic=.ba3ffc39-db1f-44ae-924f-6082bb43fa53@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Any volunteers to look at this buffer overrun?

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

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


From myano at openjdk.java.net  Wed Jan 26 07:15:33 2022
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 26 Jan 2022 07:15:33 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>
Message-ID: <UFR1vbq0WD_4-5HoGhj8yy_lgCs3aX0Xpclb2qw2kiQ=.82731c00-59f1-4289-ac21-a8182548d9ed@github.com>

On Thu, 28 Oct 2021 08:27:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8275715 bug fixes?
>> 
>> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing

@mrserb Could you tell me the confirmation status of this PR?

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

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


From tnakamura at openjdk.java.net  Wed Jan 26 07:16:51 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Wed, 26 Jan 2022 07:16:51 GMT
Subject: RFR: 8139173: [macosx] JInternalFrame shadow is not properly drawn
Message-ID: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>

JInternalFrame's bottom area is not properly drawn with Aqua LAF.
This problem remained for long time, but we recognized it recently.

According to the bug report, it depends on MacOS's version. I don't have old ones (10.10 and 10.11 in the report), but the current MacOS can recreate the issue. I confirmed the following OS versions recreated this issue and this patch could solve it.

Mojave 10.14.6
Catalina 10.15.7
Big Sur 11.6.2
Monterey 12.1

jtreg "javax/swing" and "java/awt" have no regression.

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

Commit messages:
 - 8139173: [macosx] JInternalFrame shadow is not properly drawn

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

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


From serb at openjdk.java.net  Wed Jan 26 20:42:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 26 Jan 2022 20:42:34 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
Message-ID: <CTAVntYodTAaPk6eE1YXSVzYusVeOqp9jkypx3ood0Y=.b2d74913-42a4-4cf4-9d1b-237b5962f051@github.com>

On Fri, 14 Jan 2022 19:09:53 GMT, Phil Race <prr at openjdk.org> wrote:

> Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 
> 
> See the bug for more info.

Probably we have some tests which may validate that even if our handlers are not default the external handler will call ours by chain(or something like that)? Or maybe we should restore them?

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

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


From aivanov at openjdk.java.net  Wed Jan 26 21:30:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 26 Jan 2022 21:30:35 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <JUo5AXEH5jU4LdfmlJ5uB6S1w5PElUJsJEDHE4WwT-w=.fc235aa7-5957-4de3-8c3b-bd56f7c11d91@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

I think increasing the buffer according to the scale is correct as the `scale` ? `scale` image where `scale != 1` can't fit into the buffer of size 1.

It may not fix other bugs or test failures; buffer overrun is not a good thing and it's fixed.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Wed Jan 26 21:41:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 26 Jan 2022 21:41:37 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <mfOtJzaDeaf-XbY0UHrm2hubhWusF4zeLR5Bs8hYmuI=.2cb4dc85-063f-48c6-a4cb-0f3bcc09f033@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

I wonder if a similar problem exist on Windows and Linux. The `pixelArray` is allocated as `new int[bounds.width*bounds.height]` in both. And for macOS too: `CRobot.getRGBPixels` allocates the array of size `bounds.width*bounds.height`, shouldn't it be twice as large if uiScale=2.0 is in effect?

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

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


From prr at openjdk.java.net  Wed Jan 26 22:07:31 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 26 Jan 2022 22:07:31 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <rBCbchAaZZUuZA03Aw1ApkjLTrrEzdOFMGSs9wgYKNk=.d7581fbc-9a2c-4245-b0fe-677099c9bcf5@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

I noted I was intending to run tests with this patch applied .. I think I did that but of course I've lost them now. I'll try again.

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

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


From prr at openjdk.java.net  Wed Jan 26 22:14:29 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 26 Jan 2022 22:14:29 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
Message-ID: <7A4hoEF2adcnSzqrHDzWzOKwMGzV0oBVYKYEpE9i1no=.0ffb8971-fc00-4c45-9127-5158eb430944@github.com>

On Fri, 14 Jan 2022 19:09:53 GMT, Phil Race <prr at openjdk.org> wrote:

> Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 
> 
> See the bug for more info.

The discussion seems to have gone off somewhere unrelated to this client test.
Feel free to file a hotspot test RFE and let's get the test update pushed

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

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


From prr at openjdk.java.net  Thu Jan 27 00:40:31 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 00:40:31 GMT
Subject: RFR: 8139173: [macosx] JInternalFrame shadow is not properly drawn
In-Reply-To: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
References: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
Message-ID: <ro2Qf17n46S6vlem0YrRNbPxm3a3GktUj5CNLX5D-ds=.f973d1e1-5160-4c38-9fc4-a02697b663c9@github.com>

On Wed, 26 Jan 2022 06:53:42 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> JInternalFrame's bottom area is not properly drawn with Aqua LAF.
> This problem remained for long time, but we recognized it recently.
> 
> According to the bug report, it depends on MacOS's version. I don't have old ones (10.10 and 10.11 in the report), but the current MacOS can recreate the issue. I confirmed the following OS versions recreated this issue and this patch could solve it.
> 
> Mojave 10.14.6
> Catalina 10.15.7
> Big Sur 11.6.2
> Monterey 12.1
> 
> jtreg "javax/swing" and "java/awt" have no regression.

Looks so much better.

test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java line 59:

> 57:             UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel");
> 58:         } catch (Exception e) {
> 59:             throw new RuntimeException("Cannot initialize Aqua L&F");

Really this should not be needed since it is the default. But it should at least stop folks running it on Windows.

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

Marked as reviewed by prr (Reviewer).

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


From duke at openjdk.java.net  Thu Jan 27 00:40:48 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 27 Jan 2022 00:40:48 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for JTableHeader
Message-ID: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>

A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

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

Commit messages:
 - incorporated review changes
 - removed jtreg author tag
 - added copyright year and removed commented lines
 - Merge branch 'master' into JTableHeader_8016524
 - JtableHeader Bottom line issue fix

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

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


From serb at openjdk.java.net  Thu Jan 27 00:40:49 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 00:40:49 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <dPMO2IJ1a1W1gEc44iuJeMOunaLfY8O_JlgMOXdKqLs=.97bce24f-7406-4dd0-9030-480251d2b56c@github.com>

On Wed, 26 Jan 2022 00:12:17 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2014, 2022, Oracle and/or its affiliates. All rights reserved.

The first date is the date when the file was created, the second date is a date when it was updated last time. So you do not need to add a new one, just update the second.

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 74:

> 72: 
> 73:         // get JTableHeader coordinate position on screen (x,y)
> 74:         Point point = table.getTableHeader().getLocationOnScreen();

The table is a Swing component it should be accessed on the EDT. (the same comment for the header below)

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 101:

> 99:         }
> 100:     }
> 101: }

The frame should be disposed at the end of the test.

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

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


From duke at openjdk.java.net  Thu Jan 27 00:40:49 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 27 Jan 2022 00:40:49 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: <dPMO2IJ1a1W1gEc44iuJeMOunaLfY8O_JlgMOXdKqLs=.97bce24f-7406-4dd0-9030-480251d2b56c@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <dPMO2IJ1a1W1gEc44iuJeMOunaLfY8O_JlgMOXdKqLs=.97bce24f-7406-4dd0-9030-480251d2b56c@github.com>
Message-ID: <GJJ0Pq1HeX5ClaPLeSoGFzYX9yv47K3SXNI-WEm3ezU=.a8fb2f4a-1ed4-48f0-9f94-a5e4a88463d7@github.com>

On Wed, 26 Jan 2022 20:29:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2011, 2014, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> The first date is the date when the file was created, the second date is a date when it was updated last time. So you do not need to add a new one, just update the second.

Updated the year

> test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 74:
> 
>> 72: 
>> 73:         // get JTableHeader coordinate position on screen (x,y)
>> 74:         Point point = table.getTableHeader().getLocationOnScreen();
> 
> The table is a Swing component it should be accessed on the EDT. (the same comment for the header below)

Updated - table and header accessed only on EDT

> test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 101:
> 
>> 99:         }
>> 100:     }
>> 101: }
> 
> The frame should be disposed at the end of the test.

frame disposed

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

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


From vdyakov at openjdk.java.net  Thu Jan 27 00:58:29 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 27 Jan 2022 00:58:29 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <QuOSmjgmCeMN9M51XocWoBg_qQDr55n75wxeTOBOc2A=.dd9e6835-f037-4c9c-ba7e-4936e3fc00d8@github.com>

On Wed, 26 Jan 2022 00:12:17 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

@prsadhuk please review

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

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


From serb at openjdk.java.net  Thu Jan 27 02:35:29 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 02:35:29 GMT
Subject: RFR: 8139173: [macosx] JInternalFrame shadow is not properly drawn
In-Reply-To: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
References: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
Message-ID: <tcrqis5oWduXCqi93Fm1ivrmDsipjb_NXTmfWxfFszE=.ec8c4023-a30b-4201-b1cc-b6f3e2e43c49@github.com>

On Wed, 26 Jan 2022 06:53:42 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> JInternalFrame's bottom area is not properly drawn with Aqua LAF.
> This problem remained for long time, but we recognized it recently.
> 
> According to the bug report, it depends on MacOS's version. I don't have old ones (10.10 and 10.11 in the report), but the current MacOS can recreate the issue. I confirmed the following OS versions recreated this issue and this patch could solve it.
> 
> Mojave 10.14.6
> Catalina 10.15.7
> Big Sur 11.6.2
> Monterey 12.1
> 
> jtreg "javax/swing" and "java/awt" have no regression.

src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java line 383:

> 381:         int h = inH;
> 382: 
> 383:         h = metrics.titleBarHeight + inH;

Just a suggestion, after the current change it is possible to align the h and other x/y/w vars and make it final.

test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java line 66:

> 64:         robot.delay(1000);
> 65: 
> 66:         Point p = internalFrame.getLocationOnScreen();

The internalFrame is a Swing component so we should call all its methods on EDT.

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

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


From serb at openjdk.java.net  Thu Jan 27 02:40:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 02:40:34 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
Message-ID: <MXqaXFUeddv4wOtmjKGqODrpw0dUYrQlwgtVr-3E3AY=.aa9a5af8-ea90-4e7f-af28-07de5f40dff0@github.com>

On Fri, 14 Jan 2022 19:09:53 GMT, Phil Race <prr at openjdk.org> wrote:

> Some more signal handler related warning strings from the VM need to be excluded from what this test considers a failure 
> 
> See the bug for more info.

I am still not sure can we do something about this, depending on that we should update the test/problem list/file another client bug/another hotspot bug?

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

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


From prr at openjdk.java.net  Thu Jan 27 02:52:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 02:52:33 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <SzGI9P7EqIK8UAbsV53NRdgnSb049M9son_6tUrW9gM=.da985ef4-17b5-4435-b0f6-7ee7eccc21df@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Why doesn't this need updating too ?  Seems like it must be OK else we'd have massive over-runs .. 

  @Override
    public int [] getRGBPixels(final Rectangle bounds) {
        int[] c = new int[bounds.width * bounds.height];
        getScreenPixels(bounds, c);
        return c;
    }

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

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


From prr at openjdk.java.net  Thu Jan 27 03:01:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 03:01:34 GMT
Subject: RFR: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on
 Ubuntu 21.10
In-Reply-To: <MXqaXFUeddv4wOtmjKGqODrpw0dUYrQlwgtVr-3E3AY=.aa9a5af8-ea90-4e7f-af28-07de5f40dff0@github.com>
References: <lcPH8aOpT6Oe6Z_t5hRMjynuNrGsaZOJtvJRVPMT6jc=.814415b7-3487-4b60-aec3-c8604651e023@github.com>
 <MXqaXFUeddv4wOtmjKGqODrpw0dUYrQlwgtVr-3E3AY=.aa9a5af8-ea90-4e7f-af28-07de5f40dff0@github.com>
Message-ID: <qdWAKyuS2g1h12bLOwzddhxKkYFJRNGgA_ewN4BoDjs=.86e056c5-2db3-44d8-b725-485a296032ed@github.com>

On Thu, 27 Jan 2022 02:37:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am still not sure can we do something about this, depending on that we should update the test/problem list/file another client bug/another hotspot bug?

I can't work out what you are saying/expecting.
The test is nothing to do with signals so that is just noise. We already parse out such noise. 
We have two options. Parse out the noise or disable the test because of this irrelevant noise and then miss when the problem it cares about is introduced.
Which is better ?

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

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


From prr at openjdk.java.net  Thu Jan 27 03:22:30 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 03:22:30 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <wSjZRS3yDtqWmjTeKBjIuNrbNU3pvxYmDs1XofvJ1i4=.c4de65f8-7f16-4b8d-a513-253ed4c7d60c@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Looking at what happens in native it seems like it should be possible to add a check that the
Java array has enough capacity to satisfy what the call to retrieve pixels expects. 
I think it would be reasonable to throw InternalError if it does not !

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

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


From tnakamura at openjdk.java.net  Thu Jan 27 04:30:14 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 27 Jan 2022 04:30:14 GMT
Subject: RFR: 8139173: [macosx] JInternalFrame shadow is not properly drawn
 [v2]
In-Reply-To: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
References: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
Message-ID: <uWoAhieP5n9gXZfKbJJbbpJEErSmLNXZZ56WIsY-UYU=.2f734127-a808-48c4-9ca9-b22ccc2473fe@github.com>

> JInternalFrame's bottom area is not properly drawn with Aqua LAF.
> This problem remained for long time, but we recognized it recently.
> 
> According to the bug report, it depends on MacOS's version. I don't have old ones (10.10 and 10.11 in the report), but the current MacOS can recreate the issue. I confirmed the following OS versions recreated this issue and this patch could solve it.
> 
> Mojave 10.14.6
> Catalina 10.15.7
> Big Sur 11.6.2
> Monterey 12.1
> 
> jtreg "javax/swing" and "java/awt" have no regression.

Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:

  Applied review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7228/files
  - new: https://git.openjdk.java.net/jdk/pull/7228/files/44ea0e12..422a9c33

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

  Stats: 27 lines in 2 files changed: 11 ins; 6 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7228/head:pull/7228

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


From tnakamura at openjdk.java.net  Thu Jan 27 04:33:30 2022
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 27 Jan 2022 04:33:30 GMT
Subject: RFR: 8139173: [macosx] JInternalFrame shadow is not properly drawn
 [v2]
In-Reply-To: <ro2Qf17n46S6vlem0YrRNbPxm3a3GktUj5CNLX5D-ds=.f973d1e1-5160-4c38-9fc4-a02697b663c9@github.com>
References: <LoezCfZfhVxpn3C-8g2uMVKRP_wiJ3445-5q-GsvOjI=.00aa3dc9-742b-44b1-947d-49a0740eb78e@github.com>
 <ro2Qf17n46S6vlem0YrRNbPxm3a3GktUj5CNLX5D-ds=.f973d1e1-5160-4c38-9fc4-a02697b663c9@github.com>
Message-ID: <DRl9usUnyLqqH0yPXxTi3a6lviIMFm5NubTrN9EugwE=.eafa6181-0122-461e-b870-ac63f379930c@github.com>

On Thu, 27 Jan 2022 00:36:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied review comments
>
> Looks so much better.

Thank you for reviewing, @prrace @mrserb.
Updated the patch. This testcase is limited to mac only.
> * @requires (os.family == "mac")

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

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


From psadhukhan at openjdk.java.net  Thu Jan 27 05:15:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 27 Jan 2022 05:15:34 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
Message-ID: <X953wirE1Hmw1C9nlexiLpZi2kyLmltFa_3eRm6Xv6k=.744a6069-3cc0-476b-ad57-e67ab639ba09@github.com>

On Mon, 24 Jan 2022 06:03:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

CSR JDK-8280765 added. please review..

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

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


From aturbanov at openjdk.java.net  Thu Jan 27 07:04:33 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 27 Jan 2022 07:04:33 GMT
Subject: Integrated: 8279673: AudioClip.play doesn't work due to
 NullPointerException when creating DataPusher
In-Reply-To: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
References: <fH5Qm--6zy0WReSNnk2tzd1zLWCxv81XAGxBV36drzE=.6f14415f-e1e1-4824-a4c1-b4071f0074e9@github.com>
Message-ID: <MeLImWnNLfvSDfhHM20Q-pu6wwdqqmWbDWH5VaeeIqU=.d3aaedfd-afb8-4715-85ec-601afb6cdd2b@github.com>

On Sun, 14 Nov 2021 20:02:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is possible NPE, when trying to play AudioClip
> 
> import java.applet.AudioClip;
> import java.io.IOException;
> import java.net.URL;
> 
> 
> public class AudioNpe {
>     public static void main(String[] args) throws IOException, InterruptedException {
>         URL url = new URL("https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav");
>         AudioClip content = (AudioClip)url.getContent();
>         content.play();
> 
>         Thread.sleep(10000L);
>     }
> }
> 
> 
> 	  at java.lang.Thread.<init>(Thread.java:393)
> 	  at java.lang.Thread.<init>(Thread.java:760)
> 	  at com.sun.media.sound.JSSecurityManager.createThread(JSSecurityManager.java:115)
> 	  at com.sun.media.sound.DataPusher.start(DataPusher.java:117)
> 	  - locked <0x955> (a com.sun.media.sound.DataPusher)
> 	  at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:202)
> 	  - locked <0x95e> (a com.sun.media.sound.JavaSoundAudioClip)
> 	  at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:152)
> 	  at main.java.AudioNpe.main(AudioNpe.java:12)
> 
> 
> It happens because of bug in `com.sun.media.sound.JSSecurityManager#createThread` implementation: variable `String name`, which supposed to be used - actually unused and `null` thread name is passed to `Thread` constructor.
> 
> After fix - audio clip plays without problems.

This pull request has now been integrated.

Changeset: 2ea0edf2
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ea0edf2c40edde4c191864a40e7a4d741ac0b8e
Stats:     93 lines in 3 files changed: 89 ins; 1 del; 3 mod

8279673: AudioClip.play doesn't work due to NullPointerException when creating DataPusher

Reviewed-by: prr, serb

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

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


From psadhukhan at openjdk.java.net  Thu Jan 27 09:04:12 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 27 Jan 2022 09:04:12 GMT
Subject: RFR: 8278232: [macos] Wrong chars emitted when entering certain
 char-sequence of Indic language [v2]
In-Reply-To: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
References: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
Message-ID: <FOxjElpojgh-oaY9ycgibzDcPH2VsTClYl_uQfVtYpk=.061609df-74cd-4521-a19b-a4a6dfe4bf71@github.com>

> Devanagiri script was not rendered properly in macos after JDK-8068283 due to incorporated check of utf16 string encoding should be more than 2 bytes is not satisfied. 
> Additional check added in JDK-8132503 to ascertain if utf8 string encoding is complex or not was also not satisfied because of which complex Devanagairi unicode text insertion was not working.
> Fix is to add Devanagiri codePoint to the complex list so that it is rendered properly.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Typo fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6979/files
  - new: https://git.openjdk.java.net/jdk/pull/6979/files/227b6287..4cb047d3

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

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

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


From psadhukhan at openjdk.java.net  Thu Jan 27 09:04:13 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 27 Jan 2022 09:04:13 GMT
Subject: Integrated: 8278232: [macos] Wrong chars emitted when entering certain
 char-sequence of Indic language
In-Reply-To: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
References: <CzXNkUTtmTFfCmI5V7Z6qfBt70wihpEuIQmmzaJ1YkQ=.bc9df937-4ffc-41ff-82c7-abc55fcda09c@github.com>
Message-ID: <AapEl6DtIV1ADS8QHpd1OdxigG-zdPxyX1pg1Gci6CY=.76803aaf-caeb-430f-a0ae-e00abd5e7005@github.com>

On Thu, 6 Jan 2022 11:03:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Devanagiri script was not rendered properly in macos after JDK-8068283 due to incorporated check of utf16 string encoding should be more than 2 bytes is not satisfied. 
> Additional check added in JDK-8132503 to ascertain if utf8 string encoding is complex or not was also not satisfied because of which complex Devanagairi unicode text insertion was not working.
> Fix is to add Devanagiri codePoint to the complex list so that it is rendered properly.

This pull request has now been integrated.

Changeset: 94380d0e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94380d0e464a491977ed2b5f1998a55cfe73c3c6
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8278232: [macos] Wrong chars emitted when entering certain char-sequence of Indic language

Reviewed-by: prr

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

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


From dbatrak at openjdk.java.net  Thu Jan 27 09:22:32 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Thu, 27 Jan 2022 09:22:32 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <vVlSMUGVZfenJVboUcGRQVvSznLPLMTZvb0Uer92j3Y=.9111dadd-fcc0-45af-bf77-0aa598a55cb3@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Still needs a reviewer.

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

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


From psadhukhan at openjdk.java.net  Thu Jan 27 09:40:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 27 Jan 2022 09:40:34 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>

On Wed, 26 Jan 2022 00:12:17 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

Changes requested by psadhukhan (Reviewer).

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 26:

> 24: /*
> 25: @test
> 26: @bug 8016524

we normally align the jtreg tags using "*" same as the copyright header..

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 42:

> 40: import javax.swing.table.JTableHeader;
> 41: 
> 42: public class Bug8016524 {

we normally use descriptive test name not bugid in testname anymore..
You can see other regression test in javax/swing test folder

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 66:

> 64:         final int header_dim[] = new int[2];
> 65:         Robot robot = new Robot();
> 66:         robot.setAutoDelay(20);

We normally set autodelay value to 100

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 105:

> 103:         // if pixel color is white then border not visible, throw Exception
> 104:         if(lowerLeft.getRGB() == WHITE_RGB || lowerRight.getRGB() == WHITE_RGB)
> 105:         {

as per coding style, the { should be at the same line

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 106:

> 104:         if(lowerLeft.getRGB() == WHITE_RGB || lowerRight.getRGB() == WHITE_RGB)
> 105:         {
> 106:             throw new RuntimeException("JTableHeader Bottom Border not visible");

Not sure this check is correct. If we have dark theme or the background is changed in system, then I guess the test will fail even with fix. Maybe you can set the JTable background to white explicitly.

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 111:

> 109:             Thread.sleep(1000);
> 110:         } catch (InterruptedException e)
> 111:         {

please rectify { style as above

test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 114:

> 112:             throw new RuntimeException(e);
> 113:         }
> 114:         frame.dispose();

frame should be disposed irrespective of whether it fails or pass.
Also, it should be under EDT too.

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

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


From psadhukhan at openjdk.java.net  Thu Jan 27 09:40:35 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 27 Jan 2022 09:40:35 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader
In-Reply-To: <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
Message-ID: <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>

On Thu, 27 Jan 2022 09:25:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.
>
> test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 114:
> 
>> 112:             throw new RuntimeException(e);
>> 113:         }
>> 114:         frame.dispose();
> 
> frame should be disposed irrespective of whether it fails or pass.
> Also, it should be under EDT too.

The test is not marked for mac only and I see it fails in my ubuntu locally.
Did you try running the test in CI system?

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

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


From prr at openjdk.java.net  Thu Jan 27 17:41:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 17:41:40 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <M6RLZZpgPqKjpBiE-t6NzmvTvZ2yoP5KusQ6kbrvyLI=.6d599e26-9c41-453f-b139-53980894f1f6@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

My testing looks good - but waiting on answers to the other questions

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

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


From trebari at openjdk.java.net  Thu Jan 27 18:17:35 2022
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 27 Jan 2022 18:17:35 GMT
Subject: RFR: 8264743: Add forRemoval for deprecated classes and method in
 javax/swing/plaf/basic
In-Reply-To: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
References: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
Message-ID: <-vt5ZyrqSQU04YjDAQ-WSh-331vSKi8eakfGWc7bPXI=.3c21e241-cad5-4059-ba2c-0bf87040aa3f@github.com>

On Mon, 24 Jan 2022 09:38:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few methods and classes were deprecated in JDK-8049700 where it was decided to add forRemoval in jdk19. 
> Added "forRemoval" to start the process of removing in near future jdk release.

Marked as reviewed by trebari (Committer).

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

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


From serb at openjdk.java.net  Thu Jan 27 18:18:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 18:18:34 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <mfOtJzaDeaf-XbY0UHrm2hubhWusF4zeLR5Bs8hYmuI=.2cb4dc85-063f-48c6-a4cb-0f3bcc09f033@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <mfOtJzaDeaf-XbY0UHrm2hubhWusF4zeLR5Bs8hYmuI=.2cb4dc85-063f-48c6-a4cb-0f3bcc09f033@github.com>
Message-ID: <pNqr-4dxaxNoYS4et0kTaMWhvdG4tR24wVBBrY0TuPs=.37baa1de-c1ba-4872-8ea6-934910589305@github.com>

On Wed, 26 Jan 2022 21:38:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I wonder if a similar problem exist on Windows and Linux. The pixelArray is allocated as new int[bounds.width*bounds.height] in both. And for macOS too: CRobot.getRGBPixels allocates the array of size bounds.width*bounds.height, shouldn't it be twice as large if uiScale=2.0 is in effect?

On Linux and Windows we pass the size of the area to the system in the device space, so we store an image of the size we just allocated. The macOS is different we pass the coordinates in the users space -> when we pass 1x1 we may get 4x4 on the HiDPI screen, this is what the current fix changed.

>Why doesn't this need updating too ? Seems like it must be OK else we'd have massive over-runs ..

We do not need to change other getRGBPixels() method because its coordinates already converted to the pixels(device space), we do this in the shared code. Note that the method which changed by this fix however use the "1" as a width and height in the users space - this is a bug.

>Looking at what happens in native it seems like it should be possible to add a check that the
Java array has enough capacity to satisfy what the call to retrieve pixels expects.
I think it would be reasonable to throw InternalError if it does not !

The logic we use is this:
 1 We prepared the pixel storage using device space coordinates
 2 We capture the 1x1 unit in the users space, usually this is 1x1 pixel on lowdpi and 4x4 on hidpi screen, actually macOS may return any size
 3 If the macOS return some other size we down/up [scale](https://github.com/openjdk/jdk/blob/cab590517bf705418c7376edd5d7066b13b6dde8/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L352) it to the size we calculated at step 1

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

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


From serb at openjdk.java.net  Thu Jan 27 18:19:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 18:19:35 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <E1hEkkOwQiHLhzDbpLFVn2wiONDpgS8XJtVJGHx5zRY=.89067e96-929b-4961-b123-6ab8d55b209d@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

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

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


From kcr at openjdk.java.net  Thu Jan 27 18:24:39 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 27 Jan 2022 18:24:39 GMT
Subject: RFR: 8264743: Add forRemoval for deprecated classes and method in
 javax/swing/plaf/basic
In-Reply-To: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
References: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
Message-ID: <c8rg728C-Yh-tqtqqU_IX82t4Fw6XuKG-rtA0OsZwCE=.6e78f67f-a329-4ae4-aea9-975501af2029@github.com>

On Mon, 24 Jan 2022 09:38:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few methods and classes were deprecated in JDK-8049700 where it was decided to add forRemoval in jdk19. 
> Added "forRemoval" to start the process of removing in near future jdk release.

This needs a CSR. Please issue the `/csr` command, and then create a CSR in JBS.

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

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


From prr at openjdk.java.net  Thu Jan 27 18:49:32 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 Jan 2022 18:49:32 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <Pb-Na9EXM9QrSAUvtzcm71CKdhXO9-0CSaxE1MIOFCY=.18ff03ed-796b-48b5-aa0b-f2f9ce5b17ef@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

I get that getPixelColor() / getRGBPixel() takes only a coordinate but when looking at CRobotPeer it is far from obvious why there is this inconsistency.  If we can't make the shared code consistent - maybe add a scale parameter ? Then at least we should have some comments.
But why are X11 and Windows fine with no scale ?

X11:
    @Override
    public int getRGBPixel(int x, int y) {
        int[] pixelArray = new int[1];
        getRGBPixelsImpl(xgc, x, y, 1, 1, pixelArray, useGtk);
        return pixelArray[0];
    }

Windows :
    @Override
    public int getRGBPixel(int x, int y) {
         // See 7002846: that's ineffective, but works correctly with non-opaque windows
        return getRGBPixels(new Rectangle(x, y, 1, 1))[0];
    }

And in native what I was suggesting was a safeguard that would have detected this problem - which I still think would be a good idea.

BTW "usually this is 1x1 pixel on lowdpi and 4x4 on hidpi screen, actually macOS may return any size"

When might it return "any size" ?
My experiments show scale==2 no matter what scale I use in the macos Display settings for the built-in retina

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

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


From duke at openjdk.java.net  Thu Jan 27 19:56:20 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 27 Jan 2022 19:56:20 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v2]
In-Reply-To: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
Message-ID: <eHqj_meEMcubaT0hKtAeEGEaYQAXBedUlQ_k3EaIaR4=.b1b1502f-ffd4-44e6-8e9f-f802d8041a8c@github.com>

> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
> 
> @shurymury 
> 
> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8278828-ws
 - Added JTextArea createTextArea() in AccessibleTextTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6844/files
  - new: https://git.openjdk.java.net/jdk/pull/6844/files/4166cb38..d0dfe970

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

  Stats: 42714 lines in 1488 files changed: 27723 ins; 8795 del; 6196 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6844.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6844/head:pull/6844

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


From duke at openjdk.java.net  Thu Jan 27 21:47:04 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 27 Jan 2022 21:47:04 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v3]
In-Reply-To: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
Message-ID: <zt7D7C5IRyTxqO-bbcujyfVhQ0hu7GfVmhnksZexL1c=.73182c68-5d94-4360-abea-166dc47b23f2@github.com>

> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
> 
> @shurymury 
> 
> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">

lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8278828-ws
 - Fixed instruction for createTextArea()
 - Merge branch 'openjdk:master' into jdk-8278828-ws
 - Added JTextArea createTextArea() in AccessibleTextTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6844/files
  - new: https://git.openjdk.java.net/jdk/pull/6844/files/d0dfe970..be7db90a

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

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

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


From duke at openjdk.java.net  Thu Jan 27 21:47:07 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 27 Jan 2022 21:47:07 GMT
Subject: RFR: 8278828 : java/awt/a11y/AccessibleTextTest.java's
 createTextArea() just shows instructions on the UI [v2]
In-Reply-To: <eHqj_meEMcubaT0hKtAeEGEaYQAXBedUlQ_k3EaIaR4=.b1b1502f-ffd4-44e6-8e9f-f802d8041a8c@github.com>
References: <lUZ_t3uGgmRCL_I4jS_kmf7SBjW9FMFyt8e85GwAe4c=.c7f668a3-96e6-4fb9-9398-efa91fcd8cfc@github.com>
 <eHqj_meEMcubaT0hKtAeEGEaYQAXBedUlQ_k3EaIaR4=.b1b1502f-ffd4-44e6-8e9f-f802d8041a8c@github.com>
Message-ID: <GeG4xk11cfD6IlsIj5R0TqLoDAVLtup8sdagxZzOwQM=.968f0b9b-e7c2-476d-9242-acc2806df012@github.com>

On Thu, 27 Jan 2022 19:56:20 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> 1) Test scenario was just showing test instruction with JTextArea. So added the JTextArea as the instruction and method says. 
>> 2) JTextArea is filled with contents so that and an Emoji character making sure that screen reader can read Emoji also.
>> 3) Now user can user arrow keys to navigate the JTextArea and screen reader can read it.
>> 
>> @shurymury 
>> 
>> Attached the screen shot of the test UI which contains JTextArea along with the instruction.
>> <img width="623" alt="Screen Shot 2021-12-14 at 7 09 14 PM" src="https://user-images.githubusercontent.com/87324768/146111187-29f81aab-a138-442d-90bd-df24d512fe01.png">
>
> lawrence.andrews has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8278828-ws
>  - Added JTextArea createTextArea() in AccessibleTextTest.java

@savoptik  , I have updated the instruction and corrected the exceptionString.

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

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


From duke at openjdk.java.net  Thu Jan 27 22:19:25 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Thu, 27 Jan 2022 22:19:25 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
Message-ID: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>

Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.

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

Commit messages:
 - updated JTable docs for tableChanged method

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

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


From serb at openjdk.java.net  Thu Jan 27 22:50:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 27 Jan 2022 22:50:12 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <Pb-Na9EXM9QrSAUvtzcm71CKdhXO9-0CSaxE1MIOFCY=.18ff03ed-796b-48b5-aa0b-f2f9ce5b17ef@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <Pb-Na9EXM9QrSAUvtzcm71CKdhXO9-0CSaxE1MIOFCY=.18ff03ed-796b-48b5-aa0b-f2f9ce5b17ef@github.com>
Message-ID: <Z9ksYR_6PqaQ6Pb6QOzYC61cBG1-AJod7A_56q86ihY=.876a4de9-d1fd-437a-98ae-c32c661d382b@github.com>

On Thu, 27 Jan 2022 18:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

> But why are X11 and Windows fine with no scale ?

Since the coordinates are in the device space, and we pass this coordinates to the OS as is, and the OS returns the images of the requested size we do not need to use a scale there. Unlike macOS where we should have coordinates in the user space and device space at the same time. So instead of the second coordinates we pass the scale and calculate others coordinate.

> BTW "usually this is 1x1 pixel on lowdpi and 4x4 on hidpi screen, actually macOS may return any size"
> 
> When might it return "any size" ? My experiments show scale==2 no matter what scale I use in the macos Display settings for the built-in retina

Per the specification of the method we use: [kCGWindowImageBestResolution](https://developer.apple.com/documentation/coregraphics/cgwindowimageoption/kcgwindowimagebestresolution). So when we request the area in the user space, that method may return low/hi/something in between/ image, then we convert/scale that image to fit the array we allocated.

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

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


From prr at openjdk.java.net  Fri Jan 28 00:47:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 00:47:10 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
Message-ID: <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>

On Thu, 27 Jan 2022 22:11:27 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.

src/java.desktop/share/classes/javax/swing/JTable.java line 4423:

> 4421:      * coordinate system of the view for the row; the appropriate
> 4422:      * mapping to the view coordinate system is performed by this
> 4423:      * <code>JTable</code> when it receives the event.

A few things
- since most of the doc is changing we can update to use the more modern {@code ...} instead
- the 2nd clause is now only about the columns so should say "the appropriate mapping of the column to"
- there's no @param tag .. how come doclint isn't complaining ? But we should fix it.
- This will require a CSR.
Oh and I assume you can confirm that you verified the above is 100% true .. and there's no need to mention RowSorter - can you point to where the event is created ?

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

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


From prr at openjdk.java.net  Fri Jan 28 00:49:11 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 00:49:11 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <Y2VUw48_nHueY3S0al7P-UedhCp4hYCYKJcfaiHAAuw=.370415b4-8db8-4295-ab0d-872a59b5ae26@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

- So this is crying out for comments in the source code 
- I still see a need for a safety check in native code

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

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


From serb at openjdk.java.net  Fri Jan 28 01:17:13 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 Jan 2022 01:17:13 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <Y2VUw48_nHueY3S0al7P-UedhCp4hYCYKJcfaiHAAuw=.370415b4-8db8-4295-ab0d-872a59b5ae26@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <Y2VUw48_nHueY3S0al7P-UedhCp4hYCYKJcfaiHAAuw=.370415b4-8db8-4295-ab0d-872a59b5ae26@github.com>
Message-ID: <guKRvC5JdriJTm8MvDUbLtvcu3NTF6QE0b_3eCst74Y=.25fe4124-27b4-4bd6-88f4-b58e9e6d6180@github.com>

On Fri, 28 Jan 2022 00:45:46 GMT, Phil Race <prr at openjdk.org> wrote:

>     * I still see a need for a safety check in native code

I can add some check but which one? In the native we should use the bounds we passed from java side, the problem is that we pass "1 * scale" = 'scale", but allocate the array as "new int[1]" so this is an issue on that java side in the changed method.

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

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


From duke at openjdk.java.net  Fri Jan 28 02:18:11 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 28 Jan 2022 02:18:11 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
 <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>
Message-ID: <OfvM6omMNGeOY7SBGuza6f-HOt-3hbgQNRdnW8qfJ70=.d176423a-1dad-4f21-be8c-1b97fc4904ac@github.com>

On Fri, 28 Jan 2022 00:44:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 4423:
> 
>> 4421:      * coordinate system of the view for the row; the appropriate
>> 4422:      * mapping to the view coordinate system is performed by this
>> 4423:      * <code>JTable</code> when it receives the event.
> 
> A few things
> - since most of the doc is changing we can update to use the more modern {@code ...} instead
> - the 2nd clause is now only about the columns so should say "the appropriate mapping of the column to"
> - there's no @param tag .. how come doclint isn't complaining ? But we should fix it.
> - This will require a CSR.
> Oh and I assume you can confirm that you verified the above is 100% true .. and there's no need to mention RowSorter - can you point to where the event is created ?

@prrace Should all instances of "code tags" (entire JTable) changed to {@code...} or for the tableChanged method only?
I was not able to understand the last point clearly. Can you please elaborate?

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

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


From prr at openjdk.java.net  Fri Jan 28 03:21:10 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 03:21:10 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <OfvM6omMNGeOY7SBGuza6f-HOt-3hbgQNRdnW8qfJ70=.d176423a-1dad-4f21-be8c-1b97fc4904ac@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
 <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>
 <OfvM6omMNGeOY7SBGuza6f-HOt-3hbgQNRdnW8qfJ70=.d176423a-1dad-4f21-be8c-1b97fc4904ac@github.com>
Message-ID: <D1WGmSk8QbLzBQe9FF6R2iTyoZRzdKXLvItIFfx0lxI=.6a7ea6ac-784d-47af-b6b3-7f74078e47a6@github.com>

On Fri, 28 Jan 2022 02:13:46 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 4423:
>> 
>>> 4421:      * coordinate system of the view for the row; the appropriate
>>> 4422:      * mapping to the view coordinate system is performed by this
>>> 4423:      * <code>JTable</code> when it receives the event.
>> 
>> A few things
>> - since most of the doc is changing we can update to use the more modern {@code ...} instead
>> - the 2nd clause is now only about the columns so should say "the appropriate mapping of the column to"
>> - there's no @param tag .. how come doclint isn't complaining ? But we should fix it.
>> - This will require a CSR.
>> Oh and I assume you can confirm that you verified the above is 100% true .. and there's no need to mention RowSorter - can you point to where the event is created ?
>
> @prrace Should all instances of "code tags" (entire JTable) changed to {@code...} or for the tableChanged method only?
> I was not able to understand the last point clearly. Can you please elaborate?

I said most of the doc is changing which is clearly not most of the doc for JTable so it means just this method.

To the latter point the doc you are proposing is asserting that it does not apply to rows.
Now since we also know this is all supposed to be code called ny the implementation and responded to by the implementation and even so we are NOT going to change anything because some code somewhere would break, nontheless we want to be sure the new code is what actually happens and not just what someone wrote in a  bug report several years ago. So go find the code that calls "new TableModelEvent" and point in this PR to how it guarantees the rows are in view order.

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

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


From prr at openjdk.java.net  Fri Jan 28 04:06:11 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 04:06:11 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <guKRvC5JdriJTm8MvDUbLtvcu3NTF6QE0b_3eCst74Y=.25fe4124-27b4-4bd6-88f4-b58e9e6d6180@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <Y2VUw48_nHueY3S0al7P-UedhCp4hYCYKJcfaiHAAuw=.370415b4-8db8-4295-ab0d-872a59b5ae26@github.com>
 <guKRvC5JdriJTm8MvDUbLtvcu3NTF6QE0b_3eCst74Y=.25fe4124-27b4-4bd6-88f4-b58e9e6d6180@github.com>
Message-ID: <xeByuG6LgH3zXT4WlUpahyuMyHIZTj9bN5JaoL_2jL8=.584bd0b7-7041-4790-8f73-bc61055c1165@github.com>

On Fri, 28 Jan 2022 01:13:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > ```
> > * I still see a need for a safety check in native code
> > ```
> 
> 
> I can add some check but which one? In the native we should use the bounds we passed from java side, the problem is that we pass "1 * scale" = 'scale", but allocate the array as "new int[1]" so this is an issue on that java side in the changed method.
Isn't the over-run supposed to be here :

JNIEXPORT void JNICALL
Java_sun_lwawt_macosx_CRobot_nativeGetScreenPixels
(JNIEnv *env, jobject peer,
 jint x, jint y, jint width, jint height, jdouble scale, jintArray pixels)



 void *jPixelData = (*env)->GetPrimitiveArrayCritical(env, pixels, 0);

  CGContextRef jPicContextRef = CGBitmapContextCreate(
                                            jPixelData,
                                            picWidth, picHeight,
                                            8, picWidth * sizeof(jint),
                                            picColorSpace,
                                            kCGBitmapByteOrder32Host |
                                            kCGImageAlphaPremultipliedFirst)

And then the apple docs at https://developer.apple.com/documentation/coregraphics/1455939-cgbitmapcontextcreate/ say
about the 1st parameter :
Data

    A pointer to the destination in memory where the drawing is to be rendered. The size of this memory block should be at least (bytesPerRow*height) bytes.
and picWidth * sizeof(jint), is bytes per row.
    So if it the Java array pixels  is just one int (4 bytes) and we have a scale of 2 when it needs to be 4 ints (16 bytes) we'd have the over-run ? 
Then why can't we just  make sure (*env)->GetArrayLength(env, pixels) >= picWidth * picHeight ??

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

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


From psadhukhan at openjdk.java.net  Fri Jan 28 04:30:10 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 28 Jan 2022 04:30:10 GMT
Subject: RFR: 8264743: Add forRemoval for deprecated classes and method in
 javax/swing/plaf/basic
In-Reply-To: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
References: <oQFB2jA6t41oYM-MRv5cFGQVF4hA0z2s2aUTDfTwph8=.1182a3de-cf2d-4b87-8c15-6e8e130bf191@github.com>
Message-ID: <BQDk8UNSc5WrVm-0wlevwVdtLoIPCAFHtS_49MhZ4jE=.cf4cff50-0421-48d5-8eb6-701e99429c3a@github.com>

On Mon, 24 Jan 2022 09:38:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Few methods and classes were deprecated in JDK-8049700 where it was decided to add forRemoval in jdk19. 
> Added "forRemoval" to start the process of removing in near future jdk release.

CSR added .JDK-8280846. Please review

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

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


From serb at openjdk.java.net  Fri Jan 28 05:18:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 Jan 2022 05:18:11 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <xeByuG6LgH3zXT4WlUpahyuMyHIZTj9bN5JaoL_2jL8=.584bd0b7-7041-4790-8f73-bc61055c1165@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <Y2VUw48_nHueY3S0al7P-UedhCp4hYCYKJcfaiHAAuw=.370415b4-8db8-4295-ab0d-872a59b5ae26@github.com>
 <guKRvC5JdriJTm8MvDUbLtvcu3NTF6QE0b_3eCst74Y=.25fe4124-27b4-4bd6-88f4-b58e9e6d6180@github.com>
 <xeByuG6LgH3zXT4WlUpahyuMyHIZTj9bN5JaoL_2jL8=.584bd0b7-7041-4790-8f73-bc61055c1165@github.com>
Message-ID: <V6toxOGpQRfsnaWfj9k1YOY2832ZZ_En0htIniEBV7Y=.2a366802-3897-4dcc-a941-80d2884ab095@github.com>

On Fri, 28 Jan 2022 04:03:00 GMT, Phil Race <prr at openjdk.org> wrote:

>A pointer to the destination in memory where the drawing is to be rendered. The size of this memory block should be at least (bytesPerRow*height) bytes. and picWidth * sizeof(jint), is bytes per row.
So if it the Java array pixels is just one int (4 bytes) and we have a scale of 2 when it needs to be 4 ints (16 bytes) we'd have the over-run ? 

If the scale is 2 then we will need 4 ints overall, but only 2 ints per row, since we will have 2 rows.

>Then why can't we just make sure (*env)->GetArrayLength(env, pixels) >= picWidth * picHeight ??

We can for sure, I can update the fix.

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

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


From duke at openjdk.java.net  Fri Jan 28 09:03:14 2022
From: duke at openjdk.java.net (Maxim Kartashev)
Date: Fri, 28 Jan 2022 09:03:14 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <hF1Qd7SmYg057CE10hRb5qovgqk1iYlSulpMCStVsRI=.9585f023-6941-47f2-b34a-8f0e2159db31@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

FWIW there's a related problem on Linux where the size of the captured area is [scaled down in the native code](https://github.com/openjdk/jdk/blob/973dda5ce0747a8ea67ec3a34c2ef2a0b2b6b140/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c#L2874), which in case of capturing just one pixel might end up being 0 for scales 300%+. I just filed [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861) for that and the issue with coordinates scaling on Linux.

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

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


From psadhukhan at openjdk.java.net  Fri Jan 28 09:44:28 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 28 Jan 2022 09:44:28 GMT
Subject: RFR: 8241192: [macosx] Wrong letter typed after =?UTF-8?B?wrQ=?=
 symbol when using Finnish layout
Message-ID: <FrPt5p9Wh_Bqdu9qE0PqSr-41wsNalEgkg-v2KRc4sc=.3c0c2eeb-52a6-4c97-ba48-d550cd2892e6@github.com>

If we press " ? " (on U.S. keyboard layout it is the [+] button just before the [delete] button), and then press "s" , 2 "?" characters are entered in a text field instead of "?s" with "Finish" keyboard layout.
This is because, although " ? " is construed as "complex" char and inserted properly the next "s" character is treated as non-complex character as it's utf8Length is 1 and utf16Length is 2, so we need to explicitly make it a "complex" char sequence if the code point is 0x73 ie "s" in Finnish layout for it to be inserted properly.

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

Commit messages:
 - 8241192: [macosx] Wrong letter typed after ? symbol when using Finnish layout
 - 8241192: [macosx] Wrong letter typed after ? symbol when using Finnish layout

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

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


From serb at openjdk.java.net  Fri Jan 28 09:47:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 Jan 2022 09:47:15 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <hF1Qd7SmYg057CE10hRb5qovgqk1iYlSulpMCStVsRI=.9585f023-6941-47f2-b34a-8f0e2159db31@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <hF1Qd7SmYg057CE10hRb5qovgqk1iYlSulpMCStVsRI=.9585f023-6941-47f2-b34a-8f0e2159db31@github.com>
Message-ID: <O8_0yGE7bcSo8eNcYlXDJ-BB3Gr0Kmjk-1S7Kti7Hd8=.e811eb9f-ed0d-47dc-9299-9f5055079bae@github.com>

On Fri, 28 Jan 2022 09:00:25 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> I just filed [JDK-8280861](https://bugs.openjdk.java.net/browse/JDK-8280861) for that and the issue with coordinates scaling on Linux.

It looks similar to what is done on macOS where two types of coordinates are needed: the user's space to pass to the GTK and the device space to create storage for the pixels. Be careful to not desync them as we did on macOS here.

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

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


From serb at openjdk.java.net  Fri Jan 28 09:58:10 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 28 Jan 2022 09:58:10 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <7KzuciywOHkrs2j5OFeXdlQ5JMU0bqIYczt7tTl0fO0=.879d329d-0c98-4514-a928-f6d4edcaa0c5@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

You are absolutely right! in case of linux we have the same bug when gtk is used. =(

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

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


From duke at openjdk.java.net  Fri Jan 28 20:07:07 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 28 Jan 2022 20:07:07 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <D1WGmSk8QbLzBQe9FF6R2iTyoZRzdKXLvItIFfx0lxI=.6a7ea6ac-784d-47af-b6b3-7f74078e47a6@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
 <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>
 <OfvM6omMNGeOY7SBGuza6f-HOt-3hbgQNRdnW8qfJ70=.d176423a-1dad-4f21-be8c-1b97fc4904ac@github.com>
 <D1WGmSk8QbLzBQe9FF6R2iTyoZRzdKXLvItIFfx0lxI=.6a7ea6ac-784d-47af-b6b3-7f74078e47a6@github.com>
Message-ID: <zwRz2j6FOS97CdDYGZc7qKiGf_qjf7Ft1MXEodivD6c=.77a6b176-82d6-455a-8ed8-eab98db170bb@github.com>

On Fri, 28 Jan 2022 03:17:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Should all instances of "code tags" (entire JTable) changed to {@code...} or for the tableChanged method only?
>> I was not able to understand the last point clearly. Can you please elaborate?
>
> I said most of the doc is changing which is clearly not most of the doc for JTable so it means just this method.
> 
> To the latter point the doc you are proposing is asserting that it does not apply to rows.
> Now since we also know this is all supposed to be code called ny the implementation and responded to by the implementation and even so we are NOT going to change anything because some code somewhere would break, nontheless we want to be sure the new code is what actually happens and not just what someone wrote in a  bug report several years ago. So go find the code that calls "new TableModelEvent" and point in this PR to how it guarantees the rows are in view order.

@prrace After going through the code, I see that the `new TableModelEvent()` is called in setModel of JTable but I wasn't able to locate the code that does model-to-view coordinate mapping for rows from here. Within the `tableChanged` method I see `sortedTableChanged` method being called if ` sortManager != null ` which in turn calls `convertRowIndexToView` method (which is called when either sorter or model changes and sorting is enabled). I think this is the method that is responsible for mapping coordinate system from model to view for the rows.

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

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


From duke at openjdk.java.net  Fri Jan 28 21:09:28 2022
From: duke at openjdk.java.net (lawrence.andrews)
Date: Fri, 28 Jan 2022 21:09:28 GMT
Subject: RFR: 8202836 : [macosx] test java/awt/Graphics/TextAAHintsTest.java
 fails
Message-ID: <xczogPvBvtw81JtkLcC3NVWSJXYjmyEwpzalCFmySL8=.9fc88820-1e33-46cf-8155-f92eb966e4e5@github.com>

1) Removed =yesno that was causing the test to fail with following exception
test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
After removing =yesno, test was just passing without user interaction so fixed the following

Add the following so that user can user interact with the test
a) Added pass/fail button and instruction for the user to know what he/she is going to test and what is expected.
b) Added Dialog with textarea to enter the reason for the testcase failure. This will help the user to understanding the reason why the test was failed while analyzing the results. 

@shurymury

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

Commit messages:
 - 8202836 : [macosx] test java/awt/Graphics/TextAAHintsTest.java fails

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

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


From aivanov at openjdk.java.net  Fri Jan 28 21:13:14 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 28 Jan 2022 21:13:14 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
Message-ID: <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com>

On Mon, 24 Jan 2022 06:03:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/Component.java line 4701:

> 4699:      *
> 4700:      * @return whether or not paint messages received from the operating system
> 4701:      * should be ignored.

Shall we remove the ending punctuation from `@return` tag for consistency?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7004


From prr at openjdk.java.net  Fri Jan 28 21:35:11 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 21:35:11 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
Message-ID: <xnpwKFrYMxPKdMWeWI35sz1qgcoeoMcnqk1tbixYkmc=.7148056a-abcf-40b9-97f4-6d46f3747ee1@github.com>

On Thu, 27 Jan 2022 22:11:27 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

> Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.

> I  wasn't able to locate the code that does model-to-view coordinate mapping for rows from here.

That's worrying. So maybe it doesn't exist ? 

When I look at TableModelEvent docs it also says at the VERY BEGINNING of the class docs .. 
/**
 * TableModelEvent is used to notify listeners that a table model
 * has changed. The model event describes changes to a TableModel
 * and all references to rows and columns are in the co-ordinate
 * system of the model.

So at the very least then these docs would be wrong too !?!?

I think look at the code that does "new TableModelEvent(...") and it is in methods caller fireTableCellUpdated() which is defined on the TableModel. 

So it goes back to what I said to you earlier (somewhere) - don't just trust what is written in a bug report - verify it.

So I think you should do some more looking at code and actual testing to verify.
Using RowSorter  and/or dragging rows around ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7253


From duke at openjdk.java.net  Fri Jan 28 21:49:08 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Fri, 28 Jan 2022 21:49:08 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <xnpwKFrYMxPKdMWeWI35sz1qgcoeoMcnqk1tbixYkmc=.7148056a-abcf-40b9-97f4-6d46f3747ee1@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
 <xnpwKFrYMxPKdMWeWI35sz1qgcoeoMcnqk1tbixYkmc=.7148056a-abcf-40b9-97f4-6d46f3747ee1@github.com>
Message-ID: <sVoGdFc8_JniEAEVXk1vDLy3sqohgiJQmZM5ZB3mMpI=.2fbdf3bc-b0ee-4be5-885c-933a59788494@github.com>

On Fri, 28 Jan 2022 21:32:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Updated JTable's tableChanged() method docs to explicitly mention the coordinate system of the rows and columns.
>
>> I  wasn't able to locate the code that does model-to-view coordinate mapping for rows from here.
> 
> That's worrying. So maybe it doesn't exist ? 
> 
> When I look at TableModelEvent docs it also says at the VERY BEGINNING of the class docs .. 
> /**
>  * TableModelEvent is used to notify listeners that a table model
>  * has changed. The model event describes changes to a TableModel
>  * and all references to rows and columns are in the co-ordinate
>  * system of the model.
> 
> So at the very least then these docs would be wrong too !?!?
> 
> I think look at the code that does "new TableModelEvent(...") and it is in methods caller fireTableCellUpdated() which is defined on the TableModel. 
> 
> So it goes back to what I said to you earlier (somewhere) - don't just trust what is written in a bug report - verify it.
> 
> So I think you should do some more looking at code and actual testing to verify.
> Using RowSorter  and/or dragging rows around ...

@prrace Thank you. Will look into the code and verify with actual testing as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7253


From aivanov at openjdk.java.net  Fri Jan 28 21:52:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 28 Jan 2022 21:52:06 GMT
Subject: RFR: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <72bAIk_d7gbzdgSmgfThWq-suCD0FMHe1ZqMfu0GoY0=.88919d40-b7bc-4c1d-b0dd-50369f08d476@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6866


From prr at openjdk.java.net  Fri Jan 28 22:22:09 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 Jan 2022 22:22:09 GMT
Subject: RFR: JDK-6998249: Wrong behavior/Javadoc of
 JTable.tableChanged(TableModelEvent e)
In-Reply-To: <zwRz2j6FOS97CdDYGZc7qKiGf_qjf7Ft1MXEodivD6c=.77a6b176-82d6-455a-8ed8-eab98db170bb@github.com>
References: <PNxUtUewAmjbIi6o6qk6LtVom2k5Uh2I34DBLUpmUvQ=.b3f357fb-5903-4e56-9754-451582ee10c1@github.com>
 <RmhW4021wtal2-VLMLDsxXGNySEL8v0TG0F9l3W9Ue4=.4e23fd0e-8dbf-4c53-bc87-4a53a1f7de37@github.com>
 <OfvM6omMNGeOY7SBGuza6f-HOt-3hbgQNRdnW8qfJ70=.d176423a-1dad-4f21-be8c-1b97fc4904ac@github.com>
 <D1WGmSk8QbLzBQe9FF6R2iTyoZRzdKXLvItIFfx0lxI=.6a7ea6ac-784d-47af-b6b3-7f74078e47a6@github.com>
 <zwRz2j6FOS97CdDYGZc7qKiGf_qjf7Ft1MXEodivD6c=.77a6b176-82d6-455a-8ed8-eab98db170bb@github.com>
Message-ID: <CStwx1L7kMrvWX6IM9PVwq6ZKM-GSgCeeYs49rJrvuI=.3d7c06a5-4c6c-4d91-8763-a6323031a65e@github.com>

On Fri, 28 Jan 2022 20:03:10 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> I said most of the doc is changing which is clearly not most of the doc for JTable so it means just this method.
>> 
>> To the latter point the doc you are proposing is asserting that it does not apply to rows.
>> Now since we also know this is all supposed to be code called ny the implementation and responded to by the implementation and even so we are NOT going to change anything because some code somewhere would break, nontheless we want to be sure the new code is what actually happens and not just what someone wrote in a  bug report several years ago. So go find the code that calls "new TableModelEvent" and point in this PR to how it guarantees the rows are in view order.
>
> @prrace After going through the code, I see that the `new TableModelEvent()` is called in setModel of JTable but I wasn't able to locate the code that does model-to-view coordinate mapping for rows from here. Within the `tableChanged` method I see `sortedTableChanged` method being called if ` sortManager != null ` which in turn calls `convertRowIndexToView` method (which is called when either sorter or model changes and sorting is enabled). I think this is the method that is responsible for mapping coordinate system from model to view for the rows.

I was just looking at this same code too - and that's how it looks to me.
So the claim in the report AND the evaluation both look wrong to me.
But verify this with testing. I am not sure but it seems like merely doing whatever it is to install
a RowSorter will ttigger that code path and the code the submitter pointed to is only used if
the model row == the view row ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7253


From mvs at openjdk.java.net  Sat Jan 29 14:03:28 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 29 Jan 2022 14:03:28 GMT
Subject: RFR: 8280913: Create a regression test for
 JRootPane.setDefaultButton() method
Message-ID: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>

This tests the behaviour of the method JRootPane.setDefaultButton() in different platforms with different LAFs.
As per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JRootPane.html#setDefaultButton(javax.swing.JButton), "The default button is the button which will be activated when a UI-defined activation event (typically the Enter key) occurs in the root pane regardless of whether or not the button has keyboard focus (unless there is another component within the root pane which consumes the activation event, such as a JTextPane). ".
This is currently not working in Linux platforms, may be this test could be problem-listed initially for linux-all.
This also fixes and colocates the tonga test Swing_JButton/Automated/bug4659800 written for verifying JDK-4659800.

-------------

Commit messages:
 - 8280913: Create a regression test for JRootPane.setDefaultButton() method

Changes: https://git.openjdk.java.net/jdk/pull/7278/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7278&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280913
  Stats: 123 lines in 2 files changed: 123 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7278.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7278/head:pull/7278

PR: https://git.openjdk.java.net/jdk/pull/7278


From mvs at openjdk.java.net  Sat Jan 29 14:45:46 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 29 Jan 2022 14:45:46 GMT
Subject: RFR: 8280913: Create a regression test for
 JRootPane.setDefaultButton() method [v2]
In-Reply-To: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>
References: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>
Message-ID: <01l-eDUas_l0uwfjpoLs7jsgvnSJcpT3Ly7psTTy07A=.cde8c406-a3ae-46a6-9a92-d78a294a9ae2@github.com>

> This tests the behaviour of the method JRootPane.setDefaultButton() in different platforms with different LAFs.
> As per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JRootPane.html#setDefaultButton(javax.swing.JButton), "The default button is the button which will be activated when a UI-defined activation event (typically the Enter key) occurs in the root pane regardless of whether or not the button has keyboard focus (unless there is another component within the root pane which consumes the activation event, such as a JTextPane). ".
> This is currently not working in Linux platforms, may be this test could be problem-listed initially for linux-all.
> This also fixes and colocates the tonga test Swing_JButton/Automated/bug4659800 written for verifying JDK-4659800.
> 
> This test is run multiple times in different platforms and got 100% success in mac and windows, but failed in linux.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  8280913: Create a regression test for JRootPane.setDefaultButton() method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7278/files
  - new: https://git.openjdk.java.net/jdk/pull/7278/files/dd6e41c2..72876598

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7278&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7278&range=00-01

  Stats: 26 lines in 1 file changed: 23 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7278.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7278/head:pull/7278

PR: https://git.openjdk.java.net/jdk/pull/7278


From mvs at openjdk.java.net  Sun Jan 30 06:30:43 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sun, 30 Jan 2022 06:30:43 GMT
Subject: RFR: 8280913: Create a regression test for
 JRootPane.setDefaultButton() method [v3]
In-Reply-To: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>
References: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>
Message-ID: <lgl13e4jcXUcbST-2m6nz5bhi8C0BDiGX2IZpI5Ksps=.95cade17-25e5-4bfb-8ab5-48e5dff64220@github.com>

> This tests the behaviour of the method JRootPane.setDefaultButton() in different platforms with different LAFs.
> As per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JRootPane.html#setDefaultButton(javax.swing.JButton), "The default button is the button which will be activated when a UI-defined activation event (typically the Enter key) occurs in the root pane regardless of whether or not the button has keyboard focus (unless there is another component within the root pane which consumes the activation event, such as a JTextPane). ".
> 
> This also fixes and colocates the tonga test Swing_JButton/Automated/bug4659800 written for verifying JDK-4659800.
> 
> This test is run multiple times in different platforms and got 100% success in mac and windows, linux.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  8280913: Create a regression test for JRootPane.setDefaultButton() method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7278/files
  - new: https://git.openjdk.java.net/jdk/pull/7278/files/72876598..9ed2cc9b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7278&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7278&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7278.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7278/head:pull/7278

PR: https://git.openjdk.java.net/jdk/pull/7278


From duke at openjdk.java.net  Mon Jan 31 03:50:44 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 03:50:44 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v2]
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <Pry-KzLUSNRhgeC1hbqbNWmmu6qJLpfnN5Aqx6ksSg4=.83f5c70b-a9a6-4281-aa76-78eb924eab2a@github.com>

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  added white background to table and header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7219/files
  - new: https://git.openjdk.java.net/jdk/pull/7219/files/1d1c6329..8f306a5b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=00-01

  Stats: 238 lines in 2 files changed: 122 ins; 116 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7219.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7219/head:pull/7219

PR: https://git.openjdk.java.net/jdk/pull/7219


From duke at openjdk.java.net  Mon Jan 31 04:00:52 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 04:00:52 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v3]
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <TKwcmw9s36V5991Bx83Z55DZtUsm5r2GmDxcVz1pNic=.2afd538d-f27d-4563-b238-829ef5d32a12@github.com>

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  aligned the jtreg header

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7219/files
  - new: https://git.openjdk.java.net/jdk/pull/7219/files/8f306a5b..90a5a7aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7219.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7219/head:pull/7219

PR: https://git.openjdk.java.net/jdk/pull/7219


From duke at openjdk.java.net  Mon Jan 31 06:30:12 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 06:30:12 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v3]
In-Reply-To: <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
Message-ID: <1w8OeRD-llxJzkhq6m_e9KhkddJZPHsplCVMHGc4Ws0=.7731338a-ada7-46f1-8df8-3cda14f68b10@github.com>

On Thu, 27 Jan 2022 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   aligned the jtreg header
>
> test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 106:
> 
>> 104:         if(lowerLeft.getRGB() == WHITE_RGB || lowerRight.getRGB() == WHITE_RGB)
>> 105:         {
>> 106:             throw new RuntimeException("JTableHeader Bottom Border not visible");
> 
> Not sure this check is correct. If we have dark theme or the background is changed in system, then I guess the test will fail even with fix. Maybe you can set the JTable background to white explicitly.

@prsadhuk I have explicitly set the background to white for the table as well as the header.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7219


From duke at openjdk.java.net  Mon Jan 31 06:30:12 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 06:30:12 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v3]
In-Reply-To: <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
 <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>
Message-ID: <EZwRH6aPwYmMTd_cNaVz--j_GpPrePi6EeD1rc41xaM=.d12ee2d7-eb25-4e32-b566-88536ceb99ff@github.com>

On Thu, 27 Jan 2022 09:26:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JTableHeader/8016524/Bug8016524.java line 114:
>> 
>>> 112:             throw new RuntimeException(e);
>>> 113:         }
>>> 114:         frame.dispose();
>> 
>> frame should be disposed irrespective of whether it fails or pass.
>> Also, it should be under EDT too.
>
> The test is not marked for mac only and I see it fails in my ubuntu locally.
> Did you try running the test in CI system?

@prsadhuk I have changed the test case to explicitly set the table and header background to white. Mach5 tests are passing on all platforms including linux now. Can you please let me know in case you are seeing any issues on Ubuntu locally, with the new test case? In order to mark the test as mac only should we specify it this way - `@requires (os.family=="mac") ` in jtreg tag section?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7219


From mvs at openjdk.java.net  Mon Jan 31 06:32:10 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 31 Jan 2022 06:32:10 GMT
Subject: RFR: 8280913: Create a regression test for
 JRootPane.setDefaultButton() method [v3]
In-Reply-To: <lgl13e4jcXUcbST-2m6nz5bhi8C0BDiGX2IZpI5Ksps=.95cade17-25e5-4bfb-8ab5-48e5dff64220@github.com>
References: <D76KamL0skIBLcpAt4VXuwOp8ASLtNtG8XbIw4TO9cg=.2560e40d-7ac8-4013-8c30-5f9ef14c5322@github.com>
 <lgl13e4jcXUcbST-2m6nz5bhi8C0BDiGX2IZpI5Ksps=.95cade17-25e5-4bfb-8ab5-48e5dff64220@github.com>
Message-ID: <fWGB38GT0zNeyswIaPhShOfJawMqnCz653T7iyiSBTY=.c647f2fc-c4ba-4808-8072-1313114d1205@github.com>

On Sun, 30 Jan 2022 06:30:43 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> This tests the behaviour of the method JRootPane.setDefaultButton() in different platforms with different LAFs.
>> As per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JRootPane.html#setDefaultButton(javax.swing.JButton), "The default button is the button which will be activated when a UI-defined activation event (typically the Enter key) occurs in the root pane regardless of whether or not the button has keyboard focus (unless there is another component within the root pane which consumes the activation event, such as a JTextPane). ".
>> 
>> This also fixes and colocates the tonga test Swing_JButton/Automated/bug4659800 written for verifying JDK-4659800.
>> 
>> This test is run multiple times in different platforms and got 100% success in mac and windows, linux.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280913: Create a regression test for JRootPane.setDefaultButton() method

Any volunteers for a review?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7278


From psadhukhan at openjdk.java.net  Mon Jan 31 07:27:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 31 Jan 2022 07:27:07 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v3]
In-Reply-To: <EZwRH6aPwYmMTd_cNaVz--j_GpPrePi6EeD1rc41xaM=.d12ee2d7-eb25-4e32-b566-88536ceb99ff@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
 <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>
 <EZwRH6aPwYmMTd_cNaVz--j_GpPrePi6EeD1rc41xaM=.d12ee2d7-eb25-4e32-b566-88536ceb99ff@github.com>
Message-ID: <_k4TH60mmpl6bPtTLEqzWcI0Ejk-OpuxCHfW_OE8dxA=.8f88460c-d79b-417a-b20b-12ee78ec6427@github.com>

On Mon, 31 Jan 2022 06:25:02 GMT, Harshitha Onkar <duke at openjdk.java.net> wrote:

>> The test is not marked for mac only and I see it fails in my ubuntu locally.
>> Did you try running the test in CI system?
>
> @prsadhuk I have changed the test case to explicitly set the table and header background to white. Mach5 tests are passing on all platforms including linux now. Can you please let me know in case you are seeing any issues on Ubuntu locally, with the new test case?

I now see it fail locally in windows system also along with ubuntu. windows screenshot here where the border is white which is why it fails
![JTheaderBorder](https://user-images.githubusercontent.com/43534309/151753660-92d6021a-30d6-4215-97b0-7ab17ddb88d4.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7219


From psadhukhan at openjdk.java.net  Mon Jan 31 07:39:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 31 Jan 2022 07:39:45 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v6]
In-Reply-To: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
Message-ID: <Mw48bN7VYm4Ka1AIYGJGmdWvUjFruxewuZRIpKeXFJE=.385cfd06-f2fc-4cd4-b5ff-c325db2bba54@github.com>

> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove . to be consistent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7004/files
  - new: https://git.openjdk.java.net/jdk/pull/7004/files/752b7a09..aebc9d70

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004

PR: https://git.openjdk.java.net/jdk/pull/7004


From psadhukhan at openjdk.java.net  Mon Jan 31 07:39:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 31 Jan 2022 07:39:49 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5]
In-Reply-To: <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com>
References: <WKgjZdBHxYefenWgC7bc7IS5p2CC1l-QnWlYT3-GeSk=.1bf11f6d-f01c-43db-bf60-e27e32bd37bc@github.com>
 <THEKiLL3AbDs54D7LhOzKUdKu1Rmz2V8YnOZLv34ONc=.9ac6afa7-d1e8-4126-b4db-619aa6aa96c1@github.com>
 <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com>
Message-ID: <ZvgSBhwV_SxQPA2_uZjxb_6JwM-h8fgrkMBP4si9Ydg=.53f0cfc8-6ffc-4d04-8c09-827af75490c5@github.com>

On Fri, 28 Jan 2022 19:29:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment
>
> src/java.desktop/share/classes/java/awt/Component.java line 4701:
> 
>> 4699:      *
>> 4700:      * @return whether or not paint messages received from the operating system
>> 4701:      * should be ignored.
> 
> Shall we remove the ending punctuation from `@return` tag for consistency?

There are few places in this file too where it still have "." but those are not touched by this PR but I agree in most places we don't have so I removed from the places where we are touching in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7004


From kizune at openjdk.java.net  Mon Jan 31 09:20:25 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 31 Jan 2022 09:20:25 GMT
Subject: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab
 to "Image Radio Buttons" and "Image CheckBoxes"
Message-ID: <8vfRuS7p6OmZ8yzFOZz8vKQ4woiO9VKdE2XGTgL-piQ=.3a04cd23-8665-4076-a0ef-30aa66cf8c46@github.com>

Focus painting for combo box and radio button with custom icon should honour the corresponding property.

-------------

Commit messages:
 - 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Changes: https://git.openjdk.java.net/jdk/pull/7284/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7284&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8216358
  Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7284.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7284/head:pull/7284

PR: https://git.openjdk.java.net/jdk/pull/7284


From kizune at openjdk.java.net  Mon Jan 31 09:41:08 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 31 Jan 2022 09:41:08 GMT
Subject: Withdrawn: 8216358: [accessibility] [macos] The focus is invisible
 when tab to "Image Radio Buttons" and "Image CheckBoxes"
In-Reply-To: <8vfRuS7p6OmZ8yzFOZz8vKQ4woiO9VKdE2XGTgL-piQ=.3a04cd23-8665-4076-a0ef-30aa66cf8c46@github.com>
References: <8vfRuS7p6OmZ8yzFOZz8vKQ4woiO9VKdE2XGTgL-piQ=.3a04cd23-8665-4076-a0ef-30aa66cf8c46@github.com>
Message-ID: <0JklkqOhiY_NL6VlOBizUrYp8KUYKLZaGvQNIv1gx-E=.85d532c4-8950-4014-85e4-25b7f264d978@github.com>

On Mon, 31 Jan 2022 09:11:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Focus painting for combo box and radio button with custom icon should honour the corresponding property.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7284


From kizune at openjdk.java.net  Mon Jan 31 09:51:36 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 31 Jan 2022 09:51:36 GMT
Subject: RFR: 8279586: [macos] custom JCheckBox and JRadioBox with custom
 icon set: focus is still displayed after unchecking
In-Reply-To: <k9xWTLyJCod60pqiqa4R_wm0unlED3zbdjCxqSkbFow=.83bb20a6-cbbc-4301-beda-2578ea70b0a8@github.com>
References: <k9xWTLyJCod60pqiqa4R_wm0unlED3zbdjCxqSkbFow=.83bb20a6-cbbc-4301-beda-2578ea70b0a8@github.com>
Message-ID: <IqfBixiiLoXPF0rWEbe2F9MK1q7V-vGKR-vbukUSHoU=.8df9a64b-573d-4e56-bc1e-f5096137c550@github.com>

On Mon, 31 Jan 2022 09:44:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make border painting for the check boxes and radio buttons with custom icons
> take into account the property that enables or disables the focus painting.
> Add that case to the test.

Focus painting for combo box and radio button with custom icon should honor the corresponding property.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7286


From kizune at openjdk.java.net  Mon Jan 31 09:51:35 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 31 Jan 2022 09:51:35 GMT
Subject: RFR: 8279586: [macos] custom JCheckBox and JRadioBox with custom icon
 set: focus is still displayed after unchecking
Message-ID: <k9xWTLyJCod60pqiqa4R_wm0unlED3zbdjCxqSkbFow=.83bb20a6-cbbc-4301-beda-2578ea70b0a8@github.com>

Make border painting for the check boxes and radio buttons with custom icons
take into account the property that enables or disables the focus painting.
Add that case to the test.

-------------

Commit messages:
 - 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking

Changes: https://git.openjdk.java.net/jdk/pull/7286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7286&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279586
  Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7286/head:pull/7286

PR: https://git.openjdk.java.net/jdk/pull/7286


From dbatrak at openjdk.java.net  Mon Jan 31 13:47:14 2022
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 31 Jan 2022 13:47:14 GMT
Subject: Integrated: 8278908: [macOS] Unexpected text normalization on pasting
 from clipboard
In-Reply-To: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
References: <Ke95TR__3vJ8Z8PI5PIpeOZDLNtahoWWgZrhR4HeVlg=.25c9d5a5-5d8a-43ea-b1ef-3f4899318689@github.com>
Message-ID: <Dd2vaWuLT-xqJddrN1wMTiwKxoHJNpwN26DDZLg7LwQ=.05e6cd22-ce7f-48e8-9bcc-bb51252709b2@github.com>

On Thu, 16 Dec 2021 15:53:26 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The fix just removes the explicit normalization of text obtained from system clipboard in JDK code, as I've found no
> good justification for such a normalization, at least for the latest macOS version.
> The same fix was performed in JetBrains Runtime by a user's request more than 4 years ago, and we didn't receive any
> related complaints from our users ever since.

This pull request has now been integrated.

Changeset: 091aff92
Author:    Dmitry Batrak <dbatrak at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/091aff92e2213bfe0de79b3561a7613ab77e24b6
Stats:     11 lines in 2 files changed: 0 ins; 9 del; 2 mod

8278908: [macOS] Unexpected text normalization on pasting from clipboard

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/6866


From vdyakov at openjdk.java.net  Mon Jan 31 16:41:13 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Mon, 31 Jan 2022 16:41:13 GMT
Subject: RFR: 8279586: [macos] custom JCheckBox and JRadioBox with custom
 icon set: focus is still displayed after unchecking
In-Reply-To: <k9xWTLyJCod60pqiqa4R_wm0unlED3zbdjCxqSkbFow=.83bb20a6-cbbc-4301-beda-2578ea70b0a8@github.com>
References: <k9xWTLyJCod60pqiqa4R_wm0unlED3zbdjCxqSkbFow=.83bb20a6-cbbc-4301-beda-2578ea70b0a8@github.com>
Message-ID: <5-gMg7XtEmX-7QiTq2LpQYrNG4Afdcepb0XfNQKRISQ=.eb9f9e18-c826-403c-a522-51d6c19a5b82@github.com>

On Mon, 31 Jan 2022 09:44:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Make border painting for the check boxes and radio buttons with custom icons
> take into account the property that enables or disables the focus painting.
> Add that case to the test.

@azvegint @aivanov-jdk please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/7286


From duke at openjdk.java.net  Mon Jan 31 17:28:11 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 17:28:11 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v3]
In-Reply-To: <_k4TH60mmpl6bPtTLEqzWcI0Ejk-OpuxCHfW_OE8dxA=.8f88460c-d79b-417a-b20b-12ee78ec6427@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
 <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>
 <EZwRH6aPwYmMTd_cNaVz--j_GpPrePi6EeD1rc41xaM=.d12ee2d7-eb25-4e32-b566-88536ceb99ff@github.com>
 <_k4TH60mmpl6bPtTLEqzWcI0Ejk-OpuxCHfW_OE8dxA=.8f88460c-d79b-417a-b20b-12ee78ec6427@github.com>
Message-ID: <P14dXy1iYh8loxHlJk9h8a6hqKRjR3pci82TRXwh1xA=.45e3f7c1-fc97-44d8-b71d-7025aa78efe0@github.com>

On Mon, 31 Jan 2022 07:24:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk I have changed the test case to explicitly set the table and header background to white. Mach5 tests are passing on all platforms including linux now. Can you please let me know in case you are seeing any issues on Ubuntu locally, with the new test case?
>
> I now see it fail locally in windows system also along with ubuntu. windows screenshot here where the border is white which is why it fails
> ![JTheaderBorder](https://user-images.githubusercontent.com/43534309/151753660-92d6021a-30d6-4215-97b0-7ab17ddb88d4.png)

@prsadhuk Thank you for checking the test case again. As you pointed out earlier, should we mark it as mac-only test case to prevent test case issues arising from platform specific System LAF ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7219


From duke at openjdk.java.net  Mon Jan 31 19:44:51 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 19:44:51 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v4]
In-Reply-To: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
Message-ID: <lvkYpdA6Tn-ThIaO9J85UYszIt3gc2blSuUu_UXrGmw=.7ff1e49d-9190-4a9f-a98e-843e2d1dd415@github.com>

> A new test case was added to test the fix as there was no corresponding test case present for this issue previously.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  tagged test case as mac only

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7219/files
  - new: https://git.openjdk.java.net/jdk/pull/7219/files/90a5a7aa..516985d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7219&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7219.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7219/head:pull/7219

PR: https://git.openjdk.java.net/jdk/pull/7219


From duke at openjdk.java.net  Mon Jan 31 19:44:52 2022
From: duke at openjdk.java.net (Harshitha Onkar)
Date: Mon, 31 Jan 2022 19:44:52 GMT
Subject: RFR: JDK-8016524: [macosx] Bottom line is not visible for
 JTableHeader [v4]
In-Reply-To: <_k4TH60mmpl6bPtTLEqzWcI0Ejk-OpuxCHfW_OE8dxA=.8f88460c-d79b-417a-b20b-12ee78ec6427@github.com>
References: <MG8XY-gjoigOezDsQEZGM4RviYIOmNvvneJDkfjk944=.3156cc63-ad37-41f2-9d25-6d496cdb2ba0@github.com>
 <5wjVB_FL_GYsLbqr_FEpBsFX3twlM9cXbrN8a3r2rDY=.e42f518a-dc26-49cb-9949-32426cf85fa8@github.com>
 <RaURhyT8urcWB-oQMOpnH1OtbE_YAw3xKX5HOdDjxxw=.688d842a-b9bb-4258-991b-7a19bf428266@github.com>
 <EZwRH6aPwYmMTd_cNaVz--j_GpPrePi6EeD1rc41xaM=.d12ee2d7-eb25-4e32-b566-88536ceb99ff@github.com>
 <_k4TH60mmpl6bPtTLEqzWcI0Ejk-OpuxCHfW_OE8dxA=.8f88460c-d79b-417a-b20b-12ee78ec6427@github.com>
Message-ID: <DY9X8eFl1SseemeItxin6-b6FmgWopLPE4lCi9WkSmk=.622ced54-120b-42e7-88b5-f6e7f6b3338e@github.com>

On Mon, 31 Jan 2022 07:24:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @prsadhuk I have changed the test case to explicitly set the table and header background to white. Mach5 tests are passing on all platforms including linux now. Can you please let me know in case you are seeing any issues on Ubuntu locally, with the new test case?
>
> I now see it fail locally in windows system also along with ubuntu. windows screenshot here where the border is white which is why it fails
> ![JTheaderBorder](https://user-images.githubusercontent.com/43534309/151753660-92d6021a-30d6-4215-97b0-7ab17ddb88d4.png)

@prsadhuk I have tagged this particular test case as mac-only to prevent test case issues arising from platform specific System LAF.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7219