From duke at openjdk.org  Fri Jul  1 00:07:05 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 1 Jul 2022 00:07:05 GMT
Subject: RFR: 8289559 : java/awt/a11y/AccessibleJPopupMenuTest.java test fails
 with java.lang.NullPointerException
Message-ID: <T8v6uKdETvAFpSal_DGp_wY-J4B4Z4Eapv1DZDb_l1g=.afa91286-550e-4bb3-ab0f-354944745445@github.com>

Fixed the java.lang.NullPointerException & tested .

@shurymury

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

Commit messages:
 - 8289559 : java/awt/a11y/AccessibleJPopupMenuTest.java test fails with java.lang.NullPointerException

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

PR: https://git.openjdk.org/jdk/pull/9342


From vdyakov at openjdk.org  Fri Jul  1 01:31:40 2022
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Fri, 1 Jul 2022 01:31:40 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
Message-ID: <Ns4D70-3o6wdncHtcGSk-jhcGN58ro9eIGSecDfYhXw=.a87cfc9f-a560-430d-8966-492045872c17@github.com>

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
>> 
>> **Analysis :** 
>> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
>> 1) End points (vertices) required for the primitive drawing are put in a buffer.
>> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
>> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
>> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
>> 
>> **Root Cause of slower performance :**
>> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
>> 
>> **Fix :** 
>> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
>> The primitive drawing logic is modified to collate adjacent draw calls as below -
>> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
>> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
>> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
>> 
>> 
>> **More insight :** 
>> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
>> The performance test that we have measure rendering performance of extreme cases such as -
>> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
>> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
>> 
>> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
>> 
>> **Results :**
>> The performance results are attached to the JBS.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make method inline + clean commented line

need a review from @prrace

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

PR: https://git.openjdk.org/jdk/pull/9245


From duke at openjdk.org  Fri Jul  1 04:14:29 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Jul 2022 04:14:29 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <Cavx_IJY1dlge-9RYKF6cHu2IqOmIlWZRDCVmMASc4A=.c67143b3-16b2-4492-ab3e-565cb1554978@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
 <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
 <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>
 <d34UG8qsp57TeJ01CjyIhHWNIIrc5LzhoUmqM0YA8yM=.5d005b8c-84d8-458c-8c77-1fd00c81da90@github.com>
 <SRNYZVpzfz7pEJ-MddvPYrWkiqnD1QyH05L
 xMeSt7Fw=.eae19d9c-fe80-4a26-afe5-01ccde0c9945@github.com>
 <Cavx_IJY1dlge-9RYKF6cHu2IqOmIlWZRDCVmMASc4A=.c67143b3-16b2-4492-ab3e-565cb1554978@github.com>
Message-ID: <wf3hQPCy-Wj66tt64zIk2AQGCX81hCdEwcppS7AE3Rs=.481fc600-3c91-4d35-90b0-ce8ac713cbf8@github.com>

On Thu, 30 Jun 2022 17:39:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think we should follow the current format for the time being and show the file size similar to how its shown in native tools.
>> 
>> In Windows Explorer, 0 bytes are shown as 0 KB, 1 byte is 1 KB and so on? However, JFileChooser shows these as 0 bytes and 1 bytes in both Java/Metal and Windows L&Fs.
>> 
>> On macOS, Finder shows the size as "Zero bytes" and "1 byte" correspondingly. JFileChooser in Aqua L&F doesn't show the size.
>
>> It is introduced in JDK12. If this has to be backported to 8, that's not an option.
> 
> Is this fix going to be backported to 11 and 8?

> The code should employ `MessageFormat`. You only need to modify the English resource bundles, i.e., `basic.properties`, the rest will be taken care of by the g11n process.

Ok, will update in basic.properties and check.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul  1 04:31:24 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Jul 2022 04:31:24 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <GeAwin-VSzBZaFyvS7hOBMjEJvnXmjYu7Kqiz1mxwGU=.2ebefa3f-cce7-48a0-aced-a72bcb9a5f47@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <GeAwin-VSzBZaFyvS7hOBMjEJvnXmjYu7Kqiz1mxwGU=.2ebefa3f-cce7-48a0-aced-a72bcb9a5f47@github.com>
Message-ID: <oWK_q0yDzP2xKMWVrQ4WW35sw1xafxoVLWBHYcqsKcI=.71dd14d2-51d3-4705-8d9c-1962017c8d3d@github.com>

On Thu, 30 Jun 2022 16:56:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> The copyright year is usually just the current year for new files. 
> Was the test case created from a reproducer code?

@

> The copyright year is usually just the current year for new files. Was the test case created from a reproducer code?

I have taken sample test case from the repo for reference and write mine test case, will update the copyright year.

> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 74:
> 
>> 72:             PassFailJFrame.positionTestFrame(frame,
>> 73:                     PassFailJFrame.Position.HORIZONTAL);
>> 74:         });
> 
> @kumarabhi006 You will have to update `addTestFrame & positonTestFrame` to `addTestWindow & positionTestWindow` due to recent PassFailJFrame changes. Probably pull in the latest code.
> PassFailJFrame changes: https://github.com/openjdk/jdk/pull/9300

@honkar-jdk @aivanov-jdk I will update the PassFailFrame changes.

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

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Fri Jul  1 09:11:58 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 1 Jul 2022 09:11:58 GMT
Subject: Integrated: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest
In-Reply-To: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
References: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
Message-ID: <u0tf6tzaY-IyCW4dyUzSc0eg-av80U5CmwgKWHT9RaQ=.2cc4b303-86b8-4737-b63d-25d077392499@github.com>

On Fri, 24 Jun 2022 22:12:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.
> 
> PassFailJFrame is being used as the test framework. 
> 
> **Proposed change related to PassFailJFrame Test framework**
> 
> Instead of creating separate methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame.positionTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L271) and [**PassFailJFrame.addTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294) can be changed to take in Window as input parameter instead of Frame, since Window is a superclass, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame, additionally would allow proper disposal of windows added to the PassFailJFrame.
> 
> **Above PassFailJFrame changes tracked by: [JDK-8289238](https://bugs.openjdk.org/browse/JDK-8289238)**

This pull request has now been integrated.

Changeset: f190f4e6
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f190f4e6389a0105b0701ec7ea201fab9dda0a48
Stats:     359 lines in 1 file changed: 359 ins; 0 del; 0 mod

8288444: Remove the workaround for frame.pack() in ModalDialogTest

Reviewed-by: azvegint

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

PR: https://git.openjdk.org/jdk/pull/9286


From mvs at openjdk.org  Fri Jul  1 12:55:44 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 1 Jul 2022 12:55:44 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <kHwF4wpRdudfrO9m88NGH94PTvB-Nygh0M26N51DJ3Y=.e485a5ef-c36f-48a5-aad6-783e78cec378@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
 <kHwF4wpRdudfrO9m88NGH94PTvB-Nygh0M26N51DJ3Y=.e485a5ef-c36f-48a5-aad6-783e78cec378@github.com>
Message-ID: <jlmUI16Y6643ZXEH2nMQNE4fZJR9suvaOaNbtNiQlsg=.c19fa917-0e16-46b9-9d15-703eef315c81@github.com>

On Wed, 29 Jun 2022 07:26:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I don't see this test failing in our CI systems "frequently"...last time it failed is June8 on a CI system which had some history of config issue, and that too on jdk17 binary and not on mainline..before that it fails on June1 due to some infra issue on mainline..and before that on June19 2021 on jdk11 binary again due to infra issue..so I dont think it's worth tinkering as of now..
> 
> also, the test has some quirks as I see. press() method is never called...it uses internal SwingTest class to start the test which I am not sure is needed

I have seen it failing around 35 times last month alone and not all failures were system issues(failures link attached as a confidential comment in bug), but yes, this was mostly failing on JDK18, JDK17 or JDK11 and I think this fails only for MacOS 12 machines. But anyway I felt it better to fix the test if some instability is there.

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

PR: https://git.openjdk.org/jdk/pull/9202


From serb at openjdk.org  Sat Jul  2 00:27:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 2 Jul 2022 00:27:45 GMT
Subject: [jdk19] Integrated: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
Message-ID: <_wEG4XZEovRyIKWl_VKSq1d8uRNH-EaCIP7TEMQ49U8=.66bc5a90-0686-4814-9a3b-5ff40d4cc17b@github.com>

On Mon, 27 Jun 2022 21:17:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the fix for a copy-paste error. The fix JDK-8076313 replaced the usage of the "screens" array from the parent class to the "devices" where the list of devices is now maintained. Since "screens" array is never used nor initialized its usage caused an NPE. That check was copied as-is, while it should use the actual number of screen devices requested early in that method.
> 
> The bug is rarely reproduced because in single screen configuration the main screen is usually 0, and in the multiscreen configuration Xinerama is usually active so the main screen is also 0 => the second part of the "if" statement is not executed.
> 
> I have validated the fix by the SwingSet, I also executed desktop tests in that config and found that even though this particular bug is fixed we still have many issues there, around ~100 tests failed.

This pull request has now been integrated.

Changeset: cfc9a881
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/cfc9a881afd300bd7c1ce784287d1669308e89fc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE

Reviewed-by: azvegint, aivanov

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

PR: https://git.openjdk.org/jdk19/pull/81


From smandalika at openjdk.org  Sat Jul  2 03:55:40 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 2 Jul 2022 03:55:40 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v4]
In-Reply-To: <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
Message-ID: <7CAcuKFx70RXpbPDctnYj67A6m1lAHe8DQ64sIZ-yuI=.0dca602a-3c8a-4b23-b5d4-70e7febb5254@github.com>

On Wed, 22 Jun 2022 12:52:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: removed redundant headful tag

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8158


From smandalika at openjdk.org  Sat Jul  2 03:55:43 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 2 Jul 2022 03:55:43 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v4]
In-Reply-To: <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
Message-ID: <KEomRzysZKOWSSV28luRIPpAxB1gQCGau_W4ThmDS50=.c43bbd8d-21f2-4978-b685-fb2beddd42c1@github.com>

On Wed, 22 Jun 2022 11:42:06 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8284767
>  - Review comment fixed: removed redundant headful tag
>  - Review Comments Fixed: Fixed File location path.
>  - Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
>  - 8284767: Create an automated test for JDK-4422535
>  - 8284767: Create an automated test for JDK-4422535

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8220


From smandalika at openjdk.org  Sat Jul  2 03:55:47 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 2 Jul 2022 03:55:47 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <ScipVxEGUbWpOHf8ZaRhoE7JRwfDKP5GUz7ILSY0c1U=.8e57db46-a88a-4ba1-be17-a8677e819e66@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8546


From jwilhelm at openjdk.org  Sat Jul  2 11:15:24 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 11:15:24 GMT
Subject: RFR: Merge jdk19
Message-ID: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8245268: -Xcomp is missing from java launcher documentation
 - 8288703: GetThreadState returns 0 for virtual thread that has terminated
 - 8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE
 - 8280320: C2: Loop opts are missing during OSR compilation
 - 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec
 - 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
 - 8289549: ISO 4217 Amendment 172 Update
 - 8284358: Unreachable loop is not removed from C2 IR, leading to a broken graph

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

Changes: https://git.openjdk.org/jdk/pull/9354/files
  Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/9354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354

PR: https://git.openjdk.org/jdk/pull/9354


From jwilhelm at openjdk.org  Sat Jul  2 18:13:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 18:13:28 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
Message-ID: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289603: Code change for JDK-8170762 breaks all build
   
   Reviewed-by: weijun
 - 8170762: Document that ISO10126Padding pads with random bytes
   
   Reviewed-by: weijun
 - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB
   
   Reviewed-by: alanb
 - 8289257: Some custom loader tests failed due to symbol refcount not decremented
   
   Reviewed-by: iklam, coleenp
 - 8289534: Change 'uncomplicated' hotspot runtime options
   
   Reviewed-by: coleenp, dholmes
 - 8289512: Fix GCC 12 warnings for adlc output_c.cpp
   
   Reviewed-by: kvn, lucy
 - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP
   
   Reviewed-by: kvn, thartmann, chagedorn, dlong
 - 8288444: Remove the workaround for frame.pack() in ModalDialogTest
   
   Reviewed-by: azvegint
 - 8289434: x86_64: Improve comment on gen_continuation_enter()
   
   Reviewed-by: kvn
 - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114

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

Changes: https://git.openjdk.org/jdk/pull/9354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=01
  Stats: 79992 lines in 1361 files changed: 50048 ins; 16523 del; 13421 mod
  Patch: https://git.openjdk.org/jdk/pull/9354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354

PR: https://git.openjdk.org/jdk/pull/9354


From jwilhelm at openjdk.org  Sat Jul  2 18:13:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 18:13:29 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
Message-ID: <vrcZn96qTXcrRhMsDhp5_kNYsPzJ4ScyoXMZNnptas4=.834e4eb5-6928-4279-9fc0-c726a9cf341d@github.com>

On Sat, 2 Jul 2022 11:03:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 70f56933
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f5693356277c0685668219a79819707d099d9f
Stats:     382 lines in 14 files changed: 330 ins; 5 del; 47 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/9354


From duke at openjdk.org  Sat Jul  2 18:42:04 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 2 Jul 2022 18:42:04 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
 <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>
Message-ID: <ERJ4_whPVB1lNQ1Y2QLJ2-5L-NMqiIFb9qdPhtekG5Y=.16799869-bd5c-4196-adf4-eff520095f9a@github.com>

On Sat, 2 Jul 2022 18:13:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Forwardport JDK 19 -> JDK 20
>
> Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:
> 
>  - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
>  - 8289603: Code change for JDK-8170762 breaks all build
>    
>    Reviewed-by: weijun
>  - 8170762: Document that ISO10126Padding pads with random bytes
>    
>    Reviewed-by: weijun
>  - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB
>    
>    Reviewed-by: alanb
>  - 8289257: Some custom loader tests failed due to symbol refcount not decremented
>    
>    Reviewed-by: iklam, coleenp
>  - 8289534: Change 'uncomplicated' hotspot runtime options
>    
>    Reviewed-by: coleenp, dholmes
>  - 8289512: Fix GCC 12 warnings for adlc output_c.cpp
>    
>    Reviewed-by: kvn, lucy
>  - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP
>    
>    Reviewed-by: kvn, thartmann, chagedorn, dlong
>  - 8288444: Remove the workaround for frame.pack() in ModalDialogTest
>    
>    Reviewed-by: azvegint
>  - 8289434: x86_64: Improve comment on gen_continuation_enter()
>    
>    Reviewed-by: kvn
>  - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/9354


From duke at openjdk.org  Sun Jul  3 05:19:49 2022
From: duke at openjdk.org (kristylee88)
Date: Sun, 3 Jul 2022 05:19:49 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <bRkbM8rHeNUXta2x_cOrnb7lcSL96edxWKtfGxMjT44=.5c1d5e6f-3b7a-41c7-b4b3-c7fb7778183c@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/9016


From psadhukhan at openjdk.org  Sun Jul  3 08:39:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Jul 2022 08:39:38 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v4]
In-Reply-To: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
Message-ID: <NmsL5-qU4bCaUTzREiGd-7nbjQpBtcjDiXrA9ZpfpOM=.7a81fb63-3955-4254-b543-c1683fe1a44c@github.com>

> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
> `p.y 154 cpos.y 155`
> 
> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
> 
> so test is updated to add 1 pixel to popup location. 
> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments addressed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9321/files
  - new: https://git.openjdk.org/jdk/pull/9321/files/2ad78ef0..6d0e56f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9321


From psadhukhan at openjdk.org  Sun Jul  3 08:39:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Jul 2022 08:39:40 GMT
Subject: Integrated: 8065097: [macosx]
 javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel
 off
In-Reply-To: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
Message-ID: <vHO9qLSI1FeaUxq73xlHrE20x3I4F1s-3hsyg7Tkgt8=.9e01c60c-4f93-4a9d-8502-eaea03693f26@github.com>

On Wed, 29 Jun 2022 08:28:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
> `p.y 154 cpos.y 155`
> 
> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
> 
> so test is updated to add 1 pixel to popup location. 
> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

This pull request has now been integrated.

Changeset: 649f2d88
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/649f2d8835027128c6c8cf37236808094a12a35f
Stats:     131 lines in 2 files changed: 37 ins; 4 del; 90 mod

8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel off

Reviewed-by: aivanov

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

PR: https://git.openjdk.org/jdk/pull/9321


From attila at openjdk.org  Sun Jul  3 20:03:45 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 3 Jul 2022 20:03:45 GMT
Subject: RFR: 8287603: Avoid redundant HashMap.containsKey calls in
 NimbusDefaults.getDerivedColor
In-Reply-To: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
References: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
Message-ID: <H0xruaAMB_jBXRYAOiuGy9fVO8D7FbUJuwA9_tdrLp0=.220a8cf6-1de2-4d8a-9cd3-9b5b416aee90@github.com>

On Sat, 30 Apr 2022 09:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `javax.swing.plaf.nimbus.NimbusDefaults#getDerivedColor(String,String,float,float,float,int,boolean)` could be improved by usage of Map.putIfAbsent instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `javax.swing.plaf.nimbus.NimbusDefaults#derivedColors` can contain only non-null values. And to check if `putIfAbsent` was successful or not, we can just compare result with `null`.
> https://github.com/openjdk/jdk/blob/97bd4c255a319ce626a316ed211ef1fd7d0f1e14/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L713-L720
> It makes code a bit cleaner and faster.

Marked as reviewed by attila (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8482


From mkartashev at openjdk.org  Mon Jul  4 09:39:24 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 4 Jul 2022 09:39:24 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java occasionally
 crashes on MacOS
Message-ID: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>

Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.

This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 

Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.

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

Commit messages:
 - 8289208: Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Changes: https://git.openjdk.org/jdk/pull/9362/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9362&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289208
  Stats: 185 lines in 3 files changed: 165 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9362.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9362/head:pull/9362

PR: https://git.openjdk.org/jdk/pull/9362


From aivanov at openjdk.org  Mon Jul  4 10:37:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Jul 2022 10:37:41 GMT
Subject: RFR: 8287603: Avoid redundant HashMap.containsKey calls in
 NimbusDefaults.getDerivedColor
In-Reply-To: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
References: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
Message-ID: <V5O-uRhlwKYY4TdO1ntSiezlEjM-z-0TZ0ML2GceoWI=.d1e8ddb8-fed8-40bf-b210-3f3088783f0b@github.com>

On Sat, 30 Apr 2022 09:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `javax.swing.plaf.nimbus.NimbusDefaults#getDerivedColor(String,String,float,float,float,int,boolean)` could be improved by usage of Map.putIfAbsent instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `javax.swing.plaf.nimbus.NimbusDefaults#derivedColors` can contain only non-null values. And to check if `putIfAbsent` was successful or not, we can just compare result with `null`.
> https://github.com/openjdk/jdk/blob/97bd4c255a319ce626a316ed211ef1fd7d0f1e14/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L713-L720
> It makes code a bit cleaner and faster.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8482


From aivanov at openjdk.org  Mon Jul  4 10:47:32 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Jul 2022 10:47:32 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <DN01G0Mgkc4QMkzzruqtprOgA56bG00U9odQ6_QvgiQ=.53b50a3a-d516-48bd-a84d-81de4e6fbfb7@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9016


From psadhukhan at openjdk.org  Mon Jul  4 11:39:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Jul 2022 11:39:43 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <UNFfD5IGa142NcAH-hOXy8U0Cn_O4WVzVpTHLs2LW64=.774e58b4-1a69-4f61-8ee3-91d32bc43f28@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
 <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
 <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>
 <4upBK4eG3UJ8LItxLizG4bZaFc8UFwM3ZGkx4wNCJaw=.cc8e3214-e98c-49ce-8a96-0244347f5c13@github.com>
 <R7yJ5AYM5oIDESlxV5cYb8RUbaFe1kedi595pJxrNlY=.27ba2ed4-a275-4e28-82de-2a0f3ec81187@github.com>
 <UNFfD5IGa142NcAH-hOXy8U0Cn_O4WVzVpTHLs2LW64=.774e58b4-1a69-4f61-8ee3-91d32bc43f28@github.com>
Message-ID: <DwVovp2wnbHlbiQVPqqe_6EUHq88TgMqdbbe-_5x0fU=.ec049181-4359-4e8b-8846-eaa31a4fa10e@github.com>

On Thu, 30 Jun 2022 22:41:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> One macOS you will not see the "Alt" key as well, but we use that name.

At least I can see
![mac-keyboard-alt](https://user-images.githubusercontent.com/43534309/177146818-c4c17e1d-5f61-4c9c-9122-947606fc59c1.png)

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

PR: https://git.openjdk.org/jdk/pull/9230


From duke at openjdk.org  Mon Jul  4 15:17:40 2022
From: duke at openjdk.org (AJ1032480)
Date: Mon, 4 Jul 2022 15:17:40 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <CujonFqSUHG59afv05oPp1JA4UZhfJelTf7Lg2TCEVA=.146e1783-a01d-4368-8921-7075be322d3c@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

pre submit tests failed*

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

PR: https://git.openjdk.org/jdk/pull/9016


From vkempik at openjdk.org  Mon Jul  4 15:47:31 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Mon, 4 Jul 2022 15:47:31 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
Message-ID: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>

Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
The code checks the cache for at least one free element, while placing 6 elements to the cache.
The fix checks the presence of 6 free elements.

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

Commit messages:
 - 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad

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

PR: https://git.openjdk.org/jdk/pull/9368


From avu at openjdk.org  Mon Jul  4 16:59:30 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 4 Jul 2022 16:59:30 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <PyTTCdkTyJypGyX41CoPg0jLn3kDjp2Yu3VGiXDmK6E=.72064f6c-9fcd-40fd-b778-6b0f978a900e@github.com>

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Looks good for me

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

PR: https://git.openjdk.org/jdk/pull/9368


From vkempik at openjdk.org  Mon Jul  4 19:45:42 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Mon, 4 Jul 2022 19:45:42 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <jZysdCOV2OthXlN8eWSM5sTOFiMCYDHk-rX4_YPfNQ0=.6d580068-3879-4786-897f-40539bc7d2ab@github.com>

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Linux test failure unrelated, this commit changes only macos's code

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

PR: https://git.openjdk.org/jdk/pull/9368


From aghaisas at openjdk.org  Tue Jul  5 06:57:22 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 5 Jul 2022 06:57:22 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <_BhezWFSLLhxX_LZjomDDtUPf_udFecAxFpQvug0Jh4=.d42198a6-f75f-4017-a594-d380fecd9e04@github.com>

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

This is a good catch and fix.

There is another place in this file where `MTLVC_ADD_TRIANGLES` is used.
Although it is a corner case, it is worth adding the check for additional 6 vertices at that place as well.
Adding a separate check at the beginning of the `MTLVertexCache_AddMaskQuad` method where there is a check for `maskCacheIndex` seems logical to me. What do you think?

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

PR: https://git.openjdk.org/jdk/pull/9368


From aturbanov at openjdk.org  Tue Jul  5 07:41:44 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 5 Jul 2022 07:41:44 GMT
Subject: Integrated: 8287603: Avoid redundant HashMap.containsKey calls in
 NimbusDefaults.getDerivedColor
In-Reply-To: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
References: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
Message-ID: <feH6ADogzpUYB2ytVOtbmQpB6FmcSUaEHJT7Yhi6lNo=.21c1324b-3a10-42bd-816d-df3616dcf678@github.com>

On Sat, 30 Apr 2022 09:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `javax.swing.plaf.nimbus.NimbusDefaults#getDerivedColor(String,String,float,float,float,int,boolean)` could be improved by usage of Map.putIfAbsent instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `javax.swing.plaf.nimbus.NimbusDefaults#derivedColors` can contain only non-null values. And to check if `putIfAbsent` was successful or not, we can just compare result with `null`.
> https://github.com/openjdk/jdk/blob/97bd4c255a319ce626a316ed211ef1fd7d0f1e14/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L713-L720
> It makes code a bit cleaner and faster.

This pull request has now been integrated.

Changeset: fd1bb078
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd1bb078ea3c8d3a10be696384ecf04d16573baa
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8287603: Avoid redundant HashMap.containsKey calls in NimbusDefaults.getDerivedColor

Reviewed-by: attila, aivanov

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

PR: https://git.openjdk.org/jdk/pull/8482


From aturbanov at openjdk.org  Tue Jul  5 07:41:43 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 5 Jul 2022 07:41:43 GMT
Subject: RFR: 8287603: Avoid redundant HashMap.containsKey calls in
 NimbusDefaults.getDerivedColor
In-Reply-To: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
References: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com>
Message-ID: <gMSMdtD9DnYWK0rAkiKTqGDtBbc9dHg5F3MAl2KYoaM=.62708b3c-fc3e-4d80-993b-9ff90deda100@github.com>

On Sat, 30 Apr 2022 09:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `javax.swing.plaf.nimbus.NimbusDefaults#getDerivedColor(String,String,float,float,float,int,boolean)` could be improved by usage of Map.putIfAbsent instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `javax.swing.plaf.nimbus.NimbusDefaults#derivedColors` can contain only non-null values. And to check if `putIfAbsent` was successful or not, we can just compare result with `null`.
> https://github.com/openjdk/jdk/blob/97bd4c255a319ce626a316ed211ef1fd7d0f1e14/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L713-L720
> It makes code a bit cleaner and faster.

Thank you for review!

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

PR: https://git.openjdk.org/jdk/pull/8482


From vkempik at openjdk.org  Tue Jul  5 11:31:38 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 5 Jul 2022 11:31:38 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v2]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <66c9ONSyg2Ij5BDzYNq31FL239UPkNPY8zIJ-fDnvIk=.d9d8e1fb-5040-426c-bcc8-9ce1d1606528@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  Add the check to one more place

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/35ed932e..88402dbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9368


From vkempik at openjdk.org  Tue Jul  5 11:31:39 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 5 Jul 2022 11:31:39 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <qs5SS_Gka6dMXQCq-1DQqUF9_OibHY3p9LKil6dHKHw=.ab97181a-89ed-4590-98b3-b8ee21c30fea@github.com>

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Added one more check into MTLVertexCache_AddMaskQuad,  to the first if condition.

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

PR: https://git.openjdk.org/jdk/pull/9368


From prr at openjdk.org  Tue Jul  5 19:05:29 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Jul 2022 19:05:29 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v2]
In-Reply-To: <66c9ONSyg2Ij5BDzYNq31FL239UPkNPY8zIJ-fDnvIk=.d9d8e1fb-5040-426c-bcc8-9ce1d1606528@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <66c9ONSyg2Ij5BDzYNq31FL239UPkNPY8zIJ-fDnvIk=.d9d8e1fb-5040-426c-bcc8-9ce1d1606528@github.com>
Message-ID: <3YnOzitxr-EhH5ntWK-jQYp8OthyOa9kKidCq3uhqQs=.e2c199f8-3741-4fc3-94b6-3b9f7d7c133b@github.com>

On Tue, 5 Jul 2022 11:31:38 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
>> The code checks the cache for at least one free element, while placing 6 elements to the cache.
>> The fix checks the presence of 6 free elements.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the check to one more place

Are there any other cases like this ? We should look around. (PS I see Ajit asked the same question and perhaps even answered it !)
Did you find this by inspection or did you hit it ?
Can we use a defined constant instead of "6" ?

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

PR: https://git.openjdk.org/jdk/pull/9368


From vkempik at openjdk.org  Tue Jul  5 20:52:52 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 5 Jul 2022 20:52:52 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v2]
In-Reply-To: <3YnOzitxr-EhH5ntWK-jQYp8OthyOa9kKidCq3uhqQs=.e2c199f8-3741-4fc3-94b6-3b9f7d7c133b@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <66c9ONSyg2Ij5BDzYNq31FL239UPkNPY8zIJ-fDnvIk=.d9d8e1fb-5040-426c-bcc8-9ce1d1606528@github.com>
 <3YnOzitxr-EhH5ntWK-jQYp8OthyOa9kKidCq3uhqQs=.e2c199f8-3741-4fc3-94b6-3b9f7d7c133b@github.com>
Message-ID: <fQtlDroI2YbOGswmFzctLaSRZFc9Y3S0KOxIwaR65_Q=.9a346de7-167b-41ab-aed7-4b233ee5360b@github.com>

On Tue, 5 Jul 2022 19:01:41 GMT, Phil Race <prr at openjdk.org> wrote:

> Are there any other cases like this ? We should look around. (PS I see Ajit asked the same question and perhaps even answered it !) Did you find this by inspection or did you hit it ? 

I hit this bug when running IDEA on asan-enabled build of ojdk

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6210011b94a8 at pc 0x0001707b9c0e bp 0x70001358e8f0 sp 0x70001358e8e8
WRITE of size 4 at 0x6210011b94a8 thread T56
    #0 0x1707b9c0d in MTLVertexCache_AddGlyphQuad+0x5ed (libawt_lwawt.dylib:x86_64+0x1cbc0d)
....
0x6210011b94a8 is located 8 bytes to the right of 4000-byte region [0x6210011b8500,0x6210011b94a0)
allocated by thread T56 here:
    #0 0x106857400 in wrap_malloc+0xa0 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x44400)
    #1 0x1707b8277 in MTLVertexCache_InitVertexCache+0x17 (libawt_lwawt.dylib:x86_64+0x1ca277)
>Can we use a defined constant instead of "6" ?

#define TRI_IN_VERT 6 ?

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

PR: https://git.openjdk.org/jdk/pull/9368


From aivanov at openjdk.org  Tue Jul  5 21:03:52 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Jul 2022 21:03:52 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <X0jN-Xr4IdBpHoOS515GE5CoMyk41e0N5LgBEPTm0QY=.51a0cbd3-0bb0-44eb-b4a1-e6474c8bde80@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <5TQwHRdWYkstuTYOtDyzJsbFLIAl0WNppp6COIVUSKI=.8869e869-fbe6-46ae-bb55-e6c0aa6b5db9@github.com>
 <X0jN-Xr4IdBpHoOS515GE5CoMyk41e0N5LgBEPTm0QY=.51a0cbd3-0bb0-44eb-b4a1-e6474c8bde80@github.com>
Message-ID: <1FH3Nea0E6YuOKb3KRZSIPBLW8EcgBYhR6uo4dIl95g=.cdcc7f9f-1cc1-47fd-854c-ff0be8b35f67@github.com>

On Thu, 9 Jun 2022 10:37:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I am not going trough all the experiments with the SHDefExtractIcon again - at least not in this pull request.
> 
> I absolutely agree, not in this pull request.
> 
> However, I'm for submitting a bug or two to explore other possibilities.

I submitted a list of issues to record all the comments that were raised here as well as in previous reviews.

1. [JDK-8289705](https://bugs.openjdk.org/browse/JDK-8289705): Handle the case where IExtractIconW::Extract returns S_FALSE
2. [JDK-8289707](https://bugs.openjdk.org/browse/JDK-8289707): Use LookupIconIdFromDirectoryEx to extract only available sizes of icon
3. [JDK-8289708](https://bugs.openjdk.org/browse/JDK-8289708): Extract only the requested icon size
4. [JDK-8289756](https://bugs.openjdk.org/browse/JDK-8289756): Do not always request 16x16 icon
5. [JDK-8289766](https://bugs.openjdk.org/browse/JDK-8289766): Unify the two methods for extracting icons on Windows
6. [JDK-8289767](https://bugs.openjdk.org/browse/JDK-8289767): Handle the case where IExtractIconW::GetIconLocation returns E_PENDING

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

PR: https://git.openjdk.org/jdk/pull/7805


From vkempik at openjdk.org  Tue Jul  5 21:26:21 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Tue, 5 Jul 2022 21:26:21 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v3]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <b9VofJyQzCECqnFeJk2b5I-PdvY8POnAurrKQUjISlc=.ab820a38-17d9-41f1-a8f3-0ce277be3a30@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  Replace constant with define

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/88402dbe..23438f27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9368.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9368/head:pull/9368

PR: https://git.openjdk.org/jdk/pull/9368


From duke at openjdk.org  Wed Jul  6 12:23:50 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 12:23:50 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <hI-a13CAwmIbDoWdUEdl3HaSGxKzYnoNSi_FqdEUIOs=.c5e9e416-f892-4b04-b9ec-cf4a48cf440e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <hI-a13CAwmIbDoWdUEdl3HaSGxKzYnoNSi_FqdEUIOs=.c5e9e416-f892-4b04-b9ec-cf4a48cf440e@github.com>
Message-ID: <SOaIObYfPT16NIcJJIOjzaNi_qKoN2RHeKNgr1GKEQY=.96fafbc2-aa08-488b-9028-1973c6efcdbe@github.com>

On Thu, 30 Jun 2022 16:31:21 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 74:
> 
>> 72:             PassFailJFrame.positionTestFrame(frame,
>> 73:                     PassFailJFrame.Position.HORIZONTAL);
>> 74:         });
> 
> @kumarabhi006 You will have to update `addTestFrame & positonTestFrame` to `addTestWindow & positionTestWindow` due to recent PassFailJFrame changes. Probably pull in the latest code.
> PassFailJFrame changes: https://github.com/openjdk/jdk/pull/9300

@honkar-jdk @aivanov-jdk updated the addTestFrame and positonTestFrame to addTestWindow & positionTestWindow.

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

PR: https://git.openjdk.org/jdk/pull/9327


From mvs at openjdk.org  Wed Jul  6 07:50:42 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 6 Jul 2022 07:50:42 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <h7BCFERIV6x0fzGCwWIVLpFKt9LbVH_M1KyA7_PiSBA=.7b01e9c0-3dc6-4caf-a287-df394d4ed6ed@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Any volunteers?

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

PR: https://git.openjdk.org/jdk/pull/9202


From duke at openjdk.org  Wed Jul  6 12:33:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 12:33:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
Message-ID: <htLoUpNgp4xipSPwANe9TUHoOzD5W_A2QI4jEqCteLo=.932109d2-c967-4a68-b70c-a796c693111f@github.com>

On Wed, 6 Jul 2022 11:59:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Byte entry added to basic.properties, MessageFormat used to format file length

JFileChooser in Windows and Ubuntu is setting the filesize from two different files.
In ubuntu, the method "public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column)" in FilePane.java is formatting the length and return it back.
In Windows, it uses ShellFolder to set FileSize column values and it is returned in terms of bytes in stead of KB (as shown by native tools).
To handle filesize in windows, I will like to raise separate PR.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul  6 15:27:41 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Wed, 6 Jul 2022 15:27:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
Message-ID: <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>

On Wed, 6 Jul 2022 11:59:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Byte entry added to basic.properties, MessageFormat used to format file length

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties line 80:

> 78: 
> 79: # File Size Units
> 80: FileChooser.fileSizeBytes={0} bytes

should it be "{0} B" to be consistent with the rest of the formatting strings?

src/java.desktop/share/classes/sun/swing/FilePane.java line 532:

> 530:                         UIManager.getString("FileChooser.detailsViewActionLabelText", l);
> 531: 
> 532:         byteString      = UIManager.getString("FileChooser.fileSizeBytes", l);

is the '-' character misaligned or is this a github rendering artifact?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul  6 12:23:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 12:23:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
Message-ID: <4_XrxVZYnCuNW_BYOqzBzGaaXKDtXj2OWxsNjZic9Qg=.6e96c124-7ab6-458e-a12c-9c5ca9f36677@github.com>

On Thu, 30 Jun 2022 04:05:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Also, will this code work correctly for non-English locales?
>> 
>> It won't.
>> 
>> It has to use `MessageFormat` and it has to add a new string to the resource bundle.
>
> Dont think this len==0 check is needed...
> One can use text = len + "bytes";
> 
> Also, this has i18n connection to it, so you need to use "byteString" similar to "kiloByteString", point it to 
> UIManager.getString("FileChooser.fileSizeBytes", l); and add "FileChooser.fileSizeBytes" entry into 
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
> 
> I am not sure if need i18n team's intervention to update those resources as "bytes" can be translated to native in jp, zh
> Maybe @naotoj can throw some light on that how to go about updating those resource file

@prsadhuk @naotoj @aivanov-jdk @andy-goryachev-oracle Messageformat has been used to format the string to work correctly for non-english locale also. 
Modified the basic.properties file to handle byte values.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul  6 10:42:46 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 10:42:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v2]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <TVwqM6B1m_TweSSSa0Pojz90fZTFkK_JXp5HNFoFOcE=.07bcfbcd-8d4e-45da-9528-90ba49ee3eea@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar 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' of https://git.openjdk.java.net/jdk into JDK-8288882
 - JFileChooser empty file size 0 bytes fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/c9583130..a7b31d98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=00-01

  Stats: 64636 lines in 1251 files changed: 39136 ins; 12514 del; 12986 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul  6 06:18:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Jul 2022 06:18:03 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines produces
 StackOverflowError
Message-ID: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>

BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
Fixed by catching StackOverflow and ignoring so that application is not stuck.

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

Commit messages:
 - Fix
 - 8224267: JOptionPane message string with 5000+ newlines produces StackOverflowError
 - 8224267: JOptionPane message string with 5000+ newlines produces StackOverflowError
 - 8224267: JOptionPane message string with 5000+ newlines produces StackOverflowError

Changes: https://git.openjdk.org/jdk/pull/9388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224267
  Stats: 86 lines in 2 files changed: 65 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9388.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9388/head:pull/9388

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Wed Jul  6 12:23:48 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 12:23:48 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <dV1Ccxduu206-uCqBxaFOaNwIphVu1aHpy_pEItZwkE=.7bc9709d-f14e-4046-b2f7-c2e848836545@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <dV1Ccxduu206-uCqBxaFOaNwIphVu1aHpy_pEItZwkE=.7bc9709d-f14e-4046-b2f7-c2e848836545@github.com>
Message-ID: <d8UWW69vHxfeHW7o3U9t1-OvT9ZdTcqXRkgbgfv2KP0=.15d3ec83-efff-4773-8256-69d1ee97fd3e@github.com>

On Wed, 29 Jun 2022 19:11:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 56:
> 
>> 54:             JFileChooser fc = new JFileChooser();
>> 55:             try {
>> 56:                 Path currentDir = Paths.get(System.getProperty("java.io.tmpdir"));
> 
> Why not create it in the `test.src` value? This property is defined by jtreg. If the property is not set, default to `.`, that is the current directory.

Creating the empty file in "test.src" now.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul  6 12:23:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Jul 2022 12:23:46 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <6CeLtschZ9i-okYJcNnIWSspUK7KKP2RG2LFhGbwz44=.108ffed8-9933-47fb-bf67-1fcac859bc3f@github.com>

On Wed, 6 Jul 2022 05:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

PR

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

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Wed Jul  6 11:59:31 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Jul 2022 11:59:31 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Byte entry added to basic.properties, MessageFormat used to format file length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/a7b31d98..b1006c66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=01-02

  Stats: 43 lines in 3 files changed: 10 ins; 13 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From kizune at openjdk.org  Wed Jul  6 18:17:41 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 6 Jul 2022 18:17:41 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v7]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Modified test case so it creates the new file instead of having it in
  the test folder. Verified on automatic run.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7805/files
  - new: https://git.openjdk.org/jdk/pull/7805/files/3d177fea..52333fbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7805&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7805&range=05-06

  Stats: 19 lines in 2 files changed: 10 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/7805.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7805/head:pull/7805

PR: https://git.openjdk.org/jdk/pull/7805


From aghaisas at openjdk.org  Wed Jul  6 16:40:29 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 6 Jul 2022 16:40:29 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v3]
In-Reply-To: <b9VofJyQzCECqnFeJk2b5I-PdvY8POnAurrKQUjISlc=.ab820a38-17d9-41f1-a8f3-0ce277be3a30@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <b9VofJyQzCECqnFeJk2b5I-PdvY8POnAurrKQUjISlc=.ab820a38-17d9-41f1-a8f3-0ce277be3a30@github.com>
Message-ID: <ftF6BwHQRj2KCgQC7mYNyn8OH2JxhwAJ51IqAtFl3ts=.00267f0c-28b1-4a9c-b257-a8368170577b@github.com>

On Tue, 5 Jul 2022 21:26:21 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
>> The code checks the cache for at least one free element, while placing 6 elements to the cache.
>> The fix checks the presence of 6 free elements.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace constant with define

I will submit a full test run with this patch and then approve on it's successful completion.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 69:

> 67: 
> 68: //Next define should exactly match to the amount of MTLVC_ADD_VERTEX in MTLVC_ADD_TRIANGLES
> 69: #define MTL_TRIS_IN_VERTEX 6

Constants starting with `MTL_` should be avoided as they are used in Metal Framework library.
I think, this should be `VERTS_FOR_A_QUAD`.

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

PR: https://git.openjdk.org/jdk/pull/9368


From naoto at openjdk.org  Wed Jul  6 16:21:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Jul 2022 16:21:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
Message-ID: <XWT1a1GE4HHKcu_W99RUfeoU0zy8Z1NLALXUe3y0lE8=.8ceae637-c65a-472f-a1f7-f85df881e318@github.com>

On Wed, 6 Jul 2022 11:59:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Byte entry added to basic.properties, MessageFormat used to format file length

src/java.desktop/share/classes/sun/swing/FilePane.java line 1194:

> 1192:                 setIcon(icon);
> 1193: 
> 1194:             } else if (value instanceof Long) {

You could change this to `value instanceof Long len` so that the cast below can be eliminated.

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 78:

> 76:         passFailJFrame.awaitAndCheck();
> 77:     }
> 78: }

Needs a newline.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul  7 04:47:30 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Jul 2022 04:47:30 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
Message-ID: <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>

On Wed, 6 Jul 2022 15:23:57 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties line 80:
> 
>> 78: 
>> 79: # File Size Units
>> 80: FileChooser.fileSizeBytes={0} bytes
> 
> should it be "{0} B" to be consistent with the rest of the formatting strings?

It is similar to the file size shown in native tools i.e. "bytes" in ubuntu platform.

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

PR: https://git.openjdk.org/jdk/pull/9327


From vkempik at openjdk.org  Wed Jul  6 20:31:31 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Wed, 6 Jul 2022 20:31:31 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v4]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  Change define name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/23438f27..0af4ec81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9368


From tr at openjdk.org  Thu Jul  7 06:31:28 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 7 Jul 2022 06:31:28 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <WNHVj_8kW02LM_D7uotvNiDmK5RlUB2B2H3qYlGIIrA=.6d53f44d-4aec-4829-ace5-b96c1ded3a5d@github.com>

On Wed, 6 Jul 2022 05:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/9388


From mickleness at gmail.com  Thu Jul  7 00:34:37 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Thu, 07 Jul 2022 00:34:37 +0000
Subject: Getting notified on a window being grabbed and moved / resized
In-Reply-To: <CAMRG33ZWw1vikdJPjUfkPrXVMsY1TWW9JWsvemux=8LQLZ0HqA@mail.gmail.com>
References: <CAMRG33ZWw1vikdJPjUfkPrXVMsY1TWW9JWsvemux=8LQLZ0HqA@mail.gmail.com>
Message-ID: <em9881ae6a-7242-42b8-a6f8-91e56421089d@a210f72e.com>

Kirill,

 > Is there a public / supported way to get notified when an OS-decorated 
window (native title pane from macOS, Windows, etc) is moved around or 
resized by the user grabbing the title bar or the border?

Not that I?m aware of.

 > I want to get notified on that process starting so that I can hide all 
the popups.

Are you OK with just knowing when your JVM?s windows are grabbed?

Attached is a small test app I threw together that I think (?) 
demonstrates what you?re describing. Even if we hide windows when we 
first detect movement, we don?t know exactly when to re-show them? so 
this just uses a timer to wait until movement stops. (We could add 
another layer of pseudoscience to it and look at the mouse location and 
guess if it?s in the title bar? Which is one of those things that will 
probably be right 95+% of the time.)

When testing on my Mac: I don?t observe any delay between moving the 
mouse a pixel and all other windows instantly hiding. What do you 
observe, and what?s your testing environment like?

>From your description my initial assessment would be:
A. What you?re trying to do is not well supported in Java.
B. It may be worth implementing your own window decorations (for Mac, 
Windows, etc.) instead. This would give you complete control over the 
?grabbing? process. It might mean you miss out on some default OS 
behavior, though. (Like nudges the OS might make to auto-align windows, 
or to wrap windows onto other monitors, or to help manage virtual 
monitors.) But if these are small helper popup windows that stay close 
to their parent frame (are they?) that might all be worth it. Plus: if 
they are officially ?undecorated? as far as the AWT is considered: you 
can fade them in/out (instead of toggling them on/off).

Regards,
  - Jeremy

------ Original Message ------
>From "Kirill Grouchnikov" <kirill.grouchnikov at gmail.com>
To client-libs-dev at openjdk.org
Date 6/28/2022 11:19:02 AM
Subject Getting notified on a window being grabbed and moved / resized

>Is there a public / supported way to get notified when an OS-decorated 
>window (native title pane from macOS, Windows, etc) is moved around or 
>resized by the user grabbing the title bar or the border?
>
>I want to get notified on that process starting so that I can hide all 
>the popups. What I see is that at [1] this is how Swing's popup menu 
>registers itself to get notified on window grabbing. Note that it's 
>using internal, undocumented and inaccessible event mask. Then at [2] 
>it gets notified that the window has been ungrabbed so that it can hide 
>itself. Again, internal and inaccessible event class. And there's also 
>APIs at [3] to grab / ungrab windows to have the whole process rolling.
>
>Are there alternatives to these internal APIs that have been exposed as 
>part of hiding the implementation details?
>
>The only thing I could find so far is adding a component listener to 
>the frame, but "componentMoved" is called with a noticeable lag, 
>hundreds of milliseconds after the window has started moving.
>
>[1] 
>https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java#L790
>[2] 
>https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java#L861
>[3] 
>https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/SunToolkit.java#L1641
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220707/86f61577/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GrabbingTests.java.zip
Type: application/zip
Size: 1162 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220707/86f61577/GrabbingTests.java.zip>

From duke at openjdk.org  Thu Jul  7 06:48:37 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Jul 2022 06:48:37 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
Message-ID: <NaF0D21OyqBwtQQ_sk9pTnxdI8ikQbgyjt3kME0JU-E=.05ee0b14-ef81-42bf-a044-d19068077368@github.com>

On Wed, 6 Jul 2022 15:22:05 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 532:
> 
>> 530:                         UIManager.getString("FileChooser.detailsViewActionLabelText", l);
>> 531: 
>> 532:         byteString      = UIManager.getString("FileChooser.fileSizeBytes", l);
> 
> is the '-' character misaligned or is this a github rendering artifact?

I didn't get you. Can you please specify the line number ?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul  7 10:32:17 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 7 Jul 2022 10:32:17 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is constructed
 from entirely used byte[]
Message-ID: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>

We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.

Benchmark results:

before

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op

after

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

Commit messages:
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Changes: https://git.openjdk.org/jdk/pull/9407/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289908
  Stats: 90 lines in 5 files changed: 77 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Thu Jul  7 07:10:29 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Jul 2022 07:10:29 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <XWT1a1GE4HHKcu_W99RUfeoU0zy8Z1NLALXUe3y0lE8=.8ceae637-c65a-472f-a1f7-f85df881e318@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <XWT1a1GE4HHKcu_W99RUfeoU0zy8Z1NLALXUe3y0lE8=.8ceae637-c65a-472f-a1f7-f85df881e318@github.com>
Message-ID: <wbnUy2ElQnTqv5l5LsdoIC-MJQ-H1-o7UQlkytHQiaY=.87097ab6-d19f-47b7-afce-2c2b277e168a@github.com>

On Wed, 6 Jul 2022 16:15:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1194:
> 
>> 1192:                 setIcon(icon);
>> 1193: 
>> 1194:             } else if (value instanceof Long) {
> 
> You could change this to `value instanceof Long len` so that the cast below can be eliminated.

After replacing "value instanceof Long" by "value instanceof Long len" and removing the cast below (long len = value) results in build error. So, I guess cast is required to convert an object to long type.

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

PR: https://git.openjdk.org/jdk/pull/9327


From mvs at openjdk.org  Wed Jul  6 07:48:44 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 6 Jul 2022 07:48:44 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
Message-ID: <Vn2tvC_0MROUj_RzBe-vOY4-aWO9ORGxUqDqWEnNSIQ=.1ae3b573-e348-4f1a-a82c-e61fd5f5f925@github.com>

On Wed, 29 Jun 2022 06:53:29 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Reverted variable name change, reverted +20 in point

Any volunteers?

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

PR: https://git.openjdk.org/jdk/pull/9187


From kizune at openjdk.org  Wed Jul  6 18:17:44 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 6 Jul 2022 18:17:44 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
Message-ID: <lYVe80RYCr_uoklwBcTbzjzfroRAKUIyRNWxTyc4rSQ=.a50c3264-edb5-4653-adfd-c6c7e14674b0@github.com>

On Mon, 6 Jun 2022 23:47:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the line ends

I have updated the test so test file is created and deleted during the testing so name is irrelevant as long as the extension is not registered and we get the default Windows icon.

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

PR: https://git.openjdk.org/jdk/pull/7805


From psadhukhan at openjdk.org  Thu Jul  7 11:55:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Jul 2022 11:55:43 GMT
Subject: Integrated: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
Message-ID: <yuabAejzPmZIU_IRKdw8Wqz2XfY4_hFvrt3i88B9wqE=.15726ee5-aa32-4896-94e7-2d99193c079e@github.com>

On Mon, 27 Jun 2022 07:01:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In macos, popups does not overlap taskbar unlike windows, as can be seen here  in "Settings"
> so we can omit this test from macOS run.
> 
> ![image](https://user-images.githubusercontent.com/43534309/175878607-6435da8c-ae32-4512-9cbc-0b449637e93f.png)

This pull request has now been integrated.

Changeset: 532a6ec7
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/532a6ec7e3a048624b380b38b4611533a7caae18
Stats:     15 lines in 2 files changed: 10 ins; 2 del; 3 mod

7124313: [macosx] Swing Popups should overlap taskbar

Reviewed-by: serb, dmarkov

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

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Thu Jul  7 12:13:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Jul 2022 12:13:09 GMT
Subject: RFR: 8170794: [macosx] Error when using setDesktopManager on a
 JDesktopPane on MacOS X with Look and Feel Aqua
Message-ID: <x67mXpqQ0LoZTxf3DRzpreINeiNnLfncqB2oqFMhOXA=.331c02f9-4e82-4e3f-9a25-38bdde2920d1@github.com>

When we call JDesktopPane.setDesktopManager(new DefaultDesktopManager()) and try to iconify an internalframe, it results in NPE

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1030)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1489)
at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
at javax.swing.JComponent.paint(JComponent.java:1042)
at javax.swing.JComponent.paintChildren(JComponent.java:889)
at javax.swing.JComponent.paint(JComponent.java:1065)
at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.updateIcon(AquaInternalFrameDockIconUI.java:193)
at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.paint(AquaInternalFrameDockIconUI.java:204)
at javax.swing.JComponent.paintChildren(JComponent.java:889)
at javax.swing.JComponent.paint(JComponent.java:1065)
at javax.swing.JComponent.paintChildren(JComponent.java:889)
at javax.swing.JComponent.paint(JComponent.java:1065)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:586) 


it seems the getVolatileOffscreenBuffer() is called with JRootPane component for AquaLookAndFeel because of which 
SwingUtilities.getWindowAncestor(JRootPane) returns null causing NPE.

Fixed by adding a null check. The JInternalFrame can be successfully iconized now after setting DesktopManager.

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

Commit messages:
 - Fix
 - Fix
 - 8170794: [macosx] Error when using setDesktopManager on a JDesktopPane on MacOS X with Look and Feel Aqua

Changes: https://git.openjdk.org/jdk/pull/9408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9408&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8170794
  Stats: 106 lines in 2 files changed: 105 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9408.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9408/head:pull/9408

PR: https://git.openjdk.org/jdk/pull/9408


From aghaisas at openjdk.org  Thu Jul  7 14:14:40 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 7 Jul 2022 14:14:40 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v4]
In-Reply-To: <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>
Message-ID: <dwLxX-nDOO1wwF75MlI-zIJ68UoUaM9RixBJBH-6Ndk=.08e37c89-edca-49ed-9047-f9b223a95958@github.com>

On Wed, 6 Jul 2022 20:31:31 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
>> The code checks the cache for at least one free element, while placing 6 elements to the cache.
>> The fix checks the presence of 6 free elements.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change define name

The full test run is good with this change.
2 comments in the code still use `MTL_TRIS_IN_VERTEX`. These need to be corrected.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 225:

> 223:                 maskCacheIndex);
> 224: 
> 225:     // MTLVC_ADD_TRIANGLES at the end of this function will place MTL_TRIS_IN_VERTEX vertexes to the vertex cache

Replace `MTL_TRIS_IN_VERTEX` from this comment.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m line 313:

> 311:     J2dTraceLn(J2D_TRACE_INFO, "MTLVertexCache_AddGlyphQuad");
> 312: 
> 313:     // MTLVC_ADD_TRIANGLES adds MTL_TRIS_IN_VERTEX vertexes into Cache, so need to check space for MTL_TRIS_IN_VERTEX elements

Replace `MTL_TRIS_IN_VERTEX` from this comment.

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

PR: https://git.openjdk.org/jdk/pull/9368


From duke at openjdk.org  Thu Jul  7 14:48:29 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 7 Jul 2022 14:48:29 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <NaF0D21OyqBwtQQ_sk9pTnxdI8ikQbgyjt3kME0JU-E=.05ee0b14-ef81-42bf-a044-d19068077368@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <NaF0D21OyqBwtQQ_sk9pTnxdI8ikQbgyjt3kME0JU-E=.05ee0b14-ef81-42bf-a044-d19068077368@github.com>
Message-ID: <S_wlv6MSVrFpVt84Vr41vLkXjZdbeMkcVJf5bD5B5I0=.e9c34ff0-e2a7-484f-8e83-e9d43b2081fc@github.com>

On Thu, 7 Jul 2022 06:44:47 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 532:
>> 
>>> 530:                         UIManager.getString("FileChooser.detailsViewActionLabelText", l);
>>> 531: 
>>> 532:         byteString      = UIManager.getString("FileChooser.fileSizeBytes", l);
>> 
>> is the '-' character misaligned or is this a github rendering artifact?
>
> I didn't get you. Can you please specify the line number ?

it's minor.

'=' symbols are misaligned between the lines 532 and 533:
        byteString      = UIManager.getString("FileChooser.fileSizeBytes", l);
        kiloByteString = UIManager.getString("FileChooser.fileSizeKiloBytes", l);

I'd suggest either align, or (better) remove any alignment by using only one space.

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jul  7 20:07:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Jul 2022 20:07:28 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <S_wlv6MSVrFpVt84Vr41vLkXjZdbeMkcVJf5bD5B5I0=.e9c34ff0-e2a7-484f-8e83-e9d43b2081fc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <NaF0D21OyqBwtQQ_sk9pTnxdI8ikQbgyjt3kME0JU-E=.05ee0b14-ef81-42bf-a044-d19068077368@github.com>
 <S_wlv6MSVrFpVt84Vr41vLkXjZdbeMkcVJf5bD5B5I0=.e9c34ff0-e2a7-484f-8e83-e9d43b2081fc@github.com>
Message-ID: <khAmNg3LtmYs4gSQ_2J9AJNRV2vvhmV2sF4zigKVcqI=.fedb6a99-2599-4433-b301-7a4ee584fda6@github.com>

On Thu, 7 Jul 2022 14:42:51 GMT, Andy Goryachev <duke at openjdk.org> wrote:

> (better) remove any alignment by using only one space.

I'm for using just one space as you would in a regular assignment.

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

PR: https://git.openjdk.org/jdk/pull/9327


From naoto at openjdk.org  Thu Jul  7 16:14:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Jul 2022 16:14:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <wbnUy2ElQnTqv5l5LsdoIC-MJQ-H1-o7UQlkytHQiaY=.87097ab6-d19f-47b7-afce-2c2b277e168a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <XWT1a1GE4HHKcu_W99RUfeoU0zy8Z1NLALXUe3y0lE8=.8ceae637-c65a-472f-a1f7-f85df881e318@github.com>
 <wbnUy2ElQnTqv5l5LsdoIC-MJQ-H1-o7UQlkytHQiaY=.87097ab6-d19f-47b7-afce-2c2b277e168a@github.com>
Message-ID: <25lXIkc_goxmMq23aSAWJUR0xy8vPMnT5_MOKIL-MvU=.a052af49-7bb8-492b-b031-992b0f9f28b8@github.com>

On Thu, 7 Jul 2022 07:06:57 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1194:
>> 
>>> 1192:                 setIcon(icon);
>>> 1193: 
>>> 1194:             } else if (value instanceof Long) {
>> 
>> You could change this to `value instanceof Long len` so that the cast below can be eliminated.
>
> After replacing "value instanceof Long" by "value instanceof Long len" and removing the cast below (long len = value) results in build error. So, I guess cast is required to convert an object to long type.

You don't need to use `value` in this `if` statement any longer. Just use `len` inside (that's the whole purpose).

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jul  7 20:07:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Jul 2022 20:07:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
Message-ID: <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>

On Wed, 6 Jul 2022 11:59:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Byte entry added to basic.properties, MessageFormat used to format file length

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1198:

> 1196:                 if (listViewWindowsStyle) {
> 1197:                     len /= 1024L;
> 1198:                     text = MessageFormat.format(kiloByteString, len + 1);

Does it make sense to address this too?
If len is zero before division, leave it as is so that the size would display "0 KB"; if len is greater than 0, then divide and add 1. At least this is how Windows Explorer displays file sizes.

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 53:

> 51:         JFileChooser fc = new JFileChooser();
> 52:         try {
> 53:             Path currentDir = Paths.get(System.getProperty("test.src"));

`currentDir` is confusing. Would `dir` be enough?

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 60:

> 58:             }
> 59:             fc.setCurrentDirectory(currentDir.toFile());
> 60:         }catch (IOException ex) {

Suggestion:

        } catch (IOException ex) {

A space is missing.

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 66:

> 64:     }
> 65: 
> 66:     public static void main(String args[]) throws Exception {

Since the test is applicable to Metal Look-and-Feel, shall the test explicitly set MetalLAF?

Does the issue seen in other Look-and-Feels? Windows L&F isn't affected, Aqua isn't either. Any other?

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 72:

> 70:             frame = new JFrame();
> 71:             PassFailJFrame.addTestWindow(frame);
> 72:             PassFailJFrame.positionTestWindow(frame, PassFailJFrame.Position.HORIZONTAL);

You don't use the frame any more, do you?

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

PR: https://git.openjdk.org/jdk/pull/9327


From vkempik at openjdk.org  Thu Jul  7 15:24:31 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Thu, 7 Jul 2022 15:24:31 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v4]
In-Reply-To: <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>
Message-ID: <i0dgXx3zhGRj7qeQo4gH_OUEhWpUlSYBsTDTZR5ph7A=.ef48ec06-6be7-4441-ad20-b89cdf42a90e@github.com>

On Wed, 6 Jul 2022 20:31:31 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
>> The code checks the cache for at least one free element, while placing 6 elements to the cache.
>> The fix checks the presence of 6 free elements.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change define name

Yeah, missed that, thanks for noticing

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

PR: https://git.openjdk.org/jdk/pull/9368


From rriggs at openjdk.org  Thu Jul  7 18:48:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Jul 2022 18:48:40 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>

On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

src/java.base/share/classes/java/lang/String.java line 1429:

> 1427:      */
> 1428:     public String(byte[] bytes, int offset, int length) {
> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));

Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.

this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());

or call `Preconditions.checkFromIndexSize` directly.

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

PR: https://git.openjdk.org/jdk/pull/9407


From aivanov at openjdk.org  Thu Jul  7 20:13:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Jul 2022 20:13:40 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <htLoUpNgp4xipSPwANe9TUHoOzD5W_A2QI4jEqCteLo=.932109d2-c967-4a68-b70c-a796c693111f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <htLoUpNgp4xipSPwANe9TUHoOzD5W_A2QI4jEqCteLo=.932109d2-c967-4a68-b70c-a796c693111f@github.com>
Message-ID: <kguS3k7Pye8T14Ngx9F3HN5H5euGWnnLFfgkWgB1c7c=.7026ffd3-900e-4f69-adc6-3189c02a9fb1@github.com>

On Wed, 6 Jul 2022 12:30:07 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> In Windows, it uses ShellFolder to set FileSize column values and it is returned in terms of bytes in stead of KB (as shown by native tools).

This doesn't seem to be true for Windows, I see "0 KB" and "1 KB" for zero-byte and one-byte sized files correspondingly in Windows Explorer.

> To handle filesize in windows, I will like to raise separate PR.

Are you saying you will submit a new bug to address the above?

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

PR: https://git.openjdk.org/jdk/pull/9327


From aghaisas at openjdk.org  Thu Jul  7 16:03:45 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 7 Jul 2022 16:03:45 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v4]
In-Reply-To: <i0dgXx3zhGRj7qeQo4gH_OUEhWpUlSYBsTDTZR5ph7A=.ef48ec06-6be7-4441-ad20-b89cdf42a90e@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <NsKN5l7wcYq4-nwJFoJNea6EPe8CMvFyUGekvb7U1cU=.f1eb7b21-e0f1-475a-805e-6cb2052f4951@github.com>
 <i0dgXx3zhGRj7qeQo4gH_OUEhWpUlSYBsTDTZR5ph7A=.ef48ec06-6be7-4441-ad20-b89cdf42a90e@github.com>
Message-ID: <tPdoCB2gWRgSPCL8cvUkVj9D5MS36CF3GjiwhEt9H-I=.b0a08424-8394-4a40-81d0-6899849be99e@github.com>

On Thu, 7 Jul 2022 15:20:04 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Yeah, missed that, thanks for noticing

There is one instance of `MTL_TRIS_IN_VERTEX` still remaining in a comment!

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

PR: https://git.openjdk.org/jdk/pull/9368


From aivanov at openjdk.org  Thu Jul  7 20:07:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Jul 2022 20:07:28 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
Message-ID: <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>

On Thu, 7 Jul 2022 04:43:44 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties line 80:
>> 
>>> 78: 
>>> 79: # File Size Units
>>> 80: FileChooser.fileSizeBytes={0} bytes
>> 
>> should it be "{0} B" to be consistent with the rest of the formatting strings?
>
> It is similar to the file size shown in native tools i.e. "bytes" in ubuntu platform.

Shall we handle "1 byte"?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul  7 20:13:41 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 7 Jul 2022 20:13:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
 <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
Message-ID: <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>

On Thu, 7 Jul 2022 19:41:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is similar to the file size shown in native tools i.e. "bytes" in ubuntu platform.
>
> Shall we handle "1 byte"?

good point!  that's why I suggested "{0} B"
plural rules can be quite complex, see
http://www.unicode.org/cldr/cldr-aux/charts/22/supplemental/language_plural_rules.html

example: in Arabic, there are 6 forms:


Language Name | Code | Category | Examples | Rules
-- | -- | -- | -- | --
Arabic | ar | zero | 0 | zero ? n is 0;one ? n is 1;two ? n is 2;few ? n mod 100 in 3..10;many ? n mod 100 in 11..99;other ??everything else
one | 1
two | 2
few | 3-10, 103-110, 203-210...
many | 11-99, 111-199, 211-299...
other | 100-102, 200-202, 300-302...;0.2, 1.07, 2.94, 3.81, 11.68, 100.55...

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

PR: https://git.openjdk.org/jdk/pull/9327


From vkempik at openjdk.org  Thu Jul  7 15:24:30 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Thu, 7 Jul 2022 15:24:30 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v5]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <rk71IoBNBJYCO-nJVx-DLiA7oxyKLCyVp9YSuOLlPfA=.dbe2cd4c-cbbe-4f3b-b1be-727ba0f874f1@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  Rename comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/0af4ec81..662a6bef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9368


From prr at openjdk.org  Fri Jul  8 00:42:40 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Jul 2022 00:42:40 GMT
Subject: RFR: 8289853: Update HarfBuzz to 4.4.1
Message-ID: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>

This upgrades the JDK's version of harfbuzz to 4.4.1. The current version is 2.8.0
Builds on all platforms. Testing looks good.
I've added an UPDATING.txt file with tips on the steps involved in these upgrades.

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

Commit messages:
 - 8289853
 - 8289853

Changes: https://git.openjdk.org/jdk/pull/9420/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289853
  Stats: 58001 lines in 275 files changed: 32096 ins; 18824 del; 7081 mod
  Patch: https://git.openjdk.org/jdk/pull/9420.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9420/head:pull/9420

PR: https://git.openjdk.org/jdk/pull/9420


From vkempik at openjdk.org  Thu Jul  7 21:24:29 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Thu, 7 Jul 2022 21:24:29 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v6]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <Zypg3Nu7Nu2tVbKEigWeF6usGRkMkdwWvbXOi_KINCQ=.da88a139-d0c3-41eb-8706-36eea9b08031@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:

  oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/662a6bef..2676028f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/9368


From prr at openjdk.org  Thu Jul  7 22:29:47 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Jul 2022 22:29:47 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v6]
In-Reply-To: <Zypg3Nu7Nu2tVbKEigWeF6usGRkMkdwWvbXOi_KINCQ=.da88a139-d0c3-41eb-8706-36eea9b08031@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
 <Zypg3Nu7Nu2tVbKEigWeF6usGRkMkdwWvbXOi_KINCQ=.da88a139-d0c3-41eb-8706-36eea9b08031@github.com>
Message-ID: <8SG_YFIbFr0iqg4zf7pMXmKVnRvyJfGEw21rYz4zLv0=.8b6f5c4f-c96b-4c45-bad8-9cf9ba34f5bf@github.com>

On Thu, 7 Jul 2022 21:24:29 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
>> The code checks the cache for at least one free element, while placing 6 elements to the cache.
>> The fix checks the presence of 6 free elements.
>
> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oops

LGTM although I'd really (really!) like you to break up those long lines before pushing.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9368


From prr at openjdk.org  Thu Jul  7 21:06:39 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Jul 2022 21:06:39 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
Message-ID: <-VZrwMJC_45puGGx1duuICxJF5_j860gqyEH8FGHdbU=.6a302f3c-ae1c-4f16-8bff-f5ce6bf4786a@github.com>

On Tue, 28 Jun 2022 11:15:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   passed in text added

The bug suggests
returns true if one of this JLabel's icon or disabled icon is derived from
ImageIcon and it's Image is equal to the image passed in; false
otherwise.

But looking at the code .. I don't think that is quite right either
////
  public boolean imageUpdate(Image img, int infoflags,
                               int x, int y, int w, int h) {
        // Don't use getDisabledIcon, will trigger creation of icon if icon
        // not set.
        if (!isShowing() ||
            !SwingUtilities.doesIconReferenceImage(getIcon(), img) &&
            !SwingUtilities.doesIconReferenceImage(disabledIcon, img)) {

            return false;
        }
        return super.imageUpdate(img, infoflags, x, y, w, h);
    }
///

So if they are the same what it actually does isn't return true - it returns whatever super does !
So the original text was in some ways better and its main problem was just referring to Icon
which is the interface that will only have an Image if the implementing class is ImageIcon
There's also the isShowing condition which nothing seems to cover.

So for JLabel we want something like
If the component is not showing, or either the icon or disabled icon is not
an {@code ImageIcon} with an {@code Image} equal to the passed in {@code Image}
this method will return false. Otherwise it will delegate to the super-class.

What do you think ?


AbstractButton may need something similar but I'll leave that to you to check

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

PR: https://git.openjdk.org/jdk/pull/9240


From aivanov at openjdk.org  Thu Jul  7 20:21:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Jul 2022 20:21:22 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
 <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
 <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>
Message-ID: <eNy3Yot-KISKveaUuRp9scA1-zhlapS4i1phfhRLpR0=.13150562-8316-42ef-aaa3-3d7c5ac8fb7f@github.com>

On Thu, 7 Jul 2022 20:08:50 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> Shall we handle "1 byte"?
>
> good point!  that's why I suggested "{0} B"
> plural rules can be quite complex, see
> http://www.unicode.org/cldr/cldr-aux/charts/22/supplemental/language_plural_rules.html
> 
> example: in Arabic, there are 6 forms:
> 
> 
> Language Name | Code | Category | Examples | Rules
> -- | -- | -- | -- | --
> Arabic | ar | zero | 0 | zero ? n is 0;one ? n is 1;two ? n is 2;few ? n mod 100 in 3..10;many ? n mod 100 in 11..99;other ??everything else
> one | 1
> two | 2
> few | 3-10, 103-110, 203-210...
> many | 11-99, 111-199, 211-299...
> other | 100-102, 200-202, 300-302...;0.2, 1.07, 2.94, 3.81, 11.68, 100.55...

Yet JDK isn't localised into Arabic. Some Slavic languages have different plural forms which depend on the last digit in the number (except for 10-19).

It is probably the reason why Windows Explorer shows the size in KB. On the other hand, Properties dialog shows the size as "0 bytes" and "1 bytes".

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Thu Jul  7 20:33:40 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Jul 2022 20:33:40 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
Message-ID: <ANI49sDULzq6UsaGOWODTLZ2D5DfLO2-qk6sDkpqnOs=.2b8a8e9c-5c84-4eff-8f57-fc3e87a80898@github.com>

On Tue, 28 Jun 2022 11:15:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   passed in text added

Please move the CSR back to draft. There are some things that need to change there - and even here - before it is ready

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

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Fri Jul  8 08:06:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 8 Jul 2022 08:06:34 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v6]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <-4R5cRaboh6Avqf4Fd6ZOz4L-nVMB7j_8-ywEGZKzb8=.774e2b26-6b8e-44fd-95a3-e913afcf1bb6@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert ALT_GRAPH support

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/71fa4673..a586dd05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=04-05

  Stats: 46 lines in 5 files changed: 14 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From duke at openjdk.org  Fri Jul  8 07:05:49 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 07:05:49 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <kguS3k7Pye8T14Ngx9F3HN5H5euGWnnLFfgkWgB1c7c=.7026ffd3-900e-4f69-adc6-3189c02a9fb1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <htLoUpNgp4xipSPwANe9TUHoOzD5W_A2QI4jEqCteLo=.932109d2-c967-4a68-b70c-a796c693111f@github.com>
 <kguS3k7Pye8T14Ngx9F3HN5H5euGWnnLFfgkWgB1c7c=.7026ffd3-900e-4f69-adc6-3189c02a9fb1@github.com>
Message-ID: <8eemXeX8Cy8sOfeJFTm_9m9v8f6SnkdbMoZkuOPi7U4=.291cf7e5-ccd6-4a69-bb85-ee1fbc11e1f9@github.com>

On Thu, 7 Jul 2022 20:10:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > In Windows, it uses ShellFolder to set FileSize column values and it is returned in terms of bytes in stead of KB (as shown by native tools).
> 
> This doesn't seem to be true for Windows, I see "0 KB" and "1 KB" for zero-byte and one-byte sized files correspondingly in Windows Explorer.
> 
> > To handle filesize in windows, I will like to raise separate PR.
> 
> Are you saying you will submit a new bug to address the above?

For Windows, I would like to submit a new bug,

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul  8 09:07:35 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 09:07:35 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <-WWiwL_r0CY7fy3lY6GodY7X2UQYk-jycZsS4oCYc7w=.92efe76f-56b6-4860-a3a2-5e1f551417d1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
 <-WWiwL_r0CY7fy3lY6GodY7X2UQYk-jycZsS4oCYc7w=.92efe76f-56b6-4860-a3a2-5e1f551417d1@github.com>
Message-ID: <p7k6Q4Iq-y1yDqlLyNxu-kTnf2Ce4YgppdYxS8988kQ=.3ff24fa1-99af-413e-b972-d96c064e0169@github.com>

On Fri, 8 Jul 2022 06:58:34 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Since the test is applicable to Metal Look-and-Feel, shall the test explicitly set MetalLAF?
> 
> Does the issue seen in other Look-and-Feels? Windows L&F isn't affected, Aqua isn't either. Any other?

After Setting the MetalLAF explicitly, filesize shows correctly. No issue with NimbusLAF as well. 
In GTK and motifLAF , filesize column is not there.

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

PR: https://git.openjdk.org/jdk/pull/9327


From vkempik at openjdk.org  Fri Jul  8 09:17:26 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 09:17:26 GMT
Subject: Integrated: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <9qh1Ql54c7E2Fkh3cXELr9ZdYV5a9enaXLfMpzUv8Z0=.081fa1ce-c081-4b09-b847-e9591a10ea2d@github.com>

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

This pull request has now been integrated.

Changeset: d852e99a
Author:    Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d852e99ae9de4c611438c50ce37ea1806f58cbdf
Stats:     12 lines in 1 file changed: 10 ins; 0 del; 2 mod

8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9368


From psadhukhan at openjdk.org  Fri Jul  8 08:06:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 8 Jul 2022 08:06:38 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
Message-ID: <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>

On Fri, 24 Jun 2022 17:52:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Right Option Key handling
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 95:
> 
>> 93:         "alt altgraph LEFT", DefaultEditorKit.previousWordAction,
>> 94:         "alt altgraph RIGHT", DefaultEditorKit.nextWordAction,
>> 95:         "alt UP", DefaultEditorKit.beginLineUpAction,
> 
> I find it utterly bizarre to say we need "altgraph" when macOS doesn't have altgraph - certainly not on the k/bs on current mac books or imacs.
> 
> My take is that the previous fix JDK-8151136 was a mistake and we should have just excluded the test there on macOS.

As per offline discussion with @prrace ALT_GRAPH support done via JDK-8151136 is reverted and tests testing ALT_GRAPH in macos is excluded..
@prrace can you please review?

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

PR: https://git.openjdk.org/jdk/pull/9230


From duke at openjdk.org  Fri Jul  8 06:23:39 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 06:23:39 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
Message-ID: <qLmRjz_xq0QVdgfUUCJ7FVWEiUxB7wJ7a-TLK_Wi1rE=.f4d5887b-9afd-47a4-858c-47e5bea62ed7@github.com>

On Thu, 7 Jul 2022 19:58:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 72:
> 
>> 70:             frame = new JFrame();
>> 71:             PassFailJFrame.addTestWindow(frame);
>> 72:             PassFailJFrame.positionTestWindow(frame, PassFailJFrame.Position.HORIZONTAL);
> 
> You don't use the frame any more, do you?

No, frame is not used.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul  8 07:00:42 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 07:00:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
Message-ID: <-WWiwL_r0CY7fy3lY6GodY7X2UQYk-jycZsS4oCYc7w=.92efe76f-56b6-4860-a3a2-5e1f551417d1@github.com>

On Thu, 7 Jul 2022 20:03:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since the test is applicable to Metal Look-and-Feel, shall the test explicitly set MetalLAF?
> 
> Does the issue seen in other Look-and-Feels? Windows L&F isn't affected, Aqua isn't either. Any other?

I have not explicitly set the LAF. Need to check with other LAFs.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Fri Jul  8 08:26:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 8 Jul 2022 08:26:43 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v7]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <E0pDWi1iUz3AMepRb2mu7uUP5WHxm0D2QoghiMf-BBA=.f4833691-c376-4e44-967c-be6c0f34a58b@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove altgraph mapping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/a586dd05..3fa91217

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/9230


From asemenov at openjdk.org  Fri Jul  8 10:09:39 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 8 Jul 2022 10:09:39 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
Message-ID: <rLwyDHgkilDLN3nd9RQx_P7NgzOmRx2NDYm9WTKR1Ag=.39f7e09d-a542-4444-85aa-185cff76996c@github.com>

On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We don't do @author tags in openjdk
>   Not 2022 ?

Comment to prevent the pull request from closing.

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

PR: https://git.openjdk.org/jdk/pull/8578


From duke at openjdk.org  Fri Jul  8 07:39:46 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 8 Jul 2022 07:39:46 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
Message-ID: <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>

On Thu, 7 Jul 2022 18:45:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> src/java.base/share/classes/java/lang/String.java line 1429:
> 
>> 1427:      */
>> 1428:     public String(byte[] bytes, int offset, int length) {
>> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));
> 
> Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.
> 
> this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());
> 
> or call `Preconditions.checkFromIndexSize` directly.

But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?

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

PR: https://git.openjdk.org/jdk/pull/9407


From psadhukhan at openjdk.org  Fri Jul  8 13:15:32 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 8 Jul 2022 13:15:32 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <EQ33Jj2t5nXmvHy4pyRFCsHHr-h3quD8FC5GYR6AmS0=.345dd0ec-55d2-4d4f-a5d1-bfd7147ae7f1@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <EQ33Jj2t5nXmvHy4pyRFCsHHr-h3quD8FC5GYR6AmS0=.345dd0ec-55d2-4d4f-a5d1-bfd7147ae7f1@github.com>
Message-ID: <5zeBDi80Ypn6lyrK9jSAvPcrBFZhjf4qozQm5yoILG4=.246d708a-e2e0-4fe0-b9e4-c8f304d1bac3@github.com>

On Fri, 8 Jul 2022 12:13:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Maybe we should rather limit the number of recursive calls? You caught `StackOverflowError`, at this stage there's not much space left on the stack. It may cause another `StackOverflowError`.

I thought that but then thought limiting will not be foolproof as stack size can be modified by -Xss.

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

PR: https://git.openjdk.org/jdk/pull/9388


From rriggs at openjdk.org  Fri Jul  8 14:07:32 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Jul 2022 14:07:32 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
Message-ID: <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>

On Fri, 8 Jul 2022 07:37:36 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 1429:
>> 
>>> 1427:      */
>>> 1428:     public String(byte[] bytes, int offset, int length) {
>>> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));
>> 
>> Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.
>> 
>> this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());
>> 
>> or call `Preconditions.checkFromIndexSize` directly.
>
> But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?

The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.

The constructor should be private, it has a very narrow scope of use given the lack of checking its args.

It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
it would have broader applicability then this point fix.
I would be interesting to ask the compiler folks if that's a future optimization.
These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.

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

PR: https://git.openjdk.org/jdk/pull/9407


From aivanov at openjdk.org  Fri Jul  8 15:05:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 15:05:40 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <9zCJcmOcfXZtR31WIXTeHGbOpkGsNRHe6yE9_m9sJ1k=.3cd48e19-de98-4c54-a934-dfc4ad738bce@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
 <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
 <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>
 <9zCJcmOcfXZtR31WIXTeHGbOpkGsNRHe6yE9_m9sJ1k=.3cd48e19-de98-4c54-a934-dfc4ad738bce@github.com>
Message-ID: <cixG0t-Sn0Trw4NnDTAo65bamSHT-ZO1An28pnU_dW0=.3cfcf288-aeb1-41b9-b9df-081f200492f3@github.com>

On Tue, 21 Jun 2022 03:04:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Before the JDK-8182043 we also used the MRI so it should be changed if the scale was changed from low to hidpi. It adds more variants which could be used by some other DPI, I think one important new variant is the 64x64 because it used as a large icon on HiDPI monitor.

MRI was used only to accommodate for the fact that shell may return icon of higher resolution according the system settings.

https://github.com/openjdk/jdk/blob/978bed6c7ff64148474df3dd1ab3b3707005b8fa/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1032-L1034

If the main monitor scale was set to 200% and 16?16 icon was requested, the system returned 32?32.

In no way it handled different scale settings.

>  But if the dpi is 125% or 150% it will not work even if the user will [try to request](https://github.com/openjdk/jdk/pull/2875#discussion_r641078169) such image.

The current code by @azuev-java handles this situation because the icon returned will contain five variants for the range of 100%, 125%, 150%, 175%, 200%.

I don't clearly understand your concern here.

> Take a look to the description of 8182043, the user wanted to get some large Icon, now imaging he would like to get a 79x79 icon for some file, did we provide a way to do that? I assume we even do not try to request that size from the operation system so it actually cannot ignore our request?

No, we do not request 79?79 because such an icon never exists in Windows because Windows shell does not use such a size to display a file. Well, it may exist if a developer for some reason included it in the app resources but it would rather be an exceptional case.

So if a Java app developer wants 79?79 icon, it will be scaled down from 96?96 or 128?128.

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

PR: https://git.openjdk.org/jdk/pull/7805


From aivanov at openjdk.org  Fri Jul  8 12:38:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 12:38:42 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v7]
In-Reply-To: <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>
Message-ID: <qdiqHZHZ8Ajzaeik7SXHHrTlUU_DINHf4QrLRCP0_XE=.4e78c65f-98b1-4733-8339-de98a440b071@github.com>

On Wed, 6 Jul 2022 18:17:41 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test case so it creates the new file instead of having it in
>   the test folder. Verified on automatic run.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/7805


From aivanov at openjdk.org  Fri Jul  8 14:43:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 14:43:45 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <4z8kuT2i0Mbdz1uANzVNocRjs0NMjrGWGikyaqsmjsw=.f8194e31-d7b9-4f1b-8ea8-204574b59e64@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
 <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
 <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>
 <EMnVzwnT_PlmJzvLJyfonDXzzFGnTBD018biUqIwl0o=.cbdbea2c-c0fd-4c72-a5b8-078cbb506e18@github.com>
 <vd6hL784lg90KIH5z5LqDcljCew_dC0QakU
 ZWP-qoz8=.840cbedc-7898-4dab-ad62-24a4755c0f3c@github.com>
 <4z8kuT2i0Mbdz1uANzVNocRjs0NMjrGWGikyaqsmjsw=.f8194e31-d7b9-4f1b-8ea8-204574b59e64@github.com>
Message-ID: <lVrfjyhtZCUivs4hD_urtLk7JEUIfAzDY7_Va4ojAtQ=.d5147c23-84be-4695-8fe5-672ad66ba48c@github.com>

On Thu, 9 Jun 2022 09:52:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.
>> 
>> Are you sure? That article said the opposite and suggest to use SHDefExtractIcon if the simple extract fails. Probably we should recheck why it does not work for your old testing it seems this should be even faster since it read only one image instead of small+large.
>
>> > Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
>> 
>> No, during initial implementation i tried it and it worked even worse and less stable.
> 
> I can't remember `SHDefExtractIcon` was even tried. According to the documentation for `IExtractIconW::Extract` and to [the article](https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103), another method is to be used when `IExtractIconW::Extract` returns `S_FALSE`.
> 
> Previously, [we discussed](https://github.com/openjdk/jdk/pull/380#issuecomment-702999573) Raymond Chen's post [The format of icon resources](https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083) and [`LookupIconIdFromDirectoryEx`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex) function.
> 
>> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.
> 
> I must admit I still don't like this approach much, we extract 16?16 icon even when we don't need it.
> 
> Is it better to request small icon only when the size is less than 32?
> 
> I think it makes sense to submit a bug to explore using `LookupIconIdFromDirectoryEx` to extract icons so that we have the set of icons which is provided provided in the resources and avoid getting scaled icons. There should be another bug to add fallback to using `SHDefExtractIcon` for the case where `IExtractIconW::Extract` returns `S_FALSE`.
> 
> These are separate issues from the icon rendering, even though icon extraction issues revealed the problem with rendering, scaling up/down the icons to be specific.

> > Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.
> 
> How do we request the proper size for the example above when the scale is 1.25 and the "small" image? The requested size should be 20x20 but we will request 16x16 or 32x32 and then upscale/downscale, no?

We don't request proper size, we always request a list of size. If 16?16 icon is requested, then 20?20 up to 16*2 = 32.

https://github.com/openjdk/jdk/blob/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1150-L1151

Such MRI handles scales from 1.0 to 2.0. Maybe we should increase the list to 3.0, some Windows laptop default to 300%.

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

PR: https://git.openjdk.org/jdk/pull/7805


From aivanov at openjdk.org  Fri Jul  8 12:16:38 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 12:16:38 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <EQ33Jj2t5nXmvHy4pyRFCsHHr-h3quD8FC5GYR6AmS0=.345dd0ec-55d2-4d4f-a5d1-bfd7147ae7f1@github.com>

On Wed, 6 Jul 2022 05:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

Maybe we should rather limit the number of recursive calls? You caught `StackOverflowError`, at this stage there's not much space left on the stack. It may cause another `StackOverflowError`.

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

PR: https://git.openjdk.org/jdk/pull/9388


From aivanov at openjdk.org  Fri Jul  8 14:11:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 14:11:43 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <5zeBDi80Ypn6lyrK9jSAvPcrBFZhjf4qozQm5yoILG4=.246d708a-e2e0-4fe0-b9e4-c8f304d1bac3@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <EQ33Jj2t5nXmvHy4pyRFCsHHr-h3quD8FC5GYR6AmS0=.345dd0ec-55d2-4d4f-a5d1-bfd7147ae7f1@github.com>
 <5zeBDi80Ypn6lyrK9jSAvPcrBFZhjf4qozQm5yoILG4=.246d708a-e2e0-4fe0-b9e4-c8f304d1bac3@github.com>
Message-ID: <ttNf02ZqyRUvypkRd7AmhUzPJSCr-KzeInmQMlagl3A=.da76e134-098a-4ecd-9ef8-b2a13ac6eca7@github.com>

On Fri, 8 Jul 2022 13:12:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Maybe we should rather limit the number of recursive calls? You caught `StackOverflowError`, at this stage there's not much space left on the stack. It may cause another `StackOverflowError`.
> 
> I thought that but then thought limiting will not be foolproof as stack size can be modified by -Xss.

If the limit is low, let's say 20-30 lines, it shouldn't be a problem.

I'm afraid a message with more than 200 lines won't fit on the screen anyway.

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

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Fri Jul  8 06:28:42 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 06:28:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <eNy3Yot-KISKveaUuRp9scA1-zhlapS4i1phfhRLpR0=.13150562-8316-42ef-aaa3-3d7c5ac8fb7f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
 <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
 <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>
 <eNy3Yot-KISKveaUuRp9scA1-zhlapS4i1phfhRLpR0=.13150562-8316-42ef-aaa3-3d7c5ac8fb7f@github.com>
Message-ID: <ljZ1Wm6gU9RTUero-c1_3lcc2rrnhAGu3fumUFlCkXA=.388668ef-8cc1-4a2c-8672-33680e2a1a4e@github.com>

On Thu, 7 Jul 2022 20:17:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> good point!  that's why I suggested "{0} B"
>> plural rules can be quite complex, see
>> http://www.unicode.org/cldr/cldr-aux/charts/22/supplemental/language_plural_rules.html
>> 
>> example: in Arabic, there are 6 forms:
>> 
>> 
>> Language Name | Code | Category | Examples | Rules
>> -- | -- | -- | -- | --
>> Arabic | ar | zero | 0 | zero ? n is 0;one ? n is 1;two ? n is 2;few ? n mod 100 in 3..10;many ? n mod 100 in 11..99;other ??everything else
>> one | 1
>> two | 2
>> few | 3-10, 103-110, 203-210...
>> many | 11-99, 111-199, 211-299...
>> other | 100-102, 200-202, 300-302...;0.2, 1.07, 2.94, 3.81, 11.68, 100.55...
>
> Yet JDK isn't localised into Arabic. Some Slavic languages have different plural forms which depend on the last digit in the number (except for 10-19).
> 
> It is probably the reason why Windows Explorer shows the size in KB. On the other hand, Properties dialog shows the size as "0 bytes" and "1 bytes".

> Shall we handle "1 byte"?

"1 byte" is not handled separately. In that case, should I replace "0 bytes" with "{0} B" ?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul  8 10:34:45 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 8 Jul 2022 10:34:45 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <Dl6xxRKQDGGZnOZeAAh6RTtxAtcXEvxDnI1bxT7xddY=.f01637be-e9e8-4fa9-9807-c8b3e17f6ee1@github.com>
Message-ID: <qQ5KxRRFRSUy2uzWsgebDAhucwSH8rYvPrbhAIG4NVM=.e31b9c62-d794-44cc-b2fc-4866a9f1fc29@github.com>

On Thu, 7 Jul 2022 19:48:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Byte entry added to basic.properties, MessageFormat used to format file length
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1198:
> 
>> 1196:                 if (listViewWindowsStyle) {
>> 1197:                     len /= 1024L;
>> 1198:                     text = MessageFormat.format(kiloByteString, len + 1);
> 
> Does it make sense to address this too?
> If len is zero before division, leave it as is so that the size would display "0 KB"; if len is greater than 0, then divide and add 1. At least this is how Windows Explorer displays file sizes.

I guess in listViewWindowsStyle filesize is not shown. 
But logically it needs to address too as you suggested, otherwise it will give wrong info.

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

PR: https://git.openjdk.org/jdk/pull/9327


From vkempik at openjdk.org  Fri Jul  8 07:45:10 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 07:45:10 GMT
Subject: RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad [v7]
In-Reply-To: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
References: <7ZLs9oGJ2HHPgWQagBjNGqlZjF67h5hRqqbdOHS-sVI=.0a376bd8-e7d2-4d56-a6eb-062416589d32@github.com>
Message-ID: <ELAcQ-l-M14sBYHAsi4V2_rJ4mM6SFTg-wJ_RxnVNaM=.b8752699-eff4-4ef3-9309-e9bc50860f77@github.com>

> Please review this simple patch. When running idea on jdk17 with asan I have found this buffer overflow.
> The code checks the cache for at least one free element, while placing 6 elements to the cache.
> The fix checks the presence of 6 free elements.

Vladimir Kempik has updated the pull request incrementally with two additional commits since the last revision:

 - break up long if
 - break up comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9368/files
  - new: https://git.openjdk.org/jdk/pull/9368/files/2676028f..ecfbd563

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9368&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/9368


From duke at openjdk.org  Fri Jul  8 16:04:25 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Fri, 8 Jul 2022 16:04:25 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <ljZ1Wm6gU9RTUero-c1_3lcc2rrnhAGu3fumUFlCkXA=.388668ef-8cc1-4a2c-8672-33680e2a1a4e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
 <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
 <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>
 <eNy3Yot-KISKveaUuRp9scA1-zhlapS4i1phfhRLpR0=.13150562-8316-42ef-aaa3-3d7c5ac8fb7f@github.com>
 <ljZ1Wm6gU9RTUero-c1_3lcc2rrnhAGu3fumUFlCkXA=.388668ef-8cc1-4a2c-8672-33680e2a1a4e@github.com>
Message-ID: <BHFQZ4Hkpm15o80fTfdnJRZKRp_JgFXtz9ba9haKXb8=.8fd52e4b-a2d6-4f71-8a13-bb7d9b9f3c3b@github.com>

On Fri, 8 Jul 2022 06:24:54 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Yet JDK isn't localised into Arabic. Some Slavic languages have different plural forms which depend on the last digit in the number (except for 10-19).
>> 
>> It is probably the reason why Windows Explorer shows the size in KB. On the other hand, Properties dialog shows the size as "0 bytes" and "1 bytes".
>
>> Shall we handle "1 byte"?
> 
> "1 byte" is not handled separately. In that case, should I replace "0 bytes" with "{0} B" ?

Please refer to MessageFormat javadoc:

`For more sophisticated patterns, you can use a ChoiceFormat to produce correct forms for singular and plural:

 MessageFormat form = new MessageFormat("The disk "{1}" contains {0}.");
 double[] filelimits = {0,1,2};
 String[] filepart = {"no files","one file","{0,number} files"};
 ChoiceFormat fileform = new ChoiceFormat(filelimits, filepart);
 form.setFormatByArgumentIndex(0, fileform);

 int fileCount = 1273;
 String diskName = "MyDisk";
 Object[] testArgs = {new Long(fileCount), diskName};

 System.out.println(form.format(testArgs));
 
The output with different values for fileCount:
 The disk "MyDisk" contains no files.
 The disk "MyDisk" contains one file.
 The disk "MyDisk" contains 1,273 files.`

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Fri Jul  8 16:03:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Jul 2022 16:03:45 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <cixG0t-Sn0Trw4NnDTAo65bamSHT-ZO1An28pnU_dW0=.3cfcf288-aeb1-41b9-b9df-081f200492f3@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
 <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
 <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>
 <9zCJcmOcfXZtR31WIXTeHGbOpkGsNRHe6yE9_m9sJ1k=.3cd48e19-de98-4c54-a934-dfc4ad738bce@github.com>
 <cixG0t-Sn0Trw4NnDTAo65bamSHT-ZO1An28pnU_dW0=.3cfcf288-aeb1-41b9-b9df-081f200492f3@github.com>
Message-ID: <3cKJYyJLilecrInoYuBVb0woZs_ux7s_TmAc-9W4w_E=.1e93d942-fcc1-47ac-b09c-d3642e3375b6@github.com>

On Fri, 8 Jul 2022 15:02:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen.
>> 
>>> Before JDK-8182043, the icon was either 16?16 or 32?32 and didn't change if the scale was changed. Now the icon gets updated after the scale changes, it's noticeable on folder icons in user's home because a set of icons is fetched.
>> 
>> Before the JDK-8182043 we also used the MRI so it should be changed if the scale was changed from low to hidpi. It adds more variants which could be used by some other DPI, I think one important new variant is the 64x64 because it used as a large icon on HiDPI monitor. But if the dpi is 125% or 150% it will not work even if the user will [try to request](https://github.com/openjdk/jdk/pull/2875#discussion_r641078169) such image.
>> 
>>> There are still two different ways where icons are fetched from the Windows shell: `Java_sun_awt_shell_Win32ShellFolder2_getIcon` and `Java_sun_awt_shell_Win32ShellFolder2_extractIcon`. As @azuev-java notes, at times the returned size doesn't match the requested size.
>> 
>> We had similar "issue" before the latest version of this change, we still have an issue related to the size value [initialization](https://github.com/openjdk/jdk/pull/7805#discussion_r887384908). So it might be other our bug caused that the size is ignored.
>> 
>>> This current proposal handles the situation where the returned icon doesn't have the requested size.
>> 
>> Take a look to the description of 8182043, the user wanted to get some large Icon, now imaging he would like to get a 79x79 icon for some file, did we provide a way to do that? I assume we even do not try to request that size from the operation system so it actually cannot ignore our request? 
>> 
>>> So, there are drawbacks and limitations in the current implementation, and there are opportunities to improve it, some of them are listed in [my comment above](https://github.com/openjdk/jdk/pull/7805#discussion_r893306463). I shall submit them so that we don't forget about them, if no one else has already done it.
>> +1
>> 
>>> Why not? To request the icon of a larger size, the object which stores the icon should keep the reference to the file or folder, folders could have custom icons, and Documents, Downloads, Pictures are the examples of such folders. This must be done on COM thread because the icons are requested from the Windows shell.
>> 
>> Because selection of the proper icon/image will be done during rendering of the component, and waiting of the results on the com thread may slowdown it. Instead we can use default image which we initially loaded, and later use the better one when it will be loaded on the com thread.
>> 
>>> I agree that we should not get all possible resolutions of an icon when only one is needed. But it's out of scope of this particular issue.
>> 
>> Yes, please take a look to these change.
>
>> Before the JDK-8182043 we also used the MRI so it should be changed if the scale was changed from low to hidpi. It adds more variants which could be used by some other DPI, I think one important new variant is the 64x64 because it used as a large icon on HiDPI monitor.
> 
> MRI was used only to accommodate for the fact that shell may return icon of higher resolution according the system settings.
> 
> https://github.com/openjdk/jdk/blob/978bed6c7ff64148474df3dd1ab3b3707005b8fa/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L1032-L1034
> 
> If the main monitor scale was set to 200% and 16?16 icon was requested, the system returned 32?32.
> 
> In no way it handled different scale settings.
> 
>>  But if the dpi is 125% or 150% it will not work even if the user will [try to request](https://github.com/openjdk/jdk/pull/2875#discussion_r641078169) such image.
> 
> The current code by @azuev-java handles this situation because the icon returned will contain five variants for the range of 100%, 125%, 150%, 175%, 200%.
> 
> I don't clearly understand your concern here.
> 
>> Take a look to the description of 8182043, the user wanted to get some large Icon, now imaging he would like to get a 79x79 icon for some file, did we provide a way to do that? I assume we even do not try to request that size from the operation system so it actually cannot ignore our request?
> 
> No, we do not request 79?79 because such an icon never exists in Windows because Windows shell does not use such a size to display a file. Well, it may exist if a developer for some reason included it in the app resources but it would rather be an exceptional case.
> 
> So if a Java app developer wants 79?79 icon, it will be scaled down from 96?96 or 128?128.

> > Why not? To request the icon of a larger size, the object which stores the icon should keep the reference to the file or folder, folders could have custom icons, and Documents, Downloads, Pictures are the examples of such folders. This must be done on COM thread because the icons are requested from the Windows shell.
> 
> Because selection of the proper icon/image will be done during rendering of the component, and waiting of the results on the com thread may slowdown it. Instead we can use default image which we initially loaded, and later use the better one when it will be loaded on the com thread.

This sounds reasonable? until you take into account the fact the `Icon` or `ImageIcon` has no reference to a component. When the icon is requested, the scale at which will be rendered is unknown.

When an icon is rendered and the required variant does not exist in the MRI, there's no way to fetch it asynchronously: the icon can't make the component repaint because there's no reference to the component.

The only optimisation that I see is to request only the size which correspond to the current monitor scales. If a different size is needed, a synchronous call to COM thread is required; and for this the icon must keep the path to the file.

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

PR: https://git.openjdk.org/jdk/pull/7805


From vkempik at openjdk.org  Fri Jul  8 17:38:26 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 17:38:26 GMT
Subject: [jdk19] RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
Message-ID: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>

Clean backport to jdk19

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

Commit messages:
 - Backport d852e99ae9de4c611438c50ce37ea1806f58cbdf

Changes: https://git.openjdk.org/jdk19/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289697
  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/125/head:pull/125

PR: https://git.openjdk.org/jdk19/pull/125


From vkempik at openjdk.org  Fri Jul  8 17:52:58 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 17:52:58 GMT
Subject: [jdk19] RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
References: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
Message-ID: <ofVJZVYEekoSvLVJyXFbDHod-8FNZb2WDX5FElxRT58=.85af9a30-5d06-4843-af4e-ca3746475b9b@github.com>

On Fri, 8 Jul 2022 17:28:32 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Clean backport to jdk19

As far as I understand, between rdp1 and rdp2 dates I need no approval for p3 bug

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

PR: https://git.openjdk.org/jdk19/pull/125


From vkempik at openjdk.org  Fri Jul  8 17:52:59 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 17:52:59 GMT
Subject: [jdk19] Integrated: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
References: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
Message-ID: <fOghF1hXo6pGF0npDN9-5OimZJYHBnNIpbKkXjAllNU=.202e3c4a-ffa3-4b6b-bd6b-70f9ce0c1d42@github.com>

On Fri, 8 Jul 2022 17:28:32 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Clean backport to jdk19

This pull request has now been integrated.

Changeset: c142fbbb
Author:    Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c142fbbbafcaa728cbdc56467c641eeed511f161
Stats:     12 lines in 1 file changed: 10 ins; 0 del; 2 mod

8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad

Backport-of: d852e99ae9de4c611438c50ce37ea1806f58cbdf

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

PR: https://git.openjdk.org/jdk19/pull/125


From prr at openjdk.org  Fri Jul  8 20:21:42 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Jul 2022 20:21:42 GMT
Subject: [jdk19] RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <ofVJZVYEekoSvLVJyXFbDHod-8FNZb2WDX5FElxRT58=.85af9a30-5d06-4843-af4e-ca3746475b9b@github.com>
References: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
 <ofVJZVYEekoSvLVJyXFbDHod-8FNZb2WDX5FElxRT58=.85af9a30-5d06-4843-af4e-ca3746475b9b@github.com>
Message-ID: <6hHmNrfL1F2vpWXyz8XDvfXlBKy0jrN7cu3HU23-gYQ=.b7846fd7-ebe7-4972-9096-97860c452b48@github.com>

On Fri, 8 Jul 2022 17:48:40 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> As far as I understand, between rdp1 and rdp2 dates I need no approval for p3 bug

HOWEVER, if you intend a fix for JDK N after RDP1 then the PR for review should be against JDK N - NOT mainline.
JDK N (ie 19) fixes are forward ported to mainline - not the way round you did it.
Also there is a HIGH burden on YOU to test it THOROUGHLY. 
So what you did is exploit the skara clean backport rules in a way that they aren't intended for.

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

PR: https://git.openjdk.org/jdk19/pull/125


From vkempik at openjdk.org  Fri Jul  8 20:42:41 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 8 Jul 2022 20:42:41 GMT
Subject: [jdk19] RFR: 8289697: buffer overflow in MTLVertexCache.m:
 MTLVertexCache_AddGlyphQuad
In-Reply-To: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
References: <ax_Uld8apfAIYm06SukJ5nfNdPh232cGUVs5wplu80w=.4a254bd7-fc28-4322-a968-0dc9af417461@github.com>
Message-ID: <Fk07xGIU10wKKP38S5cSBSZiwysE7j4FCA16y62L7Ck=.76ebf9d5-d969-4e8a-86b8-7d1943ad9bdd@github.com>

On Fri, 8 Jul 2022 17:28:32 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Clean backport to jdk19

Sorry. that wasn't clear from the jep text:
https://openjdk.org/jeps/3
If the bug is current then develop a fix and either **integrate it when ready (in RDP 1)** or request approval to integrate it via the [fix-request process](https://openjdk.org/jeps/3#Fix-Request-Process) (RDP 2 and RC). In RDP 1, if the bug is targeted and if time permits, develop and integrate a fix when ready.

>So what you did is exploit the skara clean backport rules in a way that they aren't intended for.

unintentionally

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

PR: https://git.openjdk.org/jdk19/pull/125


From achung at openjdk.org  Fri Jul  8 22:40:09 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 8 Jul 2022 22:40:09 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java
Message-ID: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>

Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.

The test is passing on all platforms after this change.

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

Commit messages:
 - removed darkening of icons on button press in Aqua, workaround robot getPixel on cursor bug in test

Changes: https://git.openjdk.org/jdk/pull/9436/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8169187
  Stats: 16 lines in 3 files changed: 8 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9436.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9436/head:pull/9436

PR: https://git.openjdk.org/jdk/pull/9436


From achung at openjdk.org  Fri Jul  8 22:42:20 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 8 Jul 2022 22:42:20 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v2]
In-Reply-To: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
Message-ID: <GwgGqD1iPvZxX6kY-f67hXy7QG0_m70_UIblwP8mZSo=.ef25373d-122c-4c0e-8538-58be6ee5a57e@github.com>

> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
> 
> The test is passing on all platforms after this change.

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

  updated copyright dates, removed debug print statements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9436/files
  - new: https://git.openjdk.org/jdk/pull/9436/files/d7fc6773..ca002830

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=00-01

  Stats: 11 lines in 2 files changed: 0 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9436.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9436/head:pull/9436

PR: https://git.openjdk.org/jdk/pull/9436


From prr at openjdk.org  Fri Jul  8 23:01:43 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Jul 2022 23:01:43 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
Message-ID: <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>

On Mon, 4 Jul 2022 09:31:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
> 
> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
> 
> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.

I must be missing something here, since you say you saw a crash and this fixes it.

Principally you seem to be making access to the deferredRecords list thread safe.
But first I'm not sure how where the MT problem is.
The code that disposes on the rendering thread is invoked from a dispose() method
that was on the Disposer thread. It then waits for that to finish.
At that time the Disposer thread is blocked so not doing anything and the render
thread is free to add elements to deferredRecords.
When it returns the deferredRecords are cleared on the Disposer thread and the
rendering thread can't be adding anything to it.

Second if it is just about MT access to deferredRecords and pulling elements off
that queue then why aren't we getting a Java exception about concurrent modification
instead of a crash.

And if we do somehow have two threads that end up trying to free the same data
- ie both executing the dispose() method of an instance, since they are all
(or should) be synchronized AND are supposed to check if they've already been
freed .. why isn't that working ? 

So what am I missing ?

BTW when we run this test since it is a headless test we would never have accelerated
glyphs .. and the same is true of your new tests .. so I imagine in our test harness
and that of others too they'll all always pass.

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

PR: https://git.openjdk.org/jdk/pull/9362


From duke at openjdk.org  Sun Jul 10 11:41:57 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sun, 10 Jul 2022 11:41:57 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v4]
In-Reply-To: <9J2uqNgaQjlG3n98vm__aFcASjJi6uATbjjSHxI7dwA=.ba191d67-740f-4afd-a654-03f471e23bb3@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <3aUzwJTlKj3o0N9WbF7EHfFB2KwPBA1z5vCsjabSN4U=.f431f660-b8f2-41ab-915a-0014c33fd0d7@github.com>
 <9J2uqNgaQjlG3n98vm__aFcASjJi6uATbjjSHxI7dwA=.ba191d67-740f-4afd-a654-03f471e23bb3@github.com>
Message-ID: <5FG0z-xvzOLGkbpV_l677FmWTAUFSgCsMJ8w0e2-hjY=.9678bd13-bbe0-490e-a639-94fbc25d15b4@github.com>

On Sat, 25 Jun 2022 01:13:34 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8269806: Fix rendering of colored glyphs on big font sizes
>>    
>>    When using OutlineTextRenderer, fallback to GlyphListPipe for glyphs which doesn't have outlines.
>>  - 8269806: Fix glyph advance rounding with FM=OFF
>
> src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java line 75:
> 
>> 73:     public void drawString(SunGraphics2D g2d, String str, double x, double y) {
>> 74: 
>> 75:         StandardGlyphVector sgv = new StandardGlyphVector(g2d.getFont(), str, g2d.getFontRenderContext());
> 
> I started using `GlyphVector` instead of `TextLayout` because it gives more consistent look for animated text. For example, earlier text which has ligatures rendered with `drawString` was drawn with ligatures on `OutlineTextRenderer` and without on `GlyphListPipe`, which caused artifacts when text size crosses 100 threshold.

Oh I see this is incorrect, I will try to come up with a different approach

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

PR: https://git.openjdk.org/jdk/pull/4798


From serb at openjdk.org  Mon Jul 11 01:40:39 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 11 Jul 2022 01:40:39 GMT
Subject: RFR: 8289853: Update HarfBuzz to 4.4.1
In-Reply-To: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
References: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
Message-ID: <lnGa9SP19BfaBv2D1bNCBXPyof-H6zCG9cYAn9j2XQ0=.44eb12cf-4167-4016-8764-27e43e58bd06@github.com>

On Thu, 7 Jul 2022 23:06:26 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK's version of harfbuzz to 4.4.1. The current version is 2.8.0
> Builds on all platforms. Testing looks good.
> I've added an UPDATING.txt file with tips on the steps involved in these upgrades.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9420


From duke at openjdk.org  Mon Jul 11 08:07:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 08:07:28 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v2]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <QbYlemn0NGMLglclmATPHoJh63z_nzkp4aq53FVwy4w=.00ff0838-3bca-444c-83a2-ec12ef9de9f0@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

?????? ??????? 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:

 - Merge branch 'master' into 8289908
 - 8289908: Make constructor private and use trailing Void instead of int
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/567727e9..294e91f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00-01

  Stats: 11699 lines in 1295 files changed: 3911 ins; 1617 del; 6171 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Mon Jul 11 08:07:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 08:07:28 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v2]
In-Reply-To: <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
Message-ID: <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>

On Fri, 8 Jul 2022 14:04:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?
>
> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.
> 
> The constructor should be private, it has a very narrow scope of use given the lack of checking its args.
> 
> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
> it would have broader applicability then this point fix.
> I would be interesting to ask the compiler folks if that's a future optimization.
> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.

Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params.

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

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Mon Jul 11 08:46:51 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 11 Jul 2022 08:46:51 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <-VZrwMJC_45puGGx1duuICxJF5_j860gqyEH8FGHdbU=.6a302f3c-ae1c-4f16-8bff-f5ce6bf4786a@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
 <-VZrwMJC_45puGGx1duuICxJF5_j860gqyEH8FGHdbU=.6a302f3c-ae1c-4f16-8bff-f5ce6bf4786a@github.com>
Message-ID: <GoNoGZ9KRLRl3YE2Z7rJ1NGIbQS9jrbZH7P5-P8AG4E=.d45888ff-5ccb-48d4-a844-4f82d2b8bac8@github.com>

On Thu, 7 Jul 2022 21:03:04 GMT, Phil Race <prr at openjdk.org> wrote:

> The bug suggests returns true if one of this JLabel's icon or disabled icon is derived from ImageIcon and it's Image is equal to the image passed in; false otherwise.
> 
> But looking at the code .. I don't think that is quite right either //// public boolean imageUpdate(Image img, int infoflags, int x, int y, int w, int h) { // Don't use getDisabledIcon, will trigger creation of icon if icon // not set. if (!isShowing() || !SwingUtilities.doesIconReferenceImage(getIcon(), img) && !SwingUtilities.doesIconReferenceImage(disabledIcon, img)) {
> 
> ```
>         return false;
>     }
>     return super.imageUpdate(img, infoflags, x, y, w, h);
> }
> ```
> 
> ///
> 
> So if they are the same what it actually does isn't return true - it returns whatever super does ! So the original text was in some ways better and its main problem was just referring to Icon which is the interface that will only have an Image if the implementing class is ImageIcon There's also the isShowing condition which nothing seems to cover.
> 
> So for JLabel we want something like If the component is not showing, or either the icon or disabled icon is not an {@code ImageIcon} with an {@code Image} equal to the passed in {@code Image} this method will return false. Otherwise it will delegate to the super-class.
> 
> What do you think ?
> 
> AbstractButton may need something similar but I'll leave that to you to check

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

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Mon Jul 11 09:26:01 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 09:26:01 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v2]
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <ZDXZX3Pxn0DWw8b3eTmGjfTwq3l5qxV84N_LQD3m3Sk=.84f8fd9e-1344-456c-abd6-ecee15c94012@github.com>

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Restrict recursion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9388/files
  - new: https://git.openjdk.org/jdk/pull/9388/files/9376b0ff..9d47f7d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9388&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9388&range=00-01

  Stats: 30 lines in 1 file changed: 7 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9388.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9388/head:pull/9388

PR: https://git.openjdk.org/jdk/pull/9388


From psadhukhan at openjdk.org  Mon Jul 11 09:26:02 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 09:26:02 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v2]
In-Reply-To: <ttNf02ZqyRUvypkRd7AmhUzPJSCr-KzeInmQMlagl3A=.da76e134-098a-4ecd-9ef8-b2a13ac6eca7@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <EQ33Jj2t5nXmvHy4pyRFCsHHr-h3quD8FC5GYR6AmS0=.345dd0ec-55d2-4d4f-a5d1-bfd7147ae7f1@github.com>
 <5zeBDi80Ypn6lyrK9jSAvPcrBFZhjf4qozQm5yoILG4=.246d708a-e2e0-4fe0-b9e4-c8f304d1bac3@github.com>
 <ttNf02ZqyRUvypkRd7AmhUzPJSCr-KzeInmQMlagl3A=.da76e134-098a-4ecd-9ef8-b2a13ac6eca7@github.com>
Message-ID: <1-crDRevFdGBTVm_nVf7hyWO3ah2FjrPFTiv6GVVSi4=.b1554829-59d0-46ef-9241-cf19dbcc7284@github.com>

On Fri, 8 Jul 2022 14:07:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > Maybe we should rather limit the number of recursive calls? You caught `StackOverflowError`, at this stage there's not much space left on the stack. It may cause another `StackOverflowError`.
> > 
> > 
> > I thought that but then thought limiting will not be foolproof as stack size can be modified by -Xss.
> 
> If the limit is low, let's say 20-30 lines, it shouldn't be a problem.
> 
> I'm afraid a message with more than 200 lines won't fit on the screen anyway.

OK. Seems logical..I guess it could be much less lines that fit in screen but anyways, to be safe I restrict to this.

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

PR: https://git.openjdk.org/jdk/pull/9388


From psadhukhan at openjdk.org  Mon Jul 11 09:28:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 09:28:22 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9388/files
  - new: https://git.openjdk.org/jdk/pull/9388/files/9d47f7d0..d166ed01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9388&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9388&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9388


From mkartashev at openjdk.org  Mon Jul 11 10:04:33 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 11 Jul 2022 10:04:33 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
Message-ID: <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>

On Fri, 8 Jul 2022 22:58:08 GMT, Phil Race <prr at openjdk.org> wrote:

> The code that disposes on the rendering thread is invoked from a dispose() method
that was on the Disposer thread. It then waits for that to finish.
At that time the Disposer thread is blocked so not doing anything and the render
thread is free to add elements to deferredRecords.

Correct. Now let's suppose that the rendering thread - unblocked at the time - is adding more records such that `ArrayList` needs to grow. Now `ArrayList` starts relocating its underlying storage array at the time as `dispose()` returns and we're ready for the next iteration of 

for (int i=0;i<deferredRecords.size(); i++) {
``` 
loop. The next call to `ArrayList.get()` here

DisposerRecord rec = deferredRecords.get(i);

will be executed on the disposer thread simultaneously with the array relocation of `deferredRecords`. So some of the `get()` calls will return `null` as they read from initialized, but yet-to-be-relocated chunks, and some will read what essentially is garbage.

> Second if it is just about MT access to deferredRecords and pulling elements off
that queue then why aren't we getting a Java exception about concurrent modification
instead of a crash.

The race was between `ArrayList.get()` called from `clearDeferredRecords()` on a dedicated disposer thread and `ArrayList.add()` called from `pollRemove()` on a _different_ thread. AFAIK there are no safeguards against concurrent modification between those two methods (I check the implementation).

> And if we do somehow have two threads that end up trying to free the same data ie both executing the dispose() method of an instance

I didn't imply that `dispose()` was called twice on the same instance. I said "probably due to double-free" (or "bad" free in the bug description) simply because these are the checks that are usually implemented in the heap alloc/dealloc routines, so "double-free" is likely with the second free called from one of the `dispose()` methods; I have no idea who called the first `free()` and when.

> BTW when we run this test since it is a headless test we would never have accelerated
glyphs .. and the same is true of your new tests .. so I imagine in our test harness
and that of others too they'll all always pass.

Are you implying that `test/jdk/java/awt/Graphics2D/DrawString/DisposerTest.java` is useless in the headless mode? Then I can mark it as `headful`. I can also simply drop it.

Be that as it may, `test/jdk/sun/java2d/Disposer/TestDisposerRace.java` doesn't depend on any acceleration and is as removed from any 2D code as it can be. And it also shows the problem on Linux, making the one mentioned above somewhat superfluous.

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

PR: https://git.openjdk.org/jdk/pull/9362


From aivanov at openjdk.org  Mon Jul 11 10:10:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Jul 2022 10:10:47 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
Message-ID: <DaC8Hi1c0Cy2NhbcOqJG3gwgyFjCWdZrnn4WS75tpVE=.41b6a60c-daa4-483e-8dee-646b261a82df@github.com>

On Mon, 11 Jul 2022 09:28:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
>> Fixed by catching StackOverflow and ignoring so that application is not stuck.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java line 480:

> 478:                 }
> 479:                 // Prevent recursion of more than
> 480:                 // 200 successive newlines in a message

Not necessarily ?successive?, but I'm nitpicking.

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

PR: https://git.openjdk.org/jdk/pull/9388


From psadhukhan at openjdk.org  Mon Jul 11 11:38:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 11:38:43 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
Message-ID: <vYolKKST2ws2HuJ7OL33UnbvfbXDSxj2cOg3KxxmtLc=.80675c72-2d30-44c0-ab7b-5702cc9f8cbb@github.com>

On Mon, 11 Jul 2022 09:28:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
>> Fixed by catching StackOverflow and ignoring so that application is not stuck.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format

I guess if it's not successive, it will not exercise this condition so it will not recurse as much

if (nl >= 0) {
                // break up newlines
                if (nl == 0) {

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

PR: https://git.openjdk.org/jdk/pull/9388


From psadhukhan at openjdk.org  Mon Jul 11 11:38:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 11:38:45 GMT
Subject: Integrated: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError
In-Reply-To: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
Message-ID: <K1jGiTNnqpD2v6xCCd3BBGo_64B5da-SV87Mr-9bpss=.4568ff0e-e590-4e3b-8ed3-e7122d91f832@github.com>

On Wed, 6 Jul 2022 05:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
> Fixed by catching StackOverflow and ignoring so that application is not stuck.

This pull request has now been integrated.

Changeset: 46251bc6
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46251bc6e248a19e8d78173ff8d0502c68ee1acb
Stats:     68 lines in 2 files changed: 66 ins; 0 del; 2 mod

8224267: JOptionPane message string with 5000+ newlines produces StackOverflowError

Reviewed-by: tr, aivanov

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

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Mon Jul 11 11:46:21 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 11:46:21 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

  8289908: Fixed tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/294e91f7..b7375cd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407


From aivanov at openjdk.org  Mon Jul 11 11:58:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Jul 2022 11:58:40 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <vYolKKST2ws2HuJ7OL33UnbvfbXDSxj2cOg3KxxmtLc=.80675c72-2d30-44c0-ab7b-5702cc9f8cbb@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
 <vYolKKST2ws2HuJ7OL33UnbvfbXDSxj2cOg3KxxmtLc=.80675c72-2d30-44c0-ab7b-5702cc9f8cbb@github.com>
Message-ID: <zbB-YdCd1q2pypj0LAnFkHNDiYnZcZUH9JCLs81djeg=.c0c513ba-a2e0-480f-ac55-e848186daead@github.com>

On Mon, 11 Jul 2022 11:34:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess if it's not successive, it will not exercise this condition so it will not recurse as much
> 
> ```
> if (nl >= 0) {
>                 // break up newlines
>                 if (nl == 0) {
> ```

In that sense? I thought about successive in this case like `\n\n\n` but it applies to *all the new lines* in a one message.

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

PR: https://git.openjdk.org/jdk/pull/9388


From aivanov at openjdk.org  Mon Jul 11 12:02:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Jul 2022 12:02:50 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
Message-ID: <HLbTB_GpDhGJl3zGLr9liIMoGiunOK0UjaW5_ug_KXI=.05f5e16a-25c1-441b-a8d9-ad453fa8de02@github.com>

On Mon, 11 Jul 2022 09:28:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
>> Fixed by catching StackOverflow and ignoring so that application is not stuck.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format

Hm? there could be problem: **the counter isn't reset** when the function is called again. It's reset only when the limit is reached. Or do I miss another case where the counter is reset?

The easiest way could be to introduce a helper function which is called from the main function that breaks the message and to which the recursion counter is passed as a parameter.

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

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Mon Jul 11 12:25:39 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 12:25:39 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
 <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
Message-ID: <mS162Cy-DL-dLLgL4ZtZ3hXudpcpWZPoDoiq99f8IAw=.ba25b054-953d-4878-a258-24f7146830aa@github.com>

On Mon, 11 Jul 2022 08:02:43 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
>> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.
>> 
>> The constructor should be private, it has a very narrow scope of use given the lack of checking its args.
>> 
>> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
>> it would have broader applicability then this point fix.
>> I would be interesting to ask the compiler folks if that's a future optimization.
>> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.
>
> Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params.

Benchmark results after:

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,354 ? 0,195  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,035 ? 0,088  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,166 ? 0,062  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,132 ? 0,054  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,416 ? 0,206  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,421 ? 0,041  ns/op

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

PR: https://git.openjdk.org/jdk/pull/9407


From psadhukhan at openjdk.org  Mon Jul 11 12:33:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 11 Jul 2022 12:33:42 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <HLbTB_GpDhGJl3zGLr9liIMoGiunOK0UjaW5_ug_KXI=.05f5e16a-25c1-441b-a8d9-ad453fa8de02@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
 <HLbTB_GpDhGJl3zGLr9liIMoGiunOK0UjaW5_ug_KXI=.05f5e16a-25c1-441b-a8d9-ad453fa8de02@github.com>
Message-ID: <zSsZ0eN03sDwX_SNmuTFMRPOY-Bxru8B7l16TODeGnI=.6bd50fb1-7a4b-4fb1-934e-06fc9c605af5@github.com>

On Mon, 11 Jul 2022 11:59:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Hm? there could be problem: **the counter isn't reset** when the function is called again. It's reset only when the limit is reached. Or do I miss another case where the counter is reset?
> 
> The easiest way could be to introduce a helper function which is called from the main function that breaks the message and to which the recursion counter is passed as a parameter.

I dont think it's a problem with other cases as in those "msg" is non String and so wont recurse as much as successive newline case in this condition, so I have made it to reset in this.

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

PR: https://git.openjdk.org/jdk/pull/9388


From aivanov at openjdk.org  Mon Jul 11 12:44:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Jul 2022 12:44:47 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <zSsZ0eN03sDwX_SNmuTFMRPOY-Bxru8B7l16TODeGnI=.6bd50fb1-7a4b-4fb1-934e-06fc9c605af5@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
 <HLbTB_GpDhGJl3zGLr9liIMoGiunOK0UjaW5_ug_KXI=.05f5e16a-25c1-441b-a8d9-ad453fa8de02@github.com>
 <zSsZ0eN03sDwX_SNmuTFMRPOY-Bxru8B7l16TODeGnI=.6bd50fb1-7a4b-4fb1-934e-06fc9c605af5@github.com>
Message-ID: <7Ov0F96GnlEa-zEmQuVrN4nKn7rtLAchumoH7wPc_Hg=.a2c69f8c-71e1-4075-b273-c6a057dd9d5b@github.com>

On Mon, 11 Jul 2022 12:29:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Hm? there could be problem: **the counter isn't reset** when the function is called again. It's reset only when the limit is reached. Or do I miss another case where the counter is reset?
> >
> > The easiest way could be to introduce a helper function which is called from the main function that breaks the message and to which the recursion counter is passed as a parameter.
> 
> I dont think it's a problem with other cases as in those "msg" is non String and so wont recurse as much as successive newline case in this condition, so I have made it to reset in this.

If the message contains new lines, let's say 20 new lines each. Then I call `JOptionPane.showMessageDialog` continuously with the same message. Since the counter is not reset between the calls, the 10th call would stop breaking the message at the first new line in the message, which doesn't look correct.

I think we have just introduced a new bug which needs resolving.

As another thought, shall we indicate the original message is truncated? Add `...` (ellipsis) to the previous line of text?

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

PR: https://git.openjdk.org/jdk/pull/9388


From asemenov at openjdk.org  Mon Jul 11 13:42:51 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 11 Jul 2022 13:42:51 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
Message-ID: <W-gPd9B3KJ93VMBlZBevuKyQxbkH4TQKeo4l7Pypvn4=.4e031c21-9daf-4d47-8342-341a8a2adf30@github.com>

On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We don't do @author tags in openjdk
>   Not 2022 ?

@azuev-java @prrace  please review this CSR ticket [JDK-8286674](https://bugs.openjdk.org/browse/JDK-8286674)

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

PR: https://git.openjdk.org/jdk/pull/8578


From dnguyen at openjdk.org  Mon Jul 11 15:38:00 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 11 Jul 2022 15:38:00 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
Message-ID: <A95MRzTqPBvLmFFwjq4RjizCHMiEXk61rrOxa3Jsepc=.d40c64a3-0561-4794-b520-1aa531d139f3@github.com>

On Thu, 9 Jun 2022 19:53:22 GMT, Phil Race <prr at openjdk.org> wrote:

> ImageIO.read() only documents IOException for any kind of decoding problem and since
> it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
> So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
> an IIOException. This will give more stable app behaviour and still report the underlying problem.

The change makes sense to me. I built and ran your test with the change and it works on my end. Looks good to me.

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/9113


From duke at openjdk.org  Mon Jul 11 17:22:51 2022
From: duke at openjdk.org (duke)
Date: Mon, 11 Jul 2022 17:22:51 GMT
Subject: Withdrawn: 8185261: Font fallback sometimes doesn't work in Swing text
 components
In-Reply-To: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com>
Message-ID: <um5VPFw_zqjZbtLYB2vFY1yxHHm-3JtQ_4dnHpDC9Vk=.999005fd-c42b-4250-9ca2-474b220e4191@github.com>

On Tue, 1 Feb 2022 18:38:39 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that
> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field
> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be
> 'created' fonts anymore, to preserve their `Font2D` handle.
> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created
> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and
> deserialization.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/7313


From azvegint at openjdk.org  Mon Jul 11 19:16:52 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 11 Jul 2022 19:16:52 GMT
Subject: RFR: 8289853: Update HarfBuzz to 4.4.1
In-Reply-To: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
References: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
Message-ID: <L4M4JJpZRvDbaFkGjRaR4hUbpZ41qdxTib5QTfww4e4=.115d98ed-adf1-4d38-8c2c-da50bdd405ca@github.com>

On Thu, 7 Jul 2022 23:06:26 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK's version of harfbuzz to 4.4.1. The current version is 2.8.0
> Builds on all platforms. Testing looks good.
> I've added an UPDATING.txt file with tips on the steps involved in these upgrades.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9420


From prr at openjdk.org  Mon Jul 11 19:23:45 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 11 Jul 2022 19:23:45 GMT
Subject: Integrated: 8289853: Update HarfBuzz to 4.4.1
In-Reply-To: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
References: <hH3-piJgd_tDx4D-cLm1sWKU0J3a64K2Rol9BnoKmes=.804986c6-7e7b-4009-ae3f-d8a04bcded30@github.com>
Message-ID: <sUOkIA0pVKPs7j6I8GgLBnScPKUS_vvBCLmHYjawDrs=.a443a0ef-c736-4749-904c-60c05361b496@github.com>

On Thu, 7 Jul 2022 23:06:26 GMT, Phil Race <prr at openjdk.org> wrote:

> This upgrades the JDK's version of harfbuzz to 4.4.1. The current version is 2.8.0
> Builds on all platforms. Testing looks good.
> I've added an UPDATING.txt file with tips on the steps involved in these upgrades.

This pull request has now been integrated.

Changeset: f42dab85
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f42dab85924d6a74d1c2c87bca1970e2362f45ea
Stats:     58001 lines in 275 files changed: 32096 ins; 18824 del; 7081 mod

8289853: Update HarfBuzz to 4.4.1

Reviewed-by: serb, azvegint

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

PR: https://git.openjdk.org/jdk/pull/9420


From serb at openjdk.org  Tue Jul 12 01:02:26 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Jul 2022 01:02:26 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <7Ov0F96GnlEa-zEmQuVrN4nKn7rtLAchumoH7wPc_Hg=.a2c69f8c-71e1-4075-b273-c6a057dd9d5b@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
 <HLbTB_GpDhGJl3zGLr9liIMoGiunOK0UjaW5_ug_KXI=.05f5e16a-25c1-441b-a8d9-ad453fa8de02@github.com>
 <zSsZ0eN03sDwX_SNmuTFMRPOY-Bxru8B7l16TODeGnI=.6bd50fb1-7a4b-4fb1-934e-06fc9c605af5@github.com>
 <7Ov0F96GnlEa-zEmQuVrN4nKn7rtLAchumoH7wPc_Hg=.a2c69f8c-71e1-4075-b273-c6a057dd9d5b@github.com>
Message-ID: <zso1AXJjTcnpleso7HVwH63YsZKkjOgcVf_GNxKRKJs=.435c6fa7-12bb-4335-9847-9222318be05c@github.com>

On Mon, 11 Jul 2022 12:41:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> shall we indicate the original message is truncated? Add ... (ellipsis) to the previous line of text?

I think this is a great idea.

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

PR: https://git.openjdk.org/jdk/pull/9388


From duke at openjdk.org  Tue Jul 12 03:24:44 2022
From: duke at openjdk.org (j3graham)
Date: Tue, 12 Jul 2022 03:24:44 GMT
Subject: RFR: 8224267: JOptionPane message string with 5000+ newlines
 produces StackOverflowError [v3]
In-Reply-To: <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
References: <Om42QViudDnYW6_zOFMbsY9MYzbXJEZGwR4q2lXVWg4=.bd9d2535-5b5e-43af-83b8-7a520f987a46@github.com>
 <586UTwOonf88JObGHoIhoLYayp6P3GpibGrQwJy-Wgg=.3818525b-e00f-4c50-ad5b-6b8840a68024@github.com>
Message-ID: <GCLHkl-JLUuB3PL0TvaTRw-8UQ8FKY27Wz5asoUf-D4=.77e642db-a4bb-4be6-9682-89ee619f7d94@github.com>

On Mon, 11 Jul 2022 09:28:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicOptionPaneUI.addMessageComponents() uses recursion to split message strings at newlines, generating a StackOverflowError when the message string contains an unusually large number of newlines.
>> Fixed by catching StackOverflow and ignoring so that application is not stuck.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format

An alternative approach would be to avoid recursion when splitting the string.

Instead, create a new private method that does the string processing for strings without newlines. Then split the string on newlines, and call that new method for each one. ?String.lines? might be a close enough match to do the splitting - one difference would be that it always splits on \r, \n and \r\n instead of looking at the system newline value.

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

PR: https://git.openjdk.org/jdk/pull/9388


From psadhukhan at openjdk.org  Tue Jul 12 09:51:11 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Jul 2022 09:51:11 GMT
Subject: RFR: 8290162: Reset recursion counter missed in fix of JDK-8224267
Message-ID: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>

`recursionCount` counter added in fix of JDK-8224267 is only reset when limit is reached,  so it will behave incorrectly if JOptionPane.showMessageDialog continuously with the same message having newlines, so it needs to be reset also at appropriate location. 
Fix to reset the counter before the recursive method is called.

Also, fix added to indicate the original message is truncated by adding ... (ellipsis) to the previous line of text if it recurses more than limit set.

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

Commit messages:
 - Fix
 - Reset counter fix

Changes: https://git.openjdk.org/jdk/pull/9464/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290162
  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9464.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9464/head:pull/9464

PR: https://git.openjdk.org/jdk/pull/9464


From psadhukhan at openjdk.org  Tue Jul 12 11:01:51 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Jul 2022 11:01:51 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>
Message-ID: <dkA_iizvGKJWFa8ldpjqOkbAt12Y6caSKy9_WQ4pleM=.f38bd067-3903-49a4-b2f9-ed03655ea98f@github.com>

On Fri, 8 Jul 2022 08:02:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 95:
>> 
>>> 93:         "alt altgraph LEFT", DefaultEditorKit.previousWordAction,
>>> 94:         "alt altgraph RIGHT", DefaultEditorKit.nextWordAction,
>>> 95:         "alt UP", DefaultEditorKit.beginLineUpAction,
>> 
>> I find it utterly bizarre to say we need "altgraph" when macOS doesn't have altgraph - certainly not on the k/bs on current mac books or imacs.
>> 
>> My take is that the previous fix JDK-8151136 was a mistake and we should have just excluded the test there on macOS.
>
> As per offline discussion with @prrace ALT_GRAPH support done via JDK-8151136 is reverted and tests testing ALT_GRAPH in macos is excluded..
> @prrace can you please review?

Even if JavaFX, Left and Right Option key is mapped to ALT so I guess we will be consistent with that too.

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

PR: https://git.openjdk.org/jdk/pull/9230


From mvs at openjdk.org  Tue Jul 12 11:24:46 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 12 Jul 2022 11:24:46 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
Message-ID: <maaQG3BgZPTVkb-b42AoSwvUUmmGd7BuzaX6Dpaihv8=.d94f7169-4bde-4695-b229-ad48b30de747@github.com>

On Wed, 29 Jun 2022 06:53:29 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Reverted variable name change, reverted +20 in point

Any volunteers?

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

PR: https://git.openjdk.org/jdk/pull/9187


From mvs at openjdk.org  Tue Jul 12 11:24:46 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 12 Jul 2022 11:24:46 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <G-UBcityoWaQN0aB_x7J7so4cVd6bWN0kYPt78x1zdA=.7ca23540-7a51-41c8-ba6a-32308d915ef3@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Any volunteers?

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

PR: https://git.openjdk.org/jdk/pull/9202


From dnguyen at openjdk.org  Tue Jul 12 19:39:34 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 12 Jul 2022 19:39:34 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
Message-ID: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>

When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.

One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.

As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

Commit messages:
 - Updated test with PassFailJFrame
 - Added test
 - Adjusted height and coordinate for editable JComboBox

Changes: https://git.openjdk.org/jdk/pull/9473/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8054572
  Stats: 100 lines in 2 files changed: 99 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9473.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9473/head:pull/9473

PR: https://git.openjdk.org/jdk/pull/9473


From serb at openjdk.org  Tue Jul 12 19:45:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Jul 2022 19:45:54 GMT
Subject: RFR: 8289559 : java/awt/a11y/AccessibleJPopupMenuTest.java test
 fails with java.lang.NullPointerException
In-Reply-To: <T8v6uKdETvAFpSal_DGp_wY-J4B4Z4Eapv1DZDb_l1g=.afa91286-550e-4bb3-ab0f-354944745445@github.com>
References: <T8v6uKdETvAFpSal_DGp_wY-J4B4Z4Eapv1DZDb_l1g=.afa91286-550e-4bb3-ab0f-354944745445@github.com>
Message-ID: <aYKez4eEnZ7x7-P4q2KCVloJai1RNdVO0_Aa_gM-ld0=.d181c7e8-e8bc-4b50-a78d-03d6c5fcfe76@github.com>

On Thu, 30 Jun 2022 23:58:44 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Fixed the java.lang.NullPointerException & tested .
> 
> @shurymury

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9342


From serb at openjdk.org  Tue Jul 12 19:51:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Jul 2022 19:51:57 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <dkA_iizvGKJWFa8ldpjqOkbAt12Y6caSKy9_WQ4pleM=.f38bd067-3903-49a4-b2f9-ed03655ea98f@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>
 <dkA_iizvGKJWFa8ldpjqOkbAt12Y6caSKy9_WQ4pleM=.f38bd067-3903-49a4-b2f9-ed03655ea98f@github.com>
Message-ID: <9ZJ9OPQ1u8YCk5gFyqosAx9FHfNrTMumA09YTgb7CB0=.5b55e5cd-55e7-4df2-bee0-8d5cf3669c8c@github.com>

On Tue, 12 Jul 2022 10:58:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per offline discussion with @prrace ALT_GRAPH support done via JDK-8151136 is reverted and tests testing ALT_GRAPH in macos is excluded..
>> @prrace can you please review?
>
> Even if JavaFX, Left and Right Option key is mapped to ALT so I guess we will be consistent with that too.

> > One macOS you will not see the "Alt" key as well, but we use that name.
> 
> At least I can see 

Just a clarification:

On the new keyboards, it does not have it, I have two laptops where the "alt" label is missing:
![mac-keyboard-alt](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/social/keyboards-social-card.jpg)

The official document about the keyboard [mentions ](https://support.apple.com/en-us/HT201236) the "alt" key in case the windows keyboard is used: `"On keyboards made for Windows PCs, use the Alt key instead of Option, and the Windows logo key instead of Command."`

So I do not see a reason why the "right option" - "alt gr" key on the PC keyboard cannot be mapped to the ALT_GRAPH, same as "left option" - "alt" is mapped to the ALT.

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

PR: https://git.openjdk.org/jdk/pull/9230


From honkar at openjdk.org  Tue Jul 12 19:56:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 12 Jul 2022 19:56:50 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <Zt0ZlBUXucKNAER5CITuexeTwCR4p93JpED6mcphekU=.ed87ca8a-8479-425a-9250-0a014154017b@github.com>

On Tue, 12 Jul 2022 18:16:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

Changes requested by honkar (Author).

test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 59:

> 57: //
> 58: //            }
> 59: 

Might have missed removing commented lines

test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 84:

> 82:             PassFailJFrame.positionTestFrame(frame,
> 83:                     PassFailJFrame.Position.HORIZONTAL);
> 84:         });

These methods need to be changed to `addTestWindow `and `positionTestWindow` based on the recently integrated changes to PassFailJFrame. 
https://github.com/openjdk/jdk/blob/d9ca438d06166f153d11bb55c9ec672fc63c0e9e/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294

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

PR: https://git.openjdk.org/jdk/pull/9473


From javalists at cbfiddle.com  Tue Jul 12 20:17:43 2022
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 12 Jul 2022 13:17:43 -0700
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <9ZJ9OPQ1u8YCk5gFyqosAx9FHfNrTMumA09YTgb7CB0=.5b55e5cd-55e7-4df2-bee0-8d5cf3669c8c@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>
 <dkA_iizvGKJWFa8ldpjqOkbAt12Y6caSKy9_WQ4pleM=.f38bd067-3903-49a4-b2f9-ed03655ea98f@github.com>
 <9ZJ9OPQ1u8YCk5gFyqosAx9FHfNrTMumA09YTgb7CB0=.5b55e5cd-55e7-4df2-bee0-8d5cf3669c8c@github.com>
Message-ID: <2DC52A0E-A20E-4AC8-95D6-34CAC9DC001A@cbfiddle.com>

What is a ?PC keyboard?? Do you mean a keyboard attached to a machine running Windows?


> On Jul 12, 2022, at 12:51 PM, Sergey Bylokhov <serb at openjdk.org> wrote:
> 
> So I do not see a reason why the "right option" - "alt gr" key on the PC keyboard cannot be mapped to the ALT_GRAPH, same as "left option" - "alt" is mapped to the ALT.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220712/c9b70407/attachment.htm>

From prr at openjdk.org  Tue Jul 12 22:27:46 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Jul 2022 22:27:46 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
Message-ID: <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
>> 
>> **Analysis :** 
>> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
>> 1) End points (vertices) required for the primitive drawing are put in a buffer.
>> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
>> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
>> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
>> 
>> **Root Cause of slower performance :**
>> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
>> 
>> **Fix :** 
>> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
>> The primitive drawing logic is modified to collate adjacent draw calls as below -
>> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
>> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
>> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
>> 
>> 
>> **More insight :** 
>> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
>> The performance test that we have measure rendering performance of extreme cases such as -
>> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
>> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
>> 
>> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
>> 
>> **Results :**
>> The performance results are attached to the JBS.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make method inline + clean commented line

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m line 269:

> 267:     MTLRenderer_AddVertexToBatch(fx+fw, fy);
> 268: 
> 269:     MTLRenderer_AddVertexToBatch(fx+fw, fy);

Why are there several duplicates here ?

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

PR: https://git.openjdk.org/jdk/pull/9245


From prr at openjdk.org  Tue Jul 12 22:29:04 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Jul 2022 22:29:04 GMT
Subject: RFR: 8290162: Reset recursion counter missed in fix of JDK-8224267
In-Reply-To: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
References: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
Message-ID: <4y-q0SXaZwoT-fP30Ng_nHdLojXfzEUzeUzQA9hjFjI=.35652469-3bbd-446b-bc12-f461a99b5a2b@github.com>

On Tue, 12 Jul 2022 09:44:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `recursionCount` counter added in fix of JDK-8224267 is only reset when limit is reached,  so it will behave incorrectly if JOptionPane.showMessageDialog continuously with the same message having newlines, so it needs to be reset also at appropriate location. 
> Fix to reset the counter before the recursive method is called.
> 
> Also, fix added to indicate the original message is truncated by adding ... (ellipsis) to the previous line of text if it recurses more than limit set.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9464


From prr at openjdk.org  Tue Jul 12 22:32:53 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Jul 2022 22:32:53 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>
Message-ID: <-ieBZH9T_kfEdWWQPOAijkh7qx8gCm_OspehCdbfTPo=.c749524e-ac7f-4b04-8d82-5b50da62fd55@github.com>

On Mon, 11 Jul 2022 11:46:21 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289908: Fixed tests

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9407


From prr at openjdk.org  Tue Jul 12 22:35:49 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Jul 2022 22:35:49 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
Message-ID: <UCxQjzMf2mJjQ2LQvVTAukg8Jb3fHs5atTRkJhbEIug=.fcb7bdd9-8660-4284-be52-853ffa71b65d@github.com>

On Tue, 28 Jun 2022 11:15:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   passed in text added

Will there be an update to reflect the text discussed above ?

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

PR: https://git.openjdk.org/jdk/pull/9240


From dnguyen at openjdk.org  Tue Jul 12 22:56:37 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 12 Jul 2022 22:56:37 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

Damon Nguyen 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 six additional commits since the last revision:

 - Updated method names for PassFailJFrame
 - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
 - Removed commented lines. Added newlines.
 - Updated test with PassFailJFrame
 - Added test
 - Adjusted height and coordinate for editable JComboBox

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/dab81933..1d888259

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=00-01

  Stats: 518062 lines in 7117 files changed: 327149 ins; 135042 del; 55871 mod
  Patch: https://git.openjdk.org/jdk/pull/9473.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9473/head:pull/9473

PR: https://git.openjdk.org/jdk/pull/9473


From dnguyen at openjdk.org  Tue Jul 12 22:56:40 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 12 Jul 2022 22:56:40 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <Zt0ZlBUXucKNAER5CITuexeTwCR4p93JpED6mcphekU=.ed87ca8a-8479-425a-9250-0a014154017b@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <Zt0ZlBUXucKNAER5CITuexeTwCR4p93JpED6mcphekU=.ed87ca8a-8479-425a-9250-0a014154017b@github.com>
Message-ID: <ucLHWvU2VbYYkqe7XqNHnaIXhprLO4qIZ-dPkoA3WD8=.db943ed2-2e57-4561-b9d5-6543f7fbc9f1@github.com>

On Tue, 12 Jul 2022 19:49:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Damon Nguyen 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 six additional commits since the last revision:
>> 
>>  - Updated method names for PassFailJFrame
>>  - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
>>  - Removed commented lines. Added newlines.
>>  - Updated test with PassFailJFrame
>>  - Added test
>>  - Adjusted height and coordinate for editable JComboBox
>
> test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 59:
> 
>> 57: //
>> 58: //            }
>> 59: 
> 
> Might have missed removing commented lines

Thanks for catching that. I also added a few newlines for long lines of code. I think I forgot to save my latest changes.

> test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 84:
> 
>> 82:             PassFailJFrame.positionTestFrame(frame,
>> 83:                     PassFailJFrame.Position.HORIZONTAL);
>> 84:         });
> 
> These methods need to be changed to `addTestWindow `and `positionTestWindow` based on the recently integrated changes to PassFailJFrame. 
> https://github.com/openjdk/jdk/blob/d9ca438d06166f153d11bb55c9ec672fc63c0e9e/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294

I remember this conversation. I synced my local branch and updated the methods. Tested and the test still works.

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

PR: https://git.openjdk.org/jdk/pull/9473


From aghaisas at openjdk.org  Wed Jul 13 03:56:44 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 13 Jul 2022 03:56:44 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
 <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
Message-ID: <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>

On Tue, 12 Jul 2022 22:20:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make method inline + clean commented line
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m line 269:
> 
>> 267:     MTLRenderer_AddVertexToBatch(fx+fw, fy);
>> 268: 
>> 269:     MTLRenderer_AddVertexToBatch(fx+fw, fy);
> 
> Why are there several duplicates here ?

Earlier logic used to draw a rectangle with MTLPrimitiveTypeLineStrip. Hence, 5 vertices were specified to  draw 4 sides of the rectangle.
Now, the logic has been changed to use MTLPrimitiveTypeLine. Hence, 4 lines need to be specified separately by specifying 8 vertices. There are duplicates since the lines are connected.

We cannot use MTLPrimitiveTypeLineStrip if we want to batch the subsequent draw calls as it draws an unwanted line between previous rectangle and current rectangle.

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

PR: https://git.openjdk.org/jdk/pull/9245


From psadhukhan at openjdk.org  Wed Jul 13 05:24:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 05:24:44 GMT
Subject: Integrated: 8290162: Reset recursion counter missed in fix of
 JDK-8224267
In-Reply-To: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
References: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
Message-ID: <KCzgjPmmByb1qA-N5kkjFmATRYqWICl_AkkgqRDhQSw=.a778a291-ae9b-42ee-80db-f71815ad128f@github.com>

On Tue, 12 Jul 2022 09:44:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `recursionCount` counter added in fix of JDK-8224267 is only reset when limit is reached,  so it will behave incorrectly if JOptionPane.showMessageDialog continuously with the same message having newlines, so it needs to be reset also at appropriate location. 
> Fix to reset the counter before the recursive method is called.
> 
> Also, fix added to indicate the original message is truncated by adding ... (ellipsis) to the previous line of text if it recurses more than limit set.

This pull request has now been integrated.

Changeset: 6e18883d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e18883d8ffd9a7b7d495da05e9859dc1d1a2677
Stats:     5 lines in 2 files changed: 4 ins; 0 del; 1 mod

8290162: Reset recursion counter missed in fix of JDK-8224267

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9464


From duke at openjdk.org  Wed Jul 13 06:28:18 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 06:28:18 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  alignment, newline and bytes handling fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/b1006c66..8f6c9fef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=02-03

  Stats: 16 lines in 3 files changed: 5 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 13 06:28:19 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 06:28:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v3]
In-Reply-To: <BHFQZ4Hkpm15o80fTfdnJRZKRp_JgFXtz9ba9haKXb8=.8fd52e4b-a2d6-4f71-8a13-bb7d9b9f3c3b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <xpAcqYqoA0IwMkIx-n0uA_DFaqsfsB56Omka6cZmfiw=.3fbcef9c-908e-481b-9b47-23651eb3d25d@github.com>
 <gf-GNzxW6sd5S6H1-_R1k6j2J--39Ygn2jtnvNYiglw=.dabe8412-5dbf-49c9-ac5a-602a6155b972@github.com>
 <xVzOYTbJcQrPHvz4xeQtgQ_grsLEfSSIeFxNDeRJvL0=.8b5deb58-e463-4e4a-bbaf-f160d710e4fc@github.com>
 <V4y68IxgKxghRWTbxGsI_I4IYTFef0cQX4tIgeguMuA=.0f09e788-eda3-411d-babe-2c03cef579d4@github.com>
 <R0_x6juu-UcjRoTL7RhdR55jfyuCgtGDsNQeb3vLWgM=.1af595d6-a6d8-4264-a032-ea4b775e4357@github.com>
 <eNy3Yot-KISKveaUuRp9scA1-zhlapS4i1phfhRLpR0=.13150562-8316-42ef-aaa3-3d7c5ac8fb7f@github.com>
 <ljZ1Wm6gU9RTUero-c1_3lcc2rrnhAGu3fumUFlCkXA=.388668ef-8cc1-4a2c-8672-33680e2a1a4e@github.com>
 <BHFQZ4Hkpm15o80fTfdnJRZKRp_JgFXtz9ba9haKXb8=.8fd52e4b-a2d6-4f71-8a13-bb7d9b9f3c3b@github.com>
Message-ID: <Ib4uxEWzBcTDsuNLaQBKn7OhivsSXT_hNLHNrdT3GAc=.2a4a98f6-32f9-47a9-88d3-7ba174561cb4@github.com>

On Fri, 8 Jul 2022 16:01:13 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>>> Shall we handle "1 byte"?
>> 
>> "1 byte" is not handled separately. In that case, should I replace "0 bytes" with "{0} B" ?
>
> Please refer to MessageFormat javadoc:
> 
> `For more sophisticated patterns, you can use a ChoiceFormat to produce correct forms for singular and plural:
> 
>  MessageFormat form = new MessageFormat("The disk "{1}" contains {0}.");
>  double[] filelimits = {0,1,2};
>  String[] filepart = {"no files","one file","{0,number} files"};
>  ChoiceFormat fileform = new ChoiceFormat(filelimits, filepart);
>  form.setFormatByArgumentIndex(0, fileform);
> 
>  int fileCount = 1273;
>  String diskName = "MyDisk";
>  Object[] testArgs = {new Long(fileCount), diskName};
> 
>  System.out.println(form.format(testArgs));
>  
> The output with different values for fileCount:
>  The disk "MyDisk" contains no files.
>  The disk "MyDisk" contains one file.
>  The disk "MyDisk" contains 1,273 files.`

bytes replace by "B" to handle plural forms as suggested.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul 13 06:28:19 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 06:28:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
Message-ID: <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>

On Wed, 13 Jul 2022 06:20:06 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alignment, newline and bytes handling fix

src/java.desktop/share/classes/sun/swing/FilePane.java line 1203:

> 1201:                     }
> 1202:                 } else if (len < 1024L) {
> 1203:                     text = MessageFormat.format(byteString, len);

For len < 1024 say 433, does it now show 433 bytes or 433 B? 
Since in resource file, you are using {0} B and not {0} bytes..I guess in ubuntu native, it shows 433 bytes and not 433 B..

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 13 06:28:19 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 06:28:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
Message-ID: <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>

On Wed, 13 Jul 2022 05:20:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   alignment, newline and bytes handling fix
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1203:
> 
>> 1201:                     }
>> 1202:                 } else if (len < 1024L) {
>> 1203:                     text = MessageFormat.format(byteString, len);
> 
> For len < 1024 say 433, does it now show 433 bytes or 433 B? 
> Since in resource file, you are using {0} B and not {0} bytes..I guess in ubuntu native, it shows 433 bytes and not 433 B..

It will show 433 B now, in ubuntu native it shows 433 bytes. 
bytes replaced by B to handle plural forms, otherwise for 1 byte file it show 1 bytes.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul 13 07:04:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 07:04:49 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
Message-ID: <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>

On Wed, 13 Jul 2022 06:01:39 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1203:
>> 
>>> 1201:                     }
>>> 1202:                 } else if (len < 1024L) {
>>> 1203:                     text = MessageFormat.format(byteString, len);
>> 
>> For len < 1024 say 433, does it now show 433 bytes or 433 B? 
>> Since in resource file, you are using {0} B and not {0} bytes..I guess in ubuntu native, it shows 433 bytes and not 433 B..
>
> It will show 433 B now, in ubuntu native it shows 433 bytes. 
> bytes replaced by B to handle plural forms, otherwise for 1 byte file it show 1 bytes.

i guess it's not right then, no? if you are changing to mimic native, then it should be "bytes" and not "B". Just for 1 byte case, you cannot compromise on other file size(s), in my opinion.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 13 07:17:47 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 07:17:47 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
Message-ID: <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>

On Wed, 13 Jul 2022 06:51:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It will show 433 B now, in ubuntu native it shows 433 bytes. 
>> bytes replaced by B to handle plural forms, otherwise for 1 byte file it show 1 bytes.
>
> i guess it's not right then, no? if you are changing to mimic native, then it should be "bytes" and not "B". Just for 1 byte case, you cannot compromise on other file size(s), in my opinion.
> Also, what's the likelihood of having 1 byte file, I guess it's very rare. If you type a character, it will be shown as 2 bytes.

In that case to handle 1 byte, do i need to add separate property in properties file?
If filesize=1 then can get "byte" string from properties file and can format using MessageFormat?

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul 13 07:17:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 07:17:48 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
Message-ID: <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>

On Wed, 13 Jul 2022 07:11:16 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> i guess it's not right then, no? if you are changing to mimic native, then it should be "bytes" and not "B". Just for 1 byte case, you cannot compromise on other file size(s), in my opinion.
>> Also, what's the likelihood of having 1 byte file, I guess it's very rare. If you type a character, it will be shown as 2 bytes.
>
> In that case to handle 1 byte, do i need to add separate property in properties file?
> If filesize=1 then can get "byte" string from properties file and can format using MessageFormat?

am not sure if resource file can support {1} byte case...if that is supported, then you can use that...but likelihood of 1 byte file is very rare so I guess we can ignore it, that's my opinion.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 13 07:25:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 07:25:32 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v6]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <p9ePxs1myIgvK6VHUg-rlNWJ6ho0xE7JEsJPF5bpCuk=.6917f1d9-3b10-42f6-9926-6cf4d4a53d08@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  JLabel and AbstractButton imageUpdate method description modified

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/106800b8..a6693011

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=04-05

  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Wed Jul 13 07:25:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 07:25:32 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <UCxQjzMf2mJjQ2LQvVTAukg8Jb3fHs5atTRkJhbEIug=.fcb7bdd9-8660-4284-be52-853ffa71b65d@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
 <UCxQjzMf2mJjQ2LQvVTAukg8Jb3fHs5atTRkJhbEIug=.fcb7bdd9-8660-4284-be52-853ffa71b65d@github.com>
Message-ID: <lWFNduOhWT_IF51Kz6za4hOu8PZXV-fjkPr51Oa2IAE=.4aeb3c59-8015-43ad-8fb9-d1a5c343b90e@github.com>

On Tue, 12 Jul 2022 22:26:22 GMT, Phil Race <prr at openjdk.org> wrote:

> Will there be an update to reflect the text discussed above ?

I have Updated the imageUpdate method description.

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

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Wed Jul 13 07:30:55 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 13 Jul 2022 07:30:55 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
Message-ID: <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>

On Wed, 13 Jul 2022 07:14:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In that case to handle 1 byte, do i need to add separate property in properties file?
>> If filesize=1 then can get "byte" string from properties file and can format using MessageFormat?
>
> am not sure if resource file can support {1} byte case...if that is supported, then you can use that...but likelihood of 1 byte file is very rare so I guess we can ignore it, that's my opinion.

ok, should I revert back "B" to "bytes" in basic.properties and commit?

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

PR: https://git.openjdk.org/jdk/pull/9327


From serb at openjdk.org  Wed Jul 13 09:07:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Jul 2022 09:07:42 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
 <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
Message-ID: <jq09J-6HysZ6y3wI_-WXu-9fI42WTgFK9iN5O7IpLxI=.8e4f2e51-daa3-449a-8ec3-d010a0b5787f@github.com>

On Mon, 11 Jul 2022 10:01:18 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> will be executed on the disposer thread simultaneously with the array relocation of `deferredRecords`. So some of the `get()` calls will return `null` as they read from initialized, but yet-to-be-relocated chunks, and some will read what essentially is garbage.

Don't we have a similar issue in the usage of `records `and `queue`? Is it possible that the `target` object in the `add `method will be deallocated before `ref `will be added to the `records`? In that case, the next code in `run` method will fail:

    Reference<?> obj = queue.remove();
    obj.clear();
    DisposerRecord rec = records.remove(obj);
    rec.dispose();

Do we need Reference.reachabilityFence at the end of the `add` or some kind of synchronization?

Note that pollRemove tries to solve that:

    DisposerRecord rec = records.remove(obj);
    if (rec == null) { // shouldn't happen, but just in case.
         continue;
    }

But for sure synchronization should solve that in some better way.

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

PR: https://git.openjdk.org/jdk/pull/9362


From serb at openjdk.org  Wed Jul 13 09:23:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Jul 2022 09:23:51 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v2]
In-Reply-To: <GwgGqD1iPvZxX6kY-f67hXy7QG0_m70_UIblwP8mZSo=.ef25373d-122c-4c0e-8538-58be6ee5a57e@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <GwgGqD1iPvZxX6kY-f67hXy7QG0_m70_UIblwP8mZSo=.ef25373d-122c-4c0e-8538-58be6ee5a57e@github.com>
Message-ID: <fYwUiuImIV2dCW2XTmEQ2jZB_QeZFjbxGNiEp6K1fik=.eebea9ba-81d7-4a43-8630-8413ab0b23b6@github.com>

On Fri, 8 Jul 2022 22:42:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
>> 
>> The test is passing on all platforms after this change.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright dates, removed debug print statements

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 413:

> 411:             if (tmpIcon == null) {
> 412:                 if (icon instanceof ImageIcon) {
> 413:                     tmpIcon = new ImageIcon(AquaUtils.generateSelectedDarkImage(((ImageIcon)icon).getImage()));

Any other reason to remove the usage of grayimage as the pressedIcon other than this failed test? Probably it is better to set the pressedIcon in the test?

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

PR: https://git.openjdk.org/jdk/pull/9436


From serb at openjdk.org  Wed Jul 13 09:27:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Jul 2022 09:27:56 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <3cKJYyJLilecrInoYuBVb0woZs_ux7s_TmAc-9W4w_E=.1e93d942-fcc1-47ac-b09c-d3642e3375b6@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
 <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
 <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>
 <9zCJcmOcfXZtR31WIXTeHGbOpkGsNRHe6yE9_m9sJ1k=.3cd48e19-de98-4c54-a934-dfc4ad738bce@github.com>
 <cixG0t-Sn0Trw4NnDTAo65bamSHT-ZO1An28pnU_dW0=.3cfcf288-aeb1-41b9-b9df-081f200492f3@github.com>
 <3cKJYyJLilecrInoYuBVb0woZs_ux7s_TmAc-9W4w_E=.1e93d942-fcc1-47ac-b09c-d3642e3375b6@github.com>
Message-ID: <g4S8Bzc3yC8rc95fmiwLzlEZpBFoQtJlMy8a7V8qhOw=.bf71a59b-c238-4864-9203-ed5a2ad53e39@github.com>

On Fri, 8 Jul 2022 15:59:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This sounds reasonable? until you take into account the fact the `Icon` or `ImageIcon` has no reference to a component. When the icon is requested, the scale at which will be rendered is unknown.

Correct.

> When an icon is rendered and the required variant does not exist in the MRI, there's no way to fetch it asynchronously: the icon can't make the component repaint because there's no reference to the component.

The drawImage method takes the observer, which can be used to trigger repaint when the new image is reloaded, this is how the animated gifs are rendered in our components.

> The only optimisation that I see is to request only the size which correspond to the current monitor scales. If a different size is needed, a synchronous call to COM thread is required; and for this the icon must keep the path to the file.

You missed the point that the goal of that fix was to provide the icons for the file(eventually be a kind of wrapper for "Extract"), the possibility to render them in HiDPI is a side effect. So we should be able to do both:
 * If the user request the list of variants we should provide the list of icons we are able to load from the file, but the API is flaky to get the actual list of 
 * If the Icon is rendered to the image we may load the icon of the different DPI.

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

PR: https://git.openjdk.org/jdk/pull/7805


From serb at openjdk.org  Wed Jul 13 09:37:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Jul 2022 09:37:56 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
 <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
 <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>
Message-ID: <cE7M9DiJpu9GU4mpC5MEnauX4K115odtvvNLtyYmi9s=.2810fcd2-1594-4edf-b9cb-b69bf66c78f2@github.com>

On Wed, 13 Jul 2022 03:53:28 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> We cannot use MTLPrimitiveTypeLineStrip if we want to batch the subsequent draw calls as it draws an unwanted line between previous rectangle and current rectangle.

Even if the alpha will be transparent? Just curious.

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

PR: https://git.openjdk.org/jdk/pull/9245


From serb at openjdk.org  Wed Jul 13 09:46:44 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Jul 2022 09:46:44 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
Message-ID: <yolzmDTAQLjCskbSoYdaqUff9j5_KQKtFURB55i1SlI=.a35797e5-df23-4d05-b63e-278928371b5c@github.com>

On Wed, 29 Jun 2022 06:53:29 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Reverted variable name change, reverted +20 in point

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9187


From psadhukhan at openjdk.org  Wed Jul 13 11:35:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 11:35:22 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
Message-ID: <OdtSt2-1jrZPq87DVzLpgpOg60rF49B4t6Yzs8aGmBc=.9b5b57e4-8741-4868-9c7f-be8f1e70d08e@github.com>

On Tue, 12 Jul 2022 22:56:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen 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 six additional commits since the last revision:
> 
>  - Updated method names for PassFailJFrame
>  - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
>  - Removed commented lines. Added newlines.
>  - Updated test with PassFailJFrame
>  - Added test
>  - Adjusted height and coordinate for editable JComboBox

Can you please show before and after fix image of the editable combobox?
It seems the border around the button makes it feel it's still not aligned properly which gives the impression that the button is bigger than textfield. Probably we can do away with the button border, if we can, in case we cannot draw the border around the whole textfield+button.

Also, I think if you try with different font size e.g.
`comboBox.setFont(new Font("Serif", Font.PLAIN, 30));`

you will again see the editable combobox button height is not matching textfield height whereas non editable one it is aligned..

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

PR: https://git.openjdk.org/jdk/pull/9473


From mkartashev at openjdk.org  Wed Jul 13 11:51:00 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 13 Jul 2022 11:51:00 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <jq09J-6HysZ6y3wI_-WXu-9fI42WTgFK9iN5O7IpLxI=.8e4f2e51-daa3-449a-8ec3-d010a0b5787f@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
 <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
 <jq09J-6HysZ6y3wI_-WXu-9fI42WTgFK9iN5O7IpLxI=.8e4f2e51-daa3-449a-8ec3-d010a0b5787f@github.com>
Message-ID: <3hQTtUHT-oLQh7kSPbqIlPDSy9gb6pPX67B4EtqwIXs=.61f42bf7-ab46-45c2-a7a9-90b90c8122b3@github.com>

On Wed, 13 Jul 2022 08:58:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Don't we have a similar issue in the usage of records and queue? Is it possible that the target object in the add method will be deallocated before ref will be added to the records? 

Yes, I believe it can be deallocated before the reference to it is added to `records`.

> In that case, the next code in run method will fail:

    Reference<?> obj = queue.remove();
    obj.clear();
    DisposerRecord rec = records.remove(obj);
    rec.dispose();


Of this I am not so sure. When `target` object is deallocated in the middle of `add()`, then `ref.get()` (`Reference.get()`) returns `null`, but the above code doesn't do that. Neither does the `add()` method; `records` are indexed by the `Reference` object, not - by now deallocated - referent of that reference:

java.lang.ref.Reference<Object> ref;
...
records.put(ref, rec);

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

PR: https://git.openjdk.org/jdk/pull/9362


From psadhukhan at openjdk.org  Wed Jul 13 11:58:05 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 11:58:05 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <9ZJ9OPQ1u8YCk5gFyqosAx9FHfNrTMumA09YTgb7CB0=.5b55e5cd-55e7-4df2-bee0-8d5cf3669c8c@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <k4zzYyfh9bKgY8vRD7v2xnv1c3QZdeHlXAUKMcDGFp8=.70a33723-e3ef-4360-b497-9e248adc7079@github.com>
 <dkA_iizvGKJWFa8ldpjqOkbAt12Y6caSKy9_WQ4pleM=.f38bd067-3903-49a4-b2f9-ed03655ea98f@github.com>
 <9ZJ9OPQ1u8YCk5gFyqosAx9FHfNrTMumA09YTgb7CB0=.5b55e5cd-55e7-4df2-bee0-8d5cf3669c8c@github.com>
Message-ID: <PPJu8qSB4ih0G_hodg636YW9E3_Mh2pjyNkljYXHNvY=.84eb80d3-7c06-4b60-90b5-cdc900a0bc10@github.com>

On Tue, 12 Jul 2022 19:31:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Even if JavaFX, Left and Right Option key is mapped to ALT so I guess we will be consistent with that too.
>
>> > One macOS you will not see the "Alt" key as well, but we use that name.
>> 
>> At least I can see 
> 
> Just a clarification:
> 
> On the new keyboards, it does not have it, I have two laptops where the "alt" label is missing:
> ![mac-keyboard-alt](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/social/keyboards-social-card.jpg)
> 
> The official document about the keyboard [mentions ](https://support.apple.com/en-us/HT201236) the "alt" key in case the windows keyboard is used: `"On keyboards made for Windows PCs, use the Alt key instead of Option, and the Windows logo key instead of Command."`
> 
> So I do not see a reason why the "right option" - "alt gr" key on the PC keyboard cannot be mapped to the ALT_GRAPH, same as "left option" - "alt" is mapped to the ALT.

The document mentioned "use the Alt key", which is what both Option keys are mapped to now. I dont see anywhere it is mentioned to use "AltGraph" key, so I dont see the need of mapping Right Option to Alt Graph....I dont see any native app where Right Option is being used as "AltGraph"..
As I mentioned, even FX maps both keys to Alt...

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

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Wed Jul 13 13:01:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 13 Jul 2022 13:01:24 GMT
Subject: RFR: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS
Message-ID: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>

It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
Fixed to get the default selected icon and use that if in case the icon for that state is not set.

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

Commit messages:
 - Fix showig proper icon

Changes: https://git.openjdk.org/jdk/pull/9481/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7132413
  Stats: 19 lines in 1 file changed: 17 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9481.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9481/head:pull/9481

PR: https://git.openjdk.org/jdk/pull/9481


From duke at openjdk.org  Wed Jul 13 15:11:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 15:11:25 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

?????? ??????? 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 six additional commits since the last revision:

 - 8289908: Rework constructor
 - Merge branch 'master' into 8289908
 - 8289908: Fixed tests
 - Merge branch 'master' into 8289908
 - 8289908: Make constructor private and use trailing Void instead of int
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/b7375cd3..f653a67b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02-03

  Stats: 62100 lines in 564 files changed: 33281 ins; 20833 del; 7986 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Wed Jul 13 15:11:26 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 15:11:26 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <T6IkvLl16MCSqESKmPcKlaKWGtAF4wq4w4Ds_BCh8BI=.c7517f48-3868-4b81-aa49-bac37884a3a8@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
 <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
 <mS162Cy-DL-dLLgL4ZtZ3hXudpcpWZPoDoiq99f8IAw=.ba25b054-953d-4878-a258-24f7146830aa@github.com>
 <T6IkvLl16MCSqESKmPcKlaKWGtAF4wq4w4Ds_BCh8BI=.c7517f48-3868-4b81-aa49-bac37884a3a8@github.com>
Message-ID: <ylv_SbISGQ36yLy5VMpDarMACBMEuoWyMYpQW8gV8vA=.71c7ee41-3938-4c73-8619-9e144401cb6f@github.com>

On Tue, 12 Jul 2022 15:57:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Benchmark results after:
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,354 ? 0,195  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,035 ? 0,088  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,166 ? 0,062  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,132 ? 0,054  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,416 ? 0,206  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,421 ? 0,041  ns/op
>
> Matching the existing Void argument looks better.
> The new private method should have a comment saying that it does not do any precondition checks on the arguments.
> 
> (Reordering the arguments is an alternative to adding an argument, for example, (Charset, byte[], int, int).
> But it is less readable and can raise questions due to the different order of arguments.)

Updated PR. With newer version I get these results:

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,831 ? 0,205  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  3,940 ? 0,008  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  7,662 ? 0,112  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,175 ? 0,065  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  3,970 ? 0,037  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,480 ? 0,014  ns/op

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

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Wed Jul 13 15:27:07 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Wed, 13 Jul 2022 15:27:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
Message-ID: <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>

On Wed, 13 Jul 2022 07:22:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> am not sure if resource file can support {1} byte case...if that is supported, then you can use that...but likelihood of 1 byte file is very rare so I guess we can ignore it, that's my opinion.
>
> ok, should I revert back "B" to "bytes" in basic.properties and commit?

I would like to emphasize that this issue is complicated.  Plural rules vary from language to language, adding plural strings to resource bundles adds costs in terms of translation and testing.  

If we were to support proper plurals, one may use ChoiceFormat, though it seems to fail for Polish, see
https://stuartgunter.wordpress.com/2011/08/09/java-i18n-pluralisation-using-choiceformat/

Another solution is to pull in ICU4J library, see
https://stuartgunter.wordpress.com/2011/08/14/even-better-java-i18n-pluralisation-using-icu4j/

Yet another solution is to drop the words altogether and simply show a number (of bytes in this case).  Alternatively, use a common suffix such as "B", but this may not look standard.

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

PR: https://git.openjdk.org/jdk/pull/9327


From rriggs at openjdk.org  Wed Jul 13 15:47:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Jul 2022 15:47:12 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
Message-ID: <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>

On Wed, 13 Jul 2022 15:11:25 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? 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 six additional commits since the last revision:
> 
>  - 8289908: Rework constructor
>  - Merge branch 'master' into 8289908
>  - 8289908: Fixed tests
>  - Merge branch 'master' into 8289908
>  - 8289908: Make constructor private and use trailing Void instead of int
>  - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Looks good, thanks for the updates.

src/java.base/share/classes/java/lang/String.java line 528:

> 526:      * <p>
> 527:      * Important: parameter order of this method is deliberately changed in order to
> 528:      * disambiguate it against other similar methods ot this class.

typo?  "ot this".

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9407


From naoto at openjdk.org  Wed Jul 13 16:58:11 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Jul 2022 16:58:11 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
Message-ID: <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>

On Wed, 13 Jul 2022 15:23:28 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> ok, should I revert back "B" to "bytes" in basic.properties and commit?
>
> I would like to emphasize that this issue is complicated.  Plural rules vary from language to language, adding plural strings to resource bundles adds costs in terms of translation and testing.  
> 
> If we were to support proper plurals, one may use ChoiceFormat, though it seems to fail for Polish, see
> https://stuartgunter.wordpress.com/2011/08/09/java-i18n-pluralisation-using-choiceformat/
> 
> Another solution is to pull in ICU4J library, see
> https://stuartgunter.wordpress.com/2011/08/14/even-better-java-i18n-pluralisation-using-icu4j/
> 
> Yet another solution is to drop the words altogether and simply show a number (of bytes in this case).  Alternatively, use a common suffix such as "B", but this may not look standard.

True plurals (as in LDML) is not yet fully supported in the JDK. (`CompactNumberFormat` does for its own purpose (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is only localized in a handful of languages.

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

PR: https://git.openjdk.org/jdk/pull/9327


From aghaisas at openjdk.org  Wed Jul 13 16:58:12 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 13 Jul 2022 16:58:12 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <cE7M9DiJpu9GU4mpC5MEnauX4K115odtvvNLtyYmi9s=.2810fcd2-1594-4edf-b9cb-b69bf66c78f2@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
 <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
 <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>
 <cE7M9DiJpu9GU4mpC5MEnauX4K115odtvvNLtyYmi9s=.2810fcd2-1594-4edf-b9cb-b69bf66c78f2@github.com>
Message-ID: <695OWraXDsbYDLuLA85FEi6U_R3jXNxCQPHZpXmtqqI=.ed7a6020-23dc-44f0-94cf-109dde932d07@github.com>

On Wed, 13 Jul 2022 09:25:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Earlier logic used to draw a rectangle with MTLPrimitiveTypeLineStrip. Hence, 5 vertices were specified to  draw 4 sides of the rectangle.
>> Now, the logic has been changed to use MTLPrimitiveTypeLine. Hence, 4 lines need to be specified separately by specifying 8 vertices. There are duplicates since the lines are connected.
>> 
>> We cannot use MTLPrimitiveTypeLineStrip if we want to batch the subsequent draw calls as it draws an unwanted line between previous rectangle and current rectangle.
>
>> We cannot use MTLPrimitiveTypeLineStrip if we want to batch the subsequent draw calls as it draws an unwanted line between previous rectangle and current rectangle.
> 
> Even if the alpha will be transparent? Just curious.

Yes, there will be a transparent line between previous rectangle and current rectangle.
This PR introduces batching of vertices of successive draw calls of the same primitive. If we keep on adding vertices to a common buffer and finally encode draw operation using MTLPrimitiveTypeLineStrip, all those vertices will be connected. If color is changed in between these successive draw calls, we end the current vertex batch and start a new one.

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

PR: https://git.openjdk.org/jdk/pull/9245


From duke at openjdk.org  Wed Jul 13 17:42:18 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 17:42:18 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v5]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:

 - 8289908: Fix typo
 - 8289908: Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/f653a67b..72146f7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Wed Jul 13 17:42:23 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 17:42:23 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
 <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>
Message-ID: <cn9daN0Chjd9H6T25qdokpLduOZ9evfMjlLpKahhfi8=.a7eedd74-0ab4-4e9b-bf7d-94140e5ee64c@github.com>

On Wed, 13 Jul 2022 15:44:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ?????? ??????? 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 six additional commits since the last revision:
>> 
>>  - 8289908: Rework constructor
>>  - Merge branch 'master' into 8289908
>>  - 8289908: Fixed tests
>>  - Merge branch 'master' into 8289908
>>  - 8289908: Make constructor private and use trailing Void instead of int
>>  - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]
>
> src/java.base/share/classes/java/lang/String.java line 528:
> 
>> 526:      * <p>
>> 527:      * Important: parameter order of this method is deliberately changed in order to
>> 528:      * disambiguate it against other similar methods ot this class.
> 
> typo?  "ot this".

Changed to "of this"

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

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Wed Jul 13 19:54:07 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Wed, 13 Jul 2022 19:54:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
Message-ID: <k6UCNtkHiMXGQzG8TWwQxqu9UkvqF1J_pZUPbeWWaqg=.ae4a66d8-7694-44d1-b6d5-c83fc5b44976@github.com>

On Wed, 13 Jul 2022 16:54:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I would like to emphasize that this issue is complicated.  Plural rules vary from language to language, adding plural strings to resource bundles adds costs in terms of translation and testing.  
>> 
>> If we were to support proper plurals, one may use ChoiceFormat, though it seems to fail for Polish, see
>> https://stuartgunter.wordpress.com/2011/08/09/java-i18n-pluralisation-using-choiceformat/
>> 
>> Another solution is to pull in ICU4J library, see
>> https://stuartgunter.wordpress.com/2011/08/14/even-better-java-i18n-pluralisation-using-icu4j/
>> 
>> Yet another solution is to drop the words altogether and simply show a number (of bytes in this case).  Alternatively, use a common suffix such as "B", but this may not look standard.
>
> True plurals (as in LDML) is not yet fully supported in the JDK. (`CompactNumberFormat` does for its own purpose (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is only localized in a handful of languages.

another suggestion: to avoid locale-dependent complexity simply show the number of bytes as a number if length < 1000.  this will also avoid involving the group separator - as far as I know, no language on earth uses group separator for numbers in the range 0...999

0 - "0"
1 - "1"
999 - "999"
1000 - "1 KB"
etc.

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

PR: https://git.openjdk.org/jdk/pull/9327


From dnguyen at openjdk.org  Wed Jul 13 22:33:01 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Jul 2022 22:33:01 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <OdtSt2-1jrZPq87DVzLpgpOg60rF49B4t6Yzs8aGmBc=.9b5b57e4-8741-4868-9c7f-be8f1e70d08e@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
 <OdtSt2-1jrZPq87DVzLpgpOg60rF49B4t6Yzs8aGmBc=.9b5b57e4-8741-4868-9c7f-be8f1e70d08e@github.com>
Message-ID: <-vj2ziUqpHXdlyPTS6oI8e9h-KYlMz60JVzm63Zg9XY=.64baec2f-98f1-4213-aaab-e5f39a8ed2b7@github.com>

On Wed, 13 Jul 2022 11:31:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Can you please show before and after fix image of the editable combobox? It seems the border around the button makes it feel it's still not aligned properly which gives the impression that the button is bigger than textfield. Probably we can do away with the button border, if we can, in case we cannot draw the border around the whole textfield+button.
> 
> Also, I think if you try with different font size e.g. `comboBox.setFont(new Font("Serif", Font.PLAIN, 30));`
> 
> you will again see the editable combobox button height is not matching textfield height whereas non editable one it is aligned..

Local test without the fix:
<img width="182" alt="Local Test Without Fix" src="https://user-images.githubusercontent.com/96267980/178778291-805ed3e0-fed2-458d-9ae6-65ace37f8ef0.png">

Local test with the fix:
<img width="182" alt="Local Test With Alignment Fix" src="https://user-images.githubusercontent.com/96267980/178778425-5a8bf95a-014f-46dd-a018-29fd37b2fe39.png">

I have additional images on JBS, but I'll gladly post them here as well.

I'm looking into the text size and the borders. The sizing of the button seems to also be affected by a component size value, so I'm adjusting that instead.

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

PR: https://git.openjdk.org/jdk/pull/9473


From prr at openjdk.org  Wed Jul 13 22:42:57 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 13 Jul 2022 22:42:57 GMT
Subject: RFR: 8288067: Avoid redundant HashMap.containsKey call in
 Type1Font.expandAbbreviation
In-Reply-To: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
References: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
Message-ID: <9dZzI1IEQ-8rwz-k_kH8gk1nCjGjHMY50nmVF708phc=.3932bc68-3f84-4dbd-b23b-188a8905c6d2@github.com>

On Wed, 8 Jun 2022 17:50:35 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair HashMap.containsKey/HashMap.get method calls, we can use single call HashMap.getOrDefault.
> It's faster and clearer.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9089


From duke at openjdk.org  Wed Jul 13 22:46:02 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 13 Jul 2022 22:46:02 GMT
Subject: Integrated: 8289559 : java/awt/a11y/AccessibleJPopupMenuTest.java test
 fails with java.lang.NullPointerException
In-Reply-To: <T8v6uKdETvAFpSal_DGp_wY-J4B4Z4Eapv1DZDb_l1g=.afa91286-550e-4bb3-ab0f-354944745445@github.com>
References: <T8v6uKdETvAFpSal_DGp_wY-J4B4Z4Eapv1DZDb_l1g=.afa91286-550e-4bb3-ab0f-354944745445@github.com>
Message-ID: <46CfGj17eXurmOO4YXcmvr4fZ_poHOa7ffyPPdguo8g=.560ed4da-e8aa-46d6-aca2-aba9818d3089@github.com>

On Thu, 30 Jun 2022 23:58:44 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Fixed the java.lang.NullPointerException & tested .
> 
> @shurymury

This pull request has now been integrated.

Changeset: 3216d198
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3216d198f382e991522600086bb2691abfe5f067
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8289559: java/awt/a11y/AccessibleJPopupMenuTest.java test fails with java.lang.NullPointerException

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/9342


From prr at openjdk.org  Wed Jul 13 22:46:05 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 13 Jul 2022 22:46:05 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v2]
In-Reply-To: <WCiy57nOodJhH-1aNUct94zbegmBZSynDpG5MEwXrAM=.d50f8f5f-139b-4920-895a-b6f8bd21d798@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <z_rpYBkzYXqoADN_9FtplgRRB9xLW59DC1iGI_DFckM=.b9bde1a3-d5af-4e70-a75d-7ba020ea4c06@github.com>
 <WCiy57nOodJhH-1aNUct94zbegmBZSynDpG5MEwXrAM=.d50f8f5f-139b-4920-895a-b6f8bd21d798@github.com>
Message-ID: <8bf_u5pkziAA3SuCB7G8TpQYt8uzmKeiWZ1St1BiRKg=.b25497fb-16e9-44db-b840-52a4702b66b1@github.com>

On Fri, 20 May 2022 00:49:23 GMT, SWinxy <duke at openjdk.org> wrote:

>> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove @author tags per request
>
> I did an automated test to see if those were the only other things wrong. Those were the only things that were wrong.

Hello @SWinxy this PR needs some attention

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

PR: https://git.openjdk.org/jdk/pull/7096


From prr at openjdk.org  Wed Jul 13 23:15:12 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 13 Jul 2022 23:15:12 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v7]
In-Reply-To: <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>
Message-ID: <EyGk-lOSxBgTvAv7NUyGQS1erYJWYmBMUMYfvWI9lmo=.4cbec960-5bf0-4ff8-b7a4-0e6caf26815d@github.com>

On Wed, 6 Jul 2022 18:17:41 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test case so it creates the new file instead of having it in
>   the test folder. Verified on automatic run.

Marked as reviewed by prr (Reviewer).

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1440:

> 1438:                 }
> 1439:             }
> 1440:             if (retVal.getWidth(null) != w) {

It isn't in this webrev but i jyst noticed
            // We only care about width since we don't support non-rectangular icons
I think that meant non-square ???

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

PR: https://git.openjdk.org/jdk/pull/7805


From duke at openjdk.org  Thu Jul 14 00:14:08 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 14 Jul 2022 00:14:08 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v3]
In-Reply-To: <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
Message-ID: <6k1kvatqCVREfUipj6avEB59212SjLdyrl1UXTGlivE=.2c7ae47f-de0f-4f49-879f-d7f0822a80c2@github.com>

On Fri, 20 May 2022 00:53:27 GMT, SWinxy <duke at openjdk.org> wrote:

>> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accidental mergers.
>   
>   I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different.

I've hesitated asking for help, but the builds aren't working and I can't tell *why*.

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

PR: https://git.openjdk.org/jdk/pull/7096


From prr at openjdk.org  Thu Jul 14 00:26:09 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Jul 2022 00:26:09 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v3]
In-Reply-To: <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
Message-ID: <V6RoNZPdnNwYozir7d5QDWKTFJzi4DiT99BiWuaKWqM=.a8263eaa-5636-41ec-a784-45e93050307e@github.com>

On Fri, 20 May 2022 00:53:27 GMT, SWinxy <duke at openjdk.org> wrote:

>> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accidental mergers.
>   
>   I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different.

> I've hesitated asking for help, but the builds aren't working and I can't tell _why_.

the GHA builds are passing so far as I can tell.

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

PR: https://git.openjdk.org/jdk/pull/7096


From jwaters at openjdk.org  Thu Jul 14 02:26:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Jul 2022 02:26:03 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v3]
In-Reply-To: <V6RoNZPdnNwYozir7d5QDWKTFJzi4DiT99BiWuaKWqM=.a8263eaa-5636-41ec-a784-45e93050307e@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
 <V6RoNZPdnNwYozir7d5QDWKTFJzi4DiT99BiWuaKWqM=.a8263eaa-5636-41ec-a784-45e93050307e@github.com>
Message-ID: <tlz15cbAVP4ywhOIJPkbrcKulfHwz-RzPFBze1Ftfww=.ae35057f-dda8-4ed0-abf8-fde2f59fe921@github.com>

On Thu, 14 Jul 2022 00:22:39 GMT, Phil Race <prr at openjdk.org> wrote:

> I've hesitated asking for help, but the builds aren't working and I can't tell _why_.

Don't worry about it, sometimes the tests fail due to issues unrelated to the PR, you can check the tests that failed from within the PR itself

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

PR: https://git.openjdk.org/jdk/pull/7096


From smandalika at openjdk.org  Thu Jul 14 05:05:12 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Thu, 14 Jul 2022 05:05:12 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v4]
In-Reply-To: <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
Message-ID: <RUTghHGHfvcrTZn-wc1i1cnLeUyOQ-gG-jIXG770utw=.17bdd92b-988f-47b0-b3d1-a17e6e7ccd07@github.com>

On Wed, 22 Jun 2022 12:52:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: removed redundant headful tag

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8158


From smandalika at openjdk.org  Thu Jul 14 05:07:08 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Thu, 14 Jul 2022 05:07:08 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <Ex1UdWhskAASqzPTAKOB5xZvVWfy68BlO-pNNdrxLIo=.39a4883c-e0ae-4510-8d81-3e4cbb544def@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Hi! Can someone please sponsor this PR?

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

PR: https://git.openjdk.org/jdk/pull/8546


From smandalika at openjdk.org  Thu Jul 14 05:07:12 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Thu, 14 Jul 2022 05:07:12 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v4]
In-Reply-To: <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
Message-ID: <PqshCg6XuBJf3oJm_2DcIcaTGqi0dtRfNonLxBeDhUo=.b55ed7d0-d86e-47ec-8be6-763772c006b9@github.com>

On Wed, 22 Jun 2022 11:42:06 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8284767
>  - Review comment fixed: removed redundant headful tag
>  - Review Comments Fixed: Fixed File location path.
>  - Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
>  - 8284767: Create an automated test for JDK-4422535
>  - 8284767: Create an automated test for JDK-4422535

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8220


From psadhukhan at openjdk.org  Thu Jul 14 05:22:06 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 14 Jul 2022 05:22:06 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
Message-ID: <FgewE8boE3h8kfQFiSkXvPMsMpuMx4xtKsmhaBOBoKA=.ca2b25a6-ffff-48e2-a2dd-761924eba2d7@github.com>

On Tue, 12 Jul 2022 22:56:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen 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 six additional commits since the last revision:
> 
>  - Updated method names for PassFailJFrame
>  - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
>  - Removed commented lines. Added newlines.
>  - Updated test with PassFailJFrame
>  - Added test
>  - Adjusted height and coordinate for editable JComboBox

> > Can you please show before and after fix image of the editable combobox? It seems the border around the button makes it feel it's still not aligned properly which gives the impression that the button is bigger than textfield. Probably we can do away with the button border, if we can, in case we cannot draw the border around the whole textfield+button.
> > Also, I think if you try with different font size e.g. `comboBox.setFont(new Font("Serif", Font.PLAIN, 30));`
> > you will again see the editable combobox button height is not matching textfield height whereas non editable one it is aligned..
> 
> Local test without the fix: <img alt="Local Test Without Fix" width="182" src="https://user-images.githubusercontent.com/96267980/178778291-805ed3e0-fed2-458d-9ae6-65ace37f8ef0.png">
> 
> Local test with the fix: <img alt="Local Test With Alignment Fix" width="182" src="https://user-images.githubusercontent.com/96267980/178778425-5a8bf95a-014f-46dd-a018-29fd37b2fe39.png">
> 
<img width="494" alt="Screenshot 2022-07-14 at 10 41 39 AM" src="https://user-images.githubusercontent.com/43534309/178904319-4e050697-d20c-4606-8434-954e1496c8a5.png">

I am not getting the same uniform blue border around textfield and button as can be seen in my screenshot with your test, which is seen in your image (with fix), so I asked to remove that incomplete blue border.. I am testing on BigSur 11.6..which os version is yours?

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

PR: https://git.openjdk.org/jdk/pull/9473


From kizune at openjdk.org  Thu Jul 14 05:42:08 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 14 Jul 2022 05:42:08 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v7]
In-Reply-To: <EyGk-lOSxBgTvAv7NUyGQS1erYJWYmBMUMYfvWI9lmo=.4cbec960-5bf0-4ff8-b7a4-0e6caf26815d@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <3_dtZkEwYU87KpW_NZeSUVEJK9s8N_ihg9U67cPw7wk=.99da520b-410f-4b88-bdba-72325d87f341@github.com>
 <EyGk-lOSxBgTvAv7NUyGQS1erYJWYmBMUMYfvWI9lmo=.4cbec960-5bf0-4ff8-b7a4-0e6caf26815d@github.com>
Message-ID: <MQgRLxglS2oGuFzwKpi_RtTv11UgNN7-EINynmb39zU=.aa44d5de-d0e4-4dfa-968f-4e2958138737@github.com>

On Wed, 13 Jul 2022 23:12:55 GMT, Phil Race <prr at openjdk.org> wrote:

> It isn't in this webrev but i jyst noticed
> // We only care about width since we don't support non-rectangular icons
> I think that meant non-square ???

Yes. Now it seems to be apparent that English is not my native language...

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

PR: https://git.openjdk.org/jdk/pull/7805


From aturbanov at openjdk.org  Thu Jul 14 06:13:04 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Jul 2022 06:13:04 GMT
Subject: RFR: 8288067: Avoid redundant HashMap.containsKey call in
 Type1Font.expandAbbreviation
In-Reply-To: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
References: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
Message-ID: <LM_lrvtgtNI_l2b0Mqm0MojN6kkMUqT73H_iY6ucv1s=.cfe89046-794f-4c63-af5d-ff4fb687f4f8@github.com>

On Wed, 8 Jun 2022 17:50:35 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair HashMap.containsKey/HashMap.get method calls, we can use single call HashMap.getOrDefault.
> It's faster and clearer.

Thanks for the review!

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

PR: https://git.openjdk.org/jdk/pull/9089


From aturbanov at openjdk.org  Thu Jul 14 06:13:05 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Jul 2022 06:13:05 GMT
Subject: Integrated: 8288067: Avoid redundant HashMap.containsKey call in
 Type1Font.expandAbbreviation
In-Reply-To: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
References: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>
Message-ID: <kL1RVmyeyXRwk0-ppl_9rvDbh5Hk-pEATXqFn9ViWvk=.e8980a33-233e-4243-9442-3a44c6fce47f@github.com>

On Wed, 8 Jun 2022 17:50:35 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair HashMap.containsKey/HashMap.get method calls, we can use single call HashMap.getOrDefault.
> It's faster and clearer.

This pull request has now been integrated.

Changeset: 02fae607
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02fae60740ad6f5d6a2891eac5571155a3ae619c
Stats:     33 lines in 1 file changed: 0 ins; 3 del; 30 mod

8288067: Avoid redundant HashMap.containsKey call in Type1Font.expandAbbreviation

Reviewed-by: attila, prr

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

PR: https://git.openjdk.org/jdk/pull/9089


From psadhukhan at openjdk.org  Thu Jul 14 08:14:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 14 Jul 2022 08:14:27 GMT
Subject: RFR: 8064787: [macosx] In Nimbus LaF, Ctrl+Alt mnemonic doesn't work
Message-ID: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>

In SwingSet2 application, "File" menu has a visible mnemonic set on F.

![image](https://user-images.githubusercontent.com/43534309/178932400-ab70602a-9c4f-4cab-b3b7-0508b26d2ebe.png)

Now, in MacOS, with Aqua, Java (Metal), and Motif LaF, one can open the menu pressing Ctrl+Alt+F. 
But with Nimbus L&F, to open File menu, you have to press Alt+F even on OS X.

It should work with Ctrl+Alt+F as sun/lwawt/macosx/LWCToolkit.java. getFocusAcceleratorKeyMask() 
has CTRL_MASK | ALT_MASK

Fix is to add Menu.shortcutKeys in SynthLookAndFeel default table so that it can call SwingUtilities2.getSystemMnemonicKeyMask() which will call either LWCToolkit.getFocusAcceleratorKeyMask() or SunToolkit.getFocusAcceleratorKeyMask() depending on platform.

No regression test is added as it can be checked with SwingSet2 app.

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

Commit messages:
 - [macosx] In Nimbus LaF, Ctrl+Alt mnemonic doesn't work

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

PR: https://git.openjdk.org/jdk/pull/9488


From aturbanov at openjdk.org  Thu Jul 14 11:51:15 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Jul 2022 11:51:15 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v5]
In-Reply-To: <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>
Message-ID: <EggfXMph6fkkDm743D0_lvGGFIrYih-CV50uqi9Z0Eg=.dc39ff6c-a116-423e-a222-36f098b377ce@github.com>

On Wed, 13 Jul 2022 17:42:18 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8289908: Fix typo
>  - 8289908: Fix typo

Marked as reviewed by aturbanov (Committer).

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

PR: https://git.openjdk.org/jdk/pull/9407


From duke at openjdk.org  Thu Jul 14 11:53:06 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 14 Jul 2022 11:53:06 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v5]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <aONxuNjuWnP4SeBCldnZDGl8D1zjQq1qmWiqP9WcfJY=.3835e002-06b8-4719-95f0-c3ba5cf48e47@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Handling of plural forms using choiceFormat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/8f6c9fef..518c6fd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=03-04

  Stats: 39 lines in 2 files changed: 33 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 14 12:05:03 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 14 Jul 2022 12:05:03 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <k6UCNtkHiMXGQzG8TWwQxqu9UkvqF1J_pZUPbeWWaqg=.ae4a66d8-7694-44d1-b6d5-c83fc5b44976@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
 <k6UCNtkHiMXGQzG8TWwQxqu9UkvqF1J_pZU
 PbeWWaqg=.ae4a66d8-7694-44d1-b6d5-c83fc5b44976@github.com>
Message-ID: <ZULEu0NujILyOZ1eOzvOO8XpuhS-vKEeSBx8ZU0316Q=.5ca95f7a-f1cb-4925-a43c-f2a44db87e28@github.com>

On Wed, 13 Jul 2022 19:52:01 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> True plurals (as in LDML) is not yet fully supported in the JDK. (`CompactNumberFormat` does for its own purpose (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is only localized in a handful of languages.
>
> another suggestion: to avoid locale-dependent complexity simply show the number of bytes as a number if length < 1000.  this will also avoid involving the group separator - as far as I know, no language on earth uses group separator for numbers in the range 0...999
> 
> 0 - "0"
> 1 - "1"
> 999 - "999"
> 1000 - "1 KB"
> etc.

ChoiceFormat has been used now to handle formatting of file size in plural forms. For file size either 0 or more than 1 byte it shows <file length> bytes else 1 byte. 
@naotoj @andy-goryachev-oracle Please check if it is correct.

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

PR: https://git.openjdk.org/jdk/pull/9327


From azvegint at openjdk.org  Thu Jul 14 14:57:04 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 14 Jul 2022 14:57:04 GMT
Subject: RFR: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS
In-Reply-To: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
References: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
Message-ID: <XRZV7lhVgRcS_erL-OzpW02cX-hw9pL-T5R_GXGTIf8=.5eff961a-1249-47a8-bb39-e340d296503d@github.com>

On Wed, 13 Jul 2022 12:49:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
> Fixed to get the default selected icon and use that if in case the icon for that state is not set.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9481


From duke at openjdk.org  Thu Jul 14 15:31:46 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 14 Jul 2022 15:31:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
Message-ID: <xXURocaA6vPArkU45vu0jwEi9HTvqk9SyfaEBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>

On Wed, 13 Jul 2022 16:54:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I would like to emphasize that this issue is complicated.  Plural rules vary from language to language, adding plural strings to resource bundles adds costs in terms of translation and testing.  
>> 
>> If we were to support proper plurals, one may use ChoiceFormat, though it seems to fail for Polish, see
>> https://stuartgunter.wordpress.com/2011/08/09/java-i18n-pluralisation-using-choiceformat/
>> 
>> Another solution is to pull in ICU4J library, see
>> https://stuartgunter.wordpress.com/2011/08/14/even-better-java-i18n-pluralisation-using-icu4j/
>> 
>> Yet another solution is to drop the words altogether and simply show a number (of bytes in this case).  Alternatively, use a common suffix such as "B", but this may not look standard.
>
> True plurals (as in LDML) is not yet fully supported in the JDK. (`CompactNumberFormat` does for its own purpose (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is only localized in a handful of languages.

Upon further consideration, and after discussing the state of plural forms support in JDK with @naotoj I realized that we cannot use ChoiceFormat here at all.  The numeric choices, and their corresponding resource strings are locale-specific, and in some cases simply cannot be coded as a finite array (see Arabic example above).

One possible solution would be to add proper support for plural forms to MessageFormat (which is definitely out of scope for this bug), or perhaps - if showing sizes 0...999 as numbers is not acceptable - to simply fix the 0 bytes case using KB format.  That is,

0 - "0 KB"
1  - "1 KB"
...

(i.e. handle the 0 bytes case separately):

                long len = ((Long) value);

if(len == 0) {
  // shows "0 KB" for 0 bytes
  text = MessageFormat.format(kiloByteString, 0);
} else {
  // retain existing logic
  len /= 1024L;

                if (listViewWindowsStyle) {
                    text = MessageFormat.format(kiloByteString, len + 1);
                } else if (len < 1024L) {
                    text = MessageFormat.format(kiloByteString, (len == 0L) ? 1L : len);
                } else {
                    len /= 1024L;
                    if (len < 1024L) {
                        text = MessageFormat.format(megaByteString, len);
                    } else {
                        len /= 1024L;
                        text = MessageFormat.format(gigaByteString, len);
                    }
                }

and revert the new resource string.

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

PR: https://git.openjdk.org/jdk/pull/9327


From tr at openjdk.org  Thu Jul 14 16:09:33 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 14 Jul 2022 16:09:33 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
Message-ID: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>

JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

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

Commit messages:
 - Updated java document
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c7c20661...fe9a41b8

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

PR: https://git.openjdk.org/jdk/pull/9496


From dnguyen at openjdk.org  Thu Jul 14 16:29:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 14 Jul 2022 16:29:08 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
Message-ID: <c7wjtuN6mPqOBF16x5Ao4-uHXju0PB0Tf6cL8EFhY8E=.1c3e6ab2-9756-4d84-9e2d-0e64a9be9b05@github.com>

On Tue, 12 Jul 2022 22:56:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen 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 six additional commits since the last revision:
> 
>  - Updated method names for PassFailJFrame
>  - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
>  - Removed commented lines. Added newlines.
>  - Updated test with PassFailJFrame
>  - Added test
>  - Adjusted height and coordinate for editable JComboBox

> > > Can you please show before and after fix image of the editable combobox? It seems the border around the button makes it feel it's still not aligned properly which gives the impression that the button is bigger than textfield. Probably we can do away with the button border, if we can, in case we cannot draw the border around the whole textfield+button.
> > > Also, I think if you try with different font size e.g. `comboBox.setFont(new Font("Serif", Font.PLAIN, 30));`
> > > you will again see the editable combobox button height is not matching textfield height whereas non editable one it is aligned..
> > 
> > 
> > Local test without the fix: <img alt="Local Test Without Fix" width="182" src="https://user-images.githubusercontent.com/96267980/178778291-805ed3e0-fed2-458d-9ae6-65ace37f8ef0.png">
> > Local test with the fix: <img alt="Local Test With Alignment Fix" width="182" src="https://user-images.githubusercontent.com/96267980/178778425-5a8bf95a-014f-46dd-a018-29fd37b2fe39.png">
> 
> <img alt="Screenshot 2022-07-14 at 10 41 39 AM" width="494" src="https://user-images.githubusercontent.com/43534309/178904319-4e050697-d20c-4606-8434-954e1496c8a5.png">
> 
> I am not getting the same uniform blue border around textfield and button as can be seen in my screenshot with your test, which is seen in your image (with fix), so I asked to remove that incomplete blue border.. I am testing on BigSur 11.6..which os version is yours?

Discussed this with Prasanta over a meeting. I'm on Monterey 12.3.1. The border around the text field can be removed, but I can't seem to remove the button's border. I tried these but none removed the border (even though appearance changes for a standard JButton in testing):
- arrowButton.setBorder(javax.swing.BorderFactory.createEmptyBorder());
- arrowButton.setBorderPainted(false);
- arrowButton.setFocusPainted(false);

The appearance of this button in JComboBox seems to be set by the JRS, thus making a change to the button's border not possible. This concern will be compiled in a list alongside other questions regarding appearance of a JComboBox.

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

PR: https://git.openjdk.org/jdk/pull/9473


From serb at openjdk.org  Thu Jul 14 17:00:12 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 14 Jul 2022 17:00:12 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <695OWraXDsbYDLuLA85FEi6U_R3jXNxCQPHZpXmtqqI=.ed7a6020-23dc-44f0-94cf-109dde932d07@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
 <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
 <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>
 <cE7M9DiJpu9GU4mpC5MEnauX4K115odtvvNLtyYmi9s=.2810fcd2-1594-4edf-b9cb-b69bf66c78f2@github.com>
 <695OWraXDsbYDLuLA85FEi6U_R3jXNxCQPHZpXmtqqI=.ed7a6020-23dc-44f0-94cf-109dde932d07@github.com>
Message-ID: <vCyuvjmw3jB6pz6EoEwAyd9mggZ_3y2fhVjYCiGrESE=.e48ae614-2532-4531-ae0c-d52c5b237a1f@github.com>

On Wed, 13 Jul 2022 16:54:40 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>>> We cannot use MTLPrimitiveTypeLineStrip if we want to batch the subsequent draw calls as it draws an unwanted line between previous rectangle and current rectangle.
>> 
>> Even if the alpha will be transparent? Just curious.
>
> Yes, there will be a transparent line between previous rectangle and current rectangle.
> This PR introduces batching of vertices of successive draw calls of the same primitive. If we keep on adding vertices to a common buffer and finally encode draw operation using MTLPrimitiveTypeLineStrip, all those vertices will be connected. If color is changed in between these successive draw calls, we end the current vertex batch and start a new one.

But what about the usage of MTLPrimitiveTypeLineStrip and the transparent color to hide the "unwanted line between previous rectangle and current rectangle"? OR it is not possible to draw the lines using different colors in one step?

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

PR: https://git.openjdk.org/jdk/pull/9245


From aghaisas at openjdk.org  Thu Jul 14 17:21:03 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 14 Jul 2022 17:21:03 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <vCyuvjmw3jB6pz6EoEwAyd9mggZ_3y2fhVjYCiGrESE=.e48ae614-2532-4531-ae0c-d52c5b237a1f@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
 <nSmyhpFblPj4fdIadMu6rGyokR2xgRbcClxw4d44sM8=.1a88ae1d-78d4-491c-bdf7-d75ec36ffcea@github.com>
 <jGyfbyEC-rGZE6ZJqje-04Ey34IYgf-xqvAQ9Qmku_c=.f38779c7-641b-4794-bd79-636d4d634dd6@github.com>
 <cE7M9DiJpu9GU4mpC5MEnauX4K115odtvvNLtyYmi9s=.2810fcd2-1594-4edf-b9cb-b69bf66c78f2@github.com>
 <695OWraXDsbYDLuLA85FEi6U_R3jXNxCQPHZpXmtqqI=.ed7a6020-23dc-44f0-94cf-109dde932d07@github.com>
 <vCyuvjmw3jB6pz6EoEwAyd9mggZ_3y2fhVjYCiGrESE=.e48ae614-2532-4531-ae0c-d52c5b237a1f@github.com>
Message-ID: <kfoRBdLKcnY94KUWC-7hfYlg_ieybideLI41dlpwqjc=.fe2f171c-482f-4a87-a219-e2f5c6ea3ea5@github.com>

On Thu, 14 Jul 2022 16:57:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> OR it is not possible to draw the lines using different colors in one step?

Exactly this is the point.  If the color is changed (alpha change is also treated as color change) in between these successive draw calls, we end the current vertex batch and issue a draw command for accumulated vertices.
This is the reason MTLPrimitiveTypeLineStrip and MTLPrimitiveTriangleStrip cannot be used with our current vertex batching logic.

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

PR: https://git.openjdk.org/jdk/pull/9245


From naoto at openjdk.org  Thu Jul 14 19:54:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Jul 2022 19:54:20 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <xXURocaA6vPArkU45vu0jwEi9HTvqk9SyfaEBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
 <xXURocaA6vPArkU45vu0jwEi9HTvqk9Syfa
 EBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>
Message-ID: <pujKI75Zay-O9PJFd7aXMjYYp8FXid5E2I7StpbOuk0=.44dcf785-3503-44f0-b853-7e6f634a2053@github.com>

On Thu, 14 Jul 2022 15:27:43 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> True plurals (as in LDML) is not yet fully supported in the JDK. (`CompactNumberFormat` does for its own purpose (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is only localized in a handful of languages.
>
> Upon further consideration, and after discussing the state of plural forms support in JDK with @naotoj I realized that we cannot use ChoiceFormat here at all.  The numeric choices, and their corresponding resource strings are locale-specific, and in some cases simply cannot be coded as a finite array (see Arabic example above).
> 
> One possible solution would be to add proper support for plural forms to MessageFormat (which is definitely out of scope for this bug), or perhaps - if showing sizes 0...999 as numbers is not acceptable - to simply fix the 0 bytes case using KB format.  That is,
> 
> 0 - "0 KB"
> 1  - "1 KB"
> ...
> 
> (i.e. handle the 0 bytes case separately):
> 
>                 long len = ((Long) value);
> 
> if(len == 0) {
>   // shows "0 KB" for 0 bytes
>   text = MessageFormat.format(kiloByteString, 0);
> } else {
>   // retain existing logic
>   len /= 1024L;
> 
>                 if (listViewWindowsStyle) {
>                     text = MessageFormat.format(kiloByteString, len + 1);
>                 } else if (len < 1024L) {
>                     text = MessageFormat.format(kiloByteString, (len == 0L) ? 1L : len);
>                 } else {
>                     len /= 1024L;
>                     if (len < 1024L) {
>                         text = MessageFormat.format(megaByteString, len);
>                     } else {
>                         len /= 1024L;
>                         text = MessageFormat.format(gigaByteString, len);
>                     }
>                 }
> 
> and revert the new resource string.

Actually, my point was that since Swing is localized only in languages that can be dealt with (0, 1, other) choice patterns (or no plural pattern such as in Japanese), `ChoiceFormat` can still be used. Once we support complex plurals such as Arabic, we may need a more sophisticated solution.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 14 20:21:08 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 14 Jul 2022 20:21:08 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <pujKI75Zay-O9PJFd7aXMjYYp8FXid5E2I7StpbOuk0=.44dcf785-3503-44f0-b853-7e6f634a2053@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
 <xXURocaA6vPArkU45vu0jwEi9HTvqk9Syfa
 EBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>
 <pujKI75Zay-O9PJFd7aXMjYYp8FXid5E2I7StpbOuk0=.44dcf785-3503-44f0-b853-7e6f634a2053@github.com>
Message-ID: <lI5qbIs5DfnQc7vIko039aA5xdnkp_nB52YZd1HH28w=.d4ccb4d6-070e-4772-a4bf-738d2f915e8f@github.com>

On Thu, 14 Jul 2022 19:50:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upon further consideration, and after discussing the state of plural forms support in JDK with @naotoj I realized that we cannot use ChoiceFormat here at all.  The numeric choices, and their corresponding resource strings are locale-specific, and in some cases simply cannot be coded as a finite array (see Arabic example above).
>> 
>> One possible solution would be to add proper support for plural forms to MessageFormat (which is definitely out of scope for this bug), or perhaps - if showing sizes 0...999 as numbers is not acceptable - to simply fix the 0 bytes case using KB format.  That is,
>> 
>> 0 - "0 KB"
>> 1  - "1 KB"
>> ...
>> 
>> (i.e. handle the 0 bytes case separately):
>> 
>>                 long len = ((Long) value);
>> 
>> if(len == 0) {
>>   // shows "0 KB" for 0 bytes
>>   text = MessageFormat.format(kiloByteString, 0);
>> } else {
>>   // retain existing logic
>>   len /= 1024L;
>> 
>>                 if (listViewWindowsStyle) {
>>                     text = MessageFormat.format(kiloByteString, len + 1);
>>                 } else if (len < 1024L) {
>>                     text = MessageFormat.format(kiloByteString, (len == 0L) ? 1L : len);
>>                 } else {
>>                     len /= 1024L;
>>                     if (len < 1024L) {
>>                         text = MessageFormat.format(megaByteString, len);
>>                     } else {
>>                         len /= 1024L;
>>                         text = MessageFormat.format(gigaByteString, len);
>>                     }
>>                 }
>> 
>> and revert the new resource string.
>
> Actually, my point was that since Swing is localized only in languages that can be dealt with (0, 1, other) choice patterns (or no plural pattern such as in Japanese), `ChoiceFormat` can still be used. Once we support complex plurals such as Arabic, we may need a more sophisticated solution.

We seem to have resources localized in French.  French rules are as follows:
one ? n within 0..2 and n is not 2;
other ? everything else

ChoiceFormat simply cannot be used for number localization, we should remove it being mentioned in MessageFormat javadoc, at least remove the example with plurals.

The whole idea is that localization process does not require a code change.  With ChoiceFormat, it does - as the choices depend on language, and rules for some languages cannot be expressed as a set of choice, as for example in Ukrainian and many other Slavic languages:

one ? n mod 10 is 1 and n mod 100 is not 11;
few ? n mod 10 in 2..4 and n mod 100 not in 12..14;
many ? n mod 10 is 0 or n mod 10 in 5..9 or n mod 100 in 11..14;
other ? everything else

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

PR: https://git.openjdk.org/jdk/pull/9327


From naoto at openjdk.org  Thu Jul 14 20:35:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Jul 2022 20:35:14 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <lI5qbIs5DfnQc7vIko039aA5xdnkp_nB52YZd1HH28w=.d4ccb4d6-070e-4772-a4bf-738d2f915e8f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
 <xXURocaA6vPArkU45vu0jwEi9HTvqk9Syfa
 EBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>
 <pujKI75Zay-O9PJFd7aXMjYYp8FXid5E2I7StpbOuk0=.44dcf785-3503-44f0-b853-7e6f634a2053@github.com>
 <lI5qbIs5DfnQc7vIko039aA5xdnkp_nB52YZd1HH28w=.d4ccb4d6-070e-4772-a4bf-738d2f915e8f@github.com>
Message-ID: <o9-KaSUHjeIhfD8LyUpboX--CFBuDn5g9nTcOYLf2hg=.d43fd30a-df1c-417b-9e7a-a46700105fb2@github.com>

On Thu, 14 Jul 2022 20:17:14 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> Actually, my point was that since Swing is localized only in languages that can be dealt with (0, 1, other) choice patterns (or no plural pattern such as in Japanese), `ChoiceFormat` can still be used. Once we support complex plurals such as Arabic, we may need a more sophisticated solution.
>
> We seem to have resources localized in French.  French rules are as follows:
> one ? n within 0..2 and n is not 2;
> other ? everything else
> 
> ChoiceFormat simply cannot be used for number localization, we should remove it being mentioned in MessageFormat javadoc, at least remove the example with plurals.
> 
> The whole idea is that localization process does not require a code change.  With ChoiceFormat, it does - as the choices depend on language, and rules for some languages cannot be expressed as a set of choice, as for example in Ukrainian and many other Slavic languages:
> 
> one ? n mod 10 is 1 and n mod 100 is not 11;
> few ? n mod 10 in 2..4 and n mod 100 not in 12..14;
> many ? n mod 10 is 0 or n mod 10 in 5..9 or n mod 100 in 11..14;
> other ? everything else

Yes, you are right that `ChoiceFormat` is not for general localization. However, the supported UI translations in the JDK are English, German (new in 19), Japanese, and Simplified Chinese. (https://www.oracle.com/java/technologies/javase/jdk18-suported-locales.html for JDK18). That's why I made the point.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Fri Jul 15 04:57:19 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 15 Jul 2022 04:57:19 GMT
Subject: RFR: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS [v2]
In-Reply-To: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
References: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
Message-ID: <8l-nWO156lyVqJNiypjqDT8nEliZrwTq_UZWpUrHNXU=.a3d4bc70-1955-4317-ae1f-203ecbe47b26@github.com>

> It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
> Fixed to get the default selected icon and use that if in case the icon for that state is not set.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9481/files
  - new: https://git.openjdk.org/jdk/pull/9481/files/f3d3959c..859d3b9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9481&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9481&range=00-01

  Stats: 419 lines in 9 files changed: 419 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9481.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9481/head:pull/9481

PR: https://git.openjdk.org/jdk/pull/9481


From duke at openjdk.org  Fri Jul 15 05:20:34 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 15 Jul 2022 05:20:34 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  properties file reverted back and filesize shown in KB

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/518c6fd6..6b3ae9e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=04-05

  Stats: 36 lines in 3 files changed: 0 ins; 33 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul 15 05:50:08 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 15 Jul 2022 05:50:08 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v4]
In-Reply-To: <o9-KaSUHjeIhfD8LyUpboX--CFBuDn5g9nTcOYLf2hg=.d43fd30a-df1c-417b-9e7a-a46700105fb2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <_rEJ3-WPAg1pEx3QB-qld9Gva7CjNF0rhi4kODafPNU=.e4bddb99-18d3-4860-96c2-740675114281@github.com>
 <h-eV8_f2qSKaTDt3QQdt_OttMaA5-12vXBsO9nuJD0U=.47c51b80-1812-4ede-8b80-f303fafc2af1@github.com>
 <oowQgmmJ-A5bxWfefBTf9FspQ7KEINBf-TjykkmPB0I=.5a0e7459-26df-4460-9ecd-a1c98402a3cf@github.com>
 <ZWFc6M51CxjY3LsFi-VuZ8CvoxHk89nJ0gwFIJKteZE=.a152dd8f-788d-4d76-9ffa-f4319f5d06a6@github.com>
 <wKpk-VYGX0ki0HN1oMxB0pHweRGBM5T54205Qr15klM=.8a01c105-3a48-4e31-84c4-a03fa0e34471@github.com>
 <60wlzrdFfva1oh3oZkSeaq_CSpe2133MS1DctWi4Wvc=.fe6b3605-5491-4e4b-8409-55ba13ab8705@github.com>
 <NB879GCEHqRVyM6l6ROT1P8t9aigY8gjz4djJ2y2RiE=.8b1ef0c1-25bb-4e12-9ab0-14388f1ac738@github.com>
 <xkiAK5CWdFiTIbtAzw7oQekFd9JnlLxGIDULFBv4T84=.047daf87-e6db-4208-a4e9-3b7a039a3adc@github.com>
 <iN2buSzS5C8Po0ZM6O0cLPxh9-vxnLDZoB9shu1UilA=.5fd5f71b-9781-4ab2-b892-2f2d4b5d02e6@github.com>
 <xXURocaA6vPArkU45vu0jwEi9HTvqk9Syfa
 EBYVYm5A=.69b94f17-e759-4acb-8571-aa945c76aae4@github.com>
 <pujKI75Zay-O9PJFd7aXMjYYp8FXid5E2I7StpbOuk0=.44dcf785-3503-44f0-b853-7e6f634a2053@github.com>
 <lI5qbIs5DfnQc7vIko039aA5xdnkp_nB52YZd1HH28w=.d4ccb4d6-070e-4772-a4bf-738d2f915e8f@github.com>
 <o9-KaSUHjeIhfD8LyUpboX--CFBuDn5g9nTcOYLf2hg=.d43fd30a-df1c-417b-9e7a-a46700105fb2@github.com>
Message-ID: <ArB8XPKkX8ru0Lgpub8nBiU6GXknKUxfpFeWjFg6mYo=.5967c440-008f-4053-a127-a6cf4b05294b@github.com>

On Thu, 14 Jul 2022 20:33:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> We seem to have resources localized in French.  French rules are as follows:
>> one ? n within 0..2 and n is not 2;
>> other ? everything else
>> 
>> ChoiceFormat simply cannot be used for number localization, we should remove it being mentioned in MessageFormat javadoc, at least remove the example with plurals.
>> 
>> The whole idea is that localization process does not require a code change.  With ChoiceFormat, it does - as the choices depend on language, and rules for some languages cannot be expressed as a set of choice, as for example in Ukrainian and many other Slavic languages:
>> 
>> one ? n mod 10 is 1 and n mod 100 is not 11;
>> few ? n mod 10 in 2..4 and n mod 100 not in 12..14;
>> many ? n mod 10 is 0 or n mod 10 in 5..9 or n mod 100 in 11..14;
>> other ? everything else
>
> Yes, you are right that `ChoiceFormat` is not for general localization. However, the supported UI translations in the JDK are English, German (new in 19), Japanese, and Simplified Chinese. (https://www.oracle.com/java/technologies/javase/jdk18-suported-locales.html for JDK18). That's why I made the point.

I have reverted back the changes for basic.properties file and FileChooser now shows the file size as below:

0 - "0 KB"
1 - "1 KB" and so on...

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Fri Jul 15 07:00:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 15 Jul 2022 07:00:03 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <hLqueGw_bMW9jYcCdcLxnZ5XoLtBBnhW_Uw1S-dhjEE=.94690355-d620-44f4-82ad-a755e7fce5aa@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Did you check that it indeed accept 0 as a valid parameter and no exception is thrown?
Also, you need to raise a csr for this.

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

PR: https://git.openjdk.org/jdk/pull/9496


From tr at openjdk.org  Fri Jul 15 07:07:10 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 15 Jul 2022 07:07:10 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <hLqueGw_bMW9jYcCdcLxnZ5XoLtBBnhW_Uw1S-dhjEE=.94690355-d620-44f4-82ad-a755e7fce5aa@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <hLqueGw_bMW9jYcCdcLxnZ5XoLtBBnhW_Uw1S-dhjEE=.94690355-d620-44f4-82ad-a755e7fce5aa@github.com>
Message-ID: <wJHZQ0LU-0YFlVuyu6zd9JMIPidbGxLYsSK3onxEvDQ=.509cd7f0-93ab-4b54-9d28-19e2448b8a28@github.com>

On Fri, 15 Jul 2022 06:55:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Did you check that it indeed accept 0 as a valid parameter and no exception is thrown? Also, you need to raise a csr for this.

Yes, I checked with 0 and have gone through the code as well. 0 position indicates index before 1st existing position and it ranges till tabcount. Index checking is done for < 0 to > tabCount().

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

PR: https://git.openjdk.org/jdk/pull/9496


From tr at openjdk.org  Fri Jul 15 07:07:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 15 Jul 2022 07:07:11 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <x7mqmQdA1moI5jhp9EBqoSriSjf_phWpAuCBgcG6bpM=.7b36b55d-b7f9-443d-bdcf-b3faa3c39ce2@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

I'll raise CSR......?

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

PR: https://git.openjdk.org/jdk/pull/9496


From psadhukhan at openjdk.org  Fri Jul 15 07:29:10 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 15 Jul 2022 07:29:10 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <c7wjtuN6mPqOBF16x5Ao4-uHXju0PB0Tf6cL8EFhY8E=.1c3e6ab2-9756-4d84-9e2d-0e64a9be9b05@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
 <c7wjtuN6mPqOBF16x5Ao4-uHXju0PB0Tf6cL8EFhY8E=.1c3e6ab2-9756-4d84-9e2d-0e64a9be9b05@github.com>
Message-ID: <-hfHCvemr_JF77RocDdAE0Zq02ny-SlYRBrSrWG-2lk=.44a75683-fa47-4170-8748-2d0d93ecbb08@github.com>

On Thu, 14 Jul 2022 16:25:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>. I tried these but none removed the border (even though appearance changes for a standard JButton in testing):
> 
> * arrowButton.setBorder(javax.swing.BorderFactory.createEmptyBorder());
> * arrowButton.setBorderPainted(false);
> * arrowButton.setFocusPainted(false);
> 
> The appearance of this button in JComboBox seems to be set by the JRS, thus making a change to the button's border not possible. This concern will be compiled in a list alongside other questions regarding appearance of a JComboBox.

Since the arrowButton is rendered by JRS, it needs to be instucted not to draw the border in that case..The above methods will not work as JRSUIPainter does not know about that, so one can call 
`painter.state.set(FOCUSED.NO)`
or something like that to remove the focused border.
Having said that, I dont think it will be correct to remove the border from the button as it is meant to show focus is on that component. 
Ideally, the textfield also should have a focus border around it similar to button, so it will look uniform, so instead of removing border from button, we can try to draw focus border around textfield (maybe something similar to JDK-7124282)

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

PR: https://git.openjdk.org/jdk/pull/9473


From avu at openjdk.org  Fri Jul 15 11:40:26 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 15 Jul 2022 11:40:26 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
Message-ID: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>

Reuse displaysync thread for subsequent updates

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

Commit messages:
 - 8290344: Start/stop displaysync affects performance in metal rendering pipeline

Changes: https://git.openjdk.org/jdk/pull/9512/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9512&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290344
  Stats: 22 lines in 2 files changed: 15 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9512/head:pull/9512

PR: https://git.openjdk.org/jdk/pull/9512


From duke at openjdk.org  Fri Jul 15 13:11:57 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 15 Jul 2022 13:11:57 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v5]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <J749I_A6kodgzXsGEP-7q_sGRXL5yELbOhm9M0jhNPY=.309e6394-76fd-401e-8a56-d983926fa561@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with three additional commits since the last revision:

 - 8269806: Fix emoji, ZWJ, variation selectors and font fallback
   
   Also implement unacached rendering of colored outlines and bitmap glyphs
 - 8269806: Added emoji support for Windows
   
   Also pass real glyph type from native code instead of guessing it by rowBytes & width
 - Revert "8269806: Fix rendering of colored glyphs on big font sizes"
   
   This reverts commit e8b1adab923c79a6dd7a5d0b6adfb634c56f67bb.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/e8b1adab..30067e8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=03-04

  Stats: 1874 lines in 51 files changed: 1469 ins; 194 del; 211 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Jul 15 13:19:21 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 15 Jul 2022 13:19:21 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v6]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <OJ6Imxhx3pH4vlyBglrEILWbu5PapD8HvLhNdH9x8eU=.683176d4-fd51-4abd-bd26-d9743e00d733@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Fix GlyphRenderData CRLF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/30067e8e..f8fc165c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=04-05

  Stats: 171 lines in 1 file changed: 0 ins; 0 del; 171 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Jul 15 13:25:34 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 15 Jul 2022 13:25:34 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v7]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <uQIaDn8_2Mhc239fOZbMDibpSJX_0HvpUu3-f7sDETg=.c196b0a4-332f-4f29-b087-a7f968033a8c@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Fix other CRLF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/f8fc165c..3eb89159

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=05-06

  Stats: 554 lines in 4 files changed: 0 ins; 0 del; 554 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Jul 15 13:30:02 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 15 Jul 2022 13:30:02 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v7]
In-Reply-To: <uQIaDn8_2Mhc239fOZbMDibpSJX_0HvpUu3-f7sDETg=.c196b0a4-332f-4f29-b087-a7f968033a8c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <uQIaDn8_2Mhc239fOZbMDibpSJX_0HvpUu3-f7sDETg=.c196b0a4-332f-4f29-b087-a7f968033a8c@github.com>
Message-ID: <iPnjj3hnoKEezHm64OOUPtESpFWZj6M0rwMAXFT404s=.279cb506-c8a1-4121-935a-246b9a810575@github.com>

On Fri, 15 Jul 2022 13:25:34 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix other CRLF

? Celebrating 1 year of this PR by adding bunch of changes that include:

- Emoji rendering for Windows (colored outline glyphs) - based on Linux version via Freetype
- Emoji rendering via OutlineTextRenderer for big font sizes - both colored outline & bitmap glyphs

As well as many changes related to text layout & font fallback on all platforms:
- Detect emoji sequences which need shaping
- Make variation selectors work with the font fallback mechanism
- Properly handle ZWJ sequences in our layout code

@prrace can you take a look, please?

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Fri Jul 15 16:41:20 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 15 Jul 2022 16:41:20 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v8]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <PFPSoRaiw2QeR7TTGOwtMi62m-oSTwu1gtOrbSOuvak=.b2fb039d-d885-4f3d-a2a2-95095d7c6a9d@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Fix pointer to long conversion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/3eb89159..29b68f14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Fri Jul 15 18:23:12 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 18:23:12 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <W-gPd9B3KJ93VMBlZBevuKyQxbkH4TQKeo4l7Pypvn4=.4e031c21-9daf-4d47-8342-341a8a2adf30@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
 <W-gPd9B3KJ93VMBlZBevuKyQxbkH4TQKeo4l7Pypvn4=.4e031c21-9daf-4d47-8342-341a8a2adf30@github.com>
Message-ID: <ewONNnnTWn_Xx8yiBFr9fDW0lhiEB1foc3neWCLBx3Q=.66ee5596-bcc4-4a54-a4ae-6cb0b0b94424@github.com>

On Mon, 11 Jul 2022 13:38:58 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> @azuev-java @prrace please review this CSR ticket [JDK-8286674](https://bugs.openjdk.org/browse/JDK-8286674)

Before we get to that
1) You did not acknowledge this is not a backportable fix
2) I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API
3) It is incorrect to add the csr as an issue - skara tooling has made it an integration blocker.

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

PR: https://git.openjdk.org/jdk/pull/8578


From kizune at openjdk.org  Fri Jul 15 19:15:52 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 15 Jul 2022 19:15:52 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v8]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <XdKleSzQr_vPuBQQV1yLSHaBrJ_Lijait_Kk9t4JQxE=.ca02477a-2ad3-42a6-bf6a-5cdc186b60d5@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Correct wrong wording in a comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7805/files
  - new: https://git.openjdk.org/jdk/pull/7805/files/52333fbb..9d56c6e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7805&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7805&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/7805


From prr at openjdk.org  Fri Jul 15 19:24:09 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 19:24:09 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v8]
In-Reply-To: <XdKleSzQr_vPuBQQV1yLSHaBrJ_Lijait_Kk9t4JQxE=.ca02477a-2ad3-42a6-bf6a-5cdc186b60d5@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <XdKleSzQr_vPuBQQV1yLSHaBrJ_Lijait_Kk9t4JQxE=.ca02477a-2ad3-42a6-bf6a-5cdc186b60d5@github.com>
Message-ID: <ZAAYpW9AqZ9x7uq7CH68ImnCaolAhjh5LhA6XnDG6ek=.2be76a98-3190-41a2-a25d-73827a547c59@github.com>

On Fri, 15 Jul 2022 19:15:52 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct wrong wording in a comment

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/7805


From prr at openjdk.org  Fri Jul 15 20:20:10 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:20:10 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
Message-ID: <j1HyM522srQIm_cWyiMIK9GdodbAdaG4wXgVOrlONio=.15e209f4-231e-421b-b2b4-2596dd000546@github.com>

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
>> 
>> **Analysis :** 
>> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
>> 1) End points (vertices) required for the primitive drawing are put in a buffer.
>> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
>> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
>> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
>> 
>> **Root Cause of slower performance :**
>> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
>> 
>> **Fix :** 
>> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
>> The primitive drawing logic is modified to collate adjacent draw calls as below -
>> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
>> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
>> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
>> 
>> 
>> **More insight :** 
>> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
>> The performance test that we have measure rendering performance of extreme cases such as -
>> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
>> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
>> 
>> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
>> 
>> **Results :**
>> The performance results are attached to the JBS.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make method inline + clean commented line

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9245


From prr at openjdk.org  Fri Jul 15 20:31:12 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:31:12 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <z4T_g7wG1Qa4Xg3O60KeiocKTEXRM4F8BiwfE97VoGs=.35eaeb95-41df-4b05-b006-8e0cd65be55f@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

How do the changes made here improve stability ? What I see is just that you are adding a new condition under which it will fail.

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

PR: https://git.openjdk.org/jdk/pull/9202


From prr at openjdk.org  Fri Jul 15 20:42:10 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:42:10 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v4]
In-Reply-To: <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
Message-ID: <ZwkXTBfKXD8-6Tn_OhUx_kIGE6ZeGpkpOqnj2Q_xNyc=.13b9a379-2269-40b2-a56d-4648f0a5597e@github.com>

On Wed, 22 Jun 2022 12:52:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: removed redundant headful tag

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8158


From prr at openjdk.org  Fri Jul 15 20:44:08 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:44:08 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v4]
In-Reply-To: <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
Message-ID: <73ypng08TZNTwRToEvFLzvlTTJ4HS7cTbZzYJKjitnQ=.b58b13dc-c19b-43e6-8277-96eca149054a@github.com>

On Wed, 22 Jun 2022 11:42:06 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8284767
>  - Review comment fixed: removed redundant headful tag
>  - Review Comments Fixed: Fixed File location path.
>  - Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
>  - 8284767: Create an automated test for JDK-4422535
>  - 8284767: Create an automated test for JDK-4422535

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8220


From prr at openjdk.org  Fri Jul 15 20:44:16 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:44:16 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <WFsFMst8kdIrIUW369iGlPSp8md3gGi1pY9tJ2yzwXE=.4afcf2e6-4f22-47df-bd30-03386862d092@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/8546


From prr at openjdk.org  Fri Jul 15 20:52:59 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 20:52:59 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v4]
In-Reply-To: <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
Message-ID: <2WsQ4ykm29C-GFOwfepCpkVFSRpqEjoA4CAtAcLpz0g=.b841abcd-3ab2-45ec-bf87-b7b486b7e3b1@github.com>

On Fri, 10 Jun 2022 01:24:48 GMT, Jeremy <duke at openjdk.org> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Revising failing (commented out) scenarios.

Sorry, slow to get to this. I'm going to run a test job before giving it the OK.

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

PR: https://git.openjdk.org/jdk/pull/8943


From prr at openjdk.org  Fri Jul 15 21:02:03 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 21:02:03 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
Message-ID: <_QZn2bxW_yYgszpflq8_8fwIw0I_rn-IQPAnU56eggc=.e0c0ed19-66c7-47c2-a8c7-f03447cc2db1@github.com>

On Wed, 29 Jun 2022 06:53:29 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Reverted variable name change, reverted +20 in point

Changes requested by prr (Reviewer).

test/jdk/ProblemList.txt line 453:

> 451: java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java 8233568 macosx-all
> 452: java/awt/TrayIcon/RightClickWhenBalloonDisplayed/RightClickWhenBalloonDisplayed.java 8238720 windows-all
> 453: java/awt/PopupMenu/PopupMenuLocation.java 8238720 windows-all

8238720 is about failing when run on hi-dpi on windows. I don't see anything you've done to fix that

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 130:

> 128:         robot.waitForIdle();
> 129:         if (!actionEventReceivedLatch.await(5, TimeUnit.SECONDS)) {
> 130:             captureScreen();

So if it hasn't passed in 5 seconds, you fail the test. How is that improving stability ?

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

PR: https://git.openjdk.org/jdk/pull/9187


From prr at openjdk.org  Fri Jul 15 22:10:27 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 22:10:27 GMT
Subject: RFR: 8290334: Update FreeType to 2.12.1
Message-ID: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>

This is a very minor upgrade from ft 2.12.0 to 2.12.1
A good number of the changes (from upstream!) are just white space for whatever reason.

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

Commit messages:
 - 8290334

Changes: https://git.openjdk.org/jdk/pull/9524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290334
  Stats: 67 lines in 19 files changed: 10 ins; 8 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/9524.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9524/head:pull/9524

PR: https://git.openjdk.org/jdk/pull/9524


From prr at openjdk.org  Fri Jul 15 22:16:03 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Jul 2022 22:16:03 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v6]
In-Reply-To: <p9ePxs1myIgvK6VHUg-rlNWJ6ho0xE7JEsJPF5bpCuk=.6917f1d9-3b10-42f6-9926-6cf4d4a53d08@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <p9ePxs1myIgvK6VHUg-rlNWJ6ho0xE7JEsJPF5bpCuk=.6917f1d9-3b10-42f6-9926-6cf4d4a53d08@github.com>
Message-ID: <If-LUw0qmIN6u1ckmCqHqCiTKjL98wSOjHzCxjQSPIE=.4297f1f5-90c5-4b1b-9857-f763379a7d44@github.com>

On Wed, 13 Jul 2022 07:25:32 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JLabel and AbstractButton imageUpdate method description modified

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2150:

> 2148:     /**
> 2149:      * If the button icon for present button state is either <code>null</code>
> 2150:      * or not an <code>ImageIcon</code> with an <code>Image</code> equal to the

assuming the intent is correct, "for the current button state" reads better than "for present button state"

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2152:

> 2150:      * or not an <code>ImageIcon</code> with an <code>Image</code> equal to the
> 2151:      * passed in <code>Image</code>, return <code>false</code>; Otherwise it
> 2152:      * will delegate to the super-class.

"; Otherwise"

That isn't a new sentence so you should not  capitalise.

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

PR: https://git.openjdk.org/jdk/pull/9240


From smandalika at openjdk.org  Sat Jul 16 00:50:12 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 16 Jul 2022 00:50:12 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <kJ5c-bOQZJqN0Dx5hwv0lgka54KjqdN8vAaeUStwYLs=.5b576cd0-d0bd-483e-b1ea-0952ab429dba@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Can someone sponsor this PR?

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

PR: https://git.openjdk.org/jdk/pull/8546


From smandalika at openjdk.org  Sat Jul 16 00:50:22 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 16 Jul 2022 00:50:22 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v4]
In-Reply-To: <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>
Message-ID: <2LySdbcD6Muu27ocps9lKm6fqtg2MMiHeSBujGkoKY0=.4371eedd-a8aa-4fef-80f5-65c5a6407b29@github.com>

On Wed, 22 Jun 2022 12:52:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fixed: removed redundant headful tag

Can someone sponsor this PR?

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

PR: https://git.openjdk.org/jdk/pull/8158


From smandalika at openjdk.org  Sat Jul 16 00:50:26 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Sat, 16 Jul 2022 00:50:26 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v4]
In-Reply-To: <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>
Message-ID: <nDoCfTwJvVnpD6pGxfIgu9_VHwqqbvuQO8hoaK8y74I=.07c4f755-db94-4c1b-a7d9-eecbcae18e0c@github.com>

On Wed, 22 Jun 2022 11:42:06 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8284767
>  - Review comment fixed: removed redundant headful tag
>  - Review Comments Fixed: Fixed File location path.
>  - Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
>  - 8284767: Create an automated test for JDK-4422535
>  - 8284767: Create an automated test for JDK-4422535

Can someone sponsor this PR?

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

PR: https://git.openjdk.org/jdk/pull/8220


From honkar at openjdk.org  Sat Jul 16 01:10:34 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 16 Jul 2022 01:10:34 GMT
Subject: RFR: JDK-8289075: Change manual tests to use PassFailJFrame test
 framework
Message-ID: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>

Additional position setting (LEFT_HALF) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames. 

These changes have been added as part of [JDK-8289075](https://bugs.openjdk.org/browse/JDK-8289075) changes.

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

Commit messages:
 - PassFailJFrame changes for multiple frame scenarios

Changes: https://git.openjdk.org/jdk/pull/9525/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289075
  Stats: 32 lines in 1 file changed: 29 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Sat Jul 16 03:17:01 2022
From: duke at openjdk.org (SWinxy)
Date: Sat, 16 Jul 2022 03:17:01 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v3]
In-Reply-To: <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <szrbiuXqEzAHWEl_L3P_umygdVGlQ7vkarl9AN0623k=.b304a7cf-2390-4107-b921-a0a9e7fead28@github.com>
Message-ID: <5-NDEKIVpg7nSgBJcpcPiLgshys_IgdoqyyGYPXc3bk=.15bc37f8-5b76-4fc0-a004-9e562a602cdb@github.com>

On Fri, 20 May 2022 00:53:27 GMT, SWinxy <duke at openjdk.org> wrote:

>> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accidental mergers.
>   
>   I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different.

I can see which test suites are ran, sure. But they don't give me feedback as to what issues it had (good to know I got an error on the 4282 tests... but which *one*?). The bot removed the "needs sponsor" tag because tests had failed post-hoc (and they've failed for not being able to load stuff prior), so my PR surviving is dependent on those tests.

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

PR: https://git.openjdk.org/jdk/pull/7096


From duke at openjdk.org  Sat Jul 16 16:31:31 2022
From: duke at openjdk.org (SWinxy)
Date: Sat, 16 Jul 2022 16:31:31 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v4]
In-Reply-To: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
Message-ID: <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>

> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.

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

  Alter XColor documentation
  
  Let's see if this passes the checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7096/files
  - new: https://git.openjdk.org/jdk/pull/7096/files/32640e43..09d5d0ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7096&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7096&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/7096


From serb at openjdk.org  Sun Jul 17 02:58:08 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 17 Jul 2022 02:58:08 GMT
Subject: RFR: 8290334: Update FreeType to 2.12.1
In-Reply-To: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
References: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
Message-ID: <ePSzc6M8XUpXSQZPZCQnH6S8CDXKtA9XqavbIVZscug=.9c74880c-12fc-49db-a564-819a0e24081d@github.com>

On Fri, 15 Jul 2022 21:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a very minor upgrade from ft 2.12.0 to 2.12.1
> A good number of the changes (from upstream!) are just white space for whatever reason.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9524


From serb at openjdk.org  Sun Jul 17 03:07:06 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 17 Jul 2022 03:07:06 GMT
Subject: RFR: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS [v2]
In-Reply-To: <8l-nWO156lyVqJNiypjqDT8nEliZrwTq_UZWpUrHNXU=.a3d4bc70-1955-4317-ae1f-203ecbe47b26@github.com>
References: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
 <8l-nWO156lyVqJNiypjqDT8nEliZrwTq_UZWpUrHNXU=.a3d4bc70-1955-4317-ae1f-203ecbe47b26@github.com>
Message-ID: <_oC3BxYSWodWgLal2U_3F9YSXHVPcf8t8hdjFJ7rFEo=.1fcc67e5-3304-442d-9697-a52e00a0e3de@github.com>

On Fri, 15 Jul 2022 04:57:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
>> Fixed to get the default selected icon and use that if in case the icon for that state is not set.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 403:

> 401:         if (icon == null) return;
> 402: 
> 403:         Icon selectedIcon = null;

It looks like a similar pattern is used in the AquaButtonLabeledUI.paintIcon(), can we align the logic of both methods?

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

PR: https://git.openjdk.org/jdk/pull/9481


From prr at openjdk.org  Sun Jul 17 23:25:06 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 17 Jul 2022 23:25:06 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent [v2]
In-Reply-To: <DuZIpHsaFdw_cxbhiyLJ0cg4D8lNxYp2MVJ8rHB3mOI=.ce31cf20-5ca6-485b-822a-90a828dac705@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
 <DuZIpHsaFdw_cxbhiyLJ0cg4D8lNxYp2MVJ8rHB3mOI=.ce31cf20-5ca6-485b-822a-90a828dac705@github.com>
Message-ID: <Ph_SJsWvEYetgWKE39Nvzl6d9Yc0fsZmDaZgByBk4iA=.cbb91501-6cd6-45a2-8dd7-4761c168703c@github.com>

On Thu, 23 Jun 2022 06:12:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L428):
>> 
>>> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.
>> 
>> The LCMS plugin implementation expects the rendering intent in the first part of transform:
>> https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L116
>> 
>> But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L534) part of transform. 
>> 
>> Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L288)is implemented [properly](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L391).
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8288633
>  - Update ICC_ColorSpace.java
>  - 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent

Marked as reviewed by prr (Reviewer).

test/jdk/java/awt/color/ICC_ColorSpace/ToFromCIEXYZRoundTrip.java line 3:

> 1: /*
> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 3:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

2022 ?

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

PR: https://git.openjdk.org/jdk/pull/9194


From prr at openjdk.org  Sun Jul 17 23:25:09 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 17 Jul 2022 23:25:09 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent [v2]
In-Reply-To: <ygP4ipr5Jd3HKCm2qZnTSwV177k0Mui9loKSbwHmADw=.94970b14-5319-4d39-acb7-256a5ae8f6ed@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
 <ygP4ipr5Jd3HKCm2qZnTSwV177k0Mui9loKSbwHmADw=.94970b14-5319-4d39-acb7-256a5ae8f6ed@github.com>
Message-ID: <Q6HDflDFdFVBLANxI7n7DBfMxdqP0kXCYU1TBF-P3rY=.048dc85d-e735-4489-8688-8620f61ceed2@github.com>

On Fri, 17 Jun 2022 03:30:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8288633
>>  - Update ICC_ColorSpace.java
>>  - 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent
>
> src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java line 539:
> 
>> 537:                         transforms[1] = mdl.createTransform(thisProfile,
>> 538:                                         ColorTransform.Any, ColorTransform.Out);
>> 539:                     }
> 
> Note that this try/catch block is not needed, we never throw the exceptions here, but I follow this pattern for now. Will clean up it in the separate PR.

Is this some holdover from earlier code ?

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

PR: https://git.openjdk.org/jdk/pull/9194


From prr at openjdk.org  Sun Jul 17 23:28:23 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 17 Jul 2022 23:28:23 GMT
Subject: RFR: 8170794: [macosx] Error when using setDesktopManager on a
 JDesktopPane on MacOS X with Look and Feel Aqua
In-Reply-To: <x67mXpqQ0LoZTxf3DRzpreINeiNnLfncqB2oqFMhOXA=.331c02f9-4e82-4e3f-9a25-38bdde2920d1@github.com>
References: <x67mXpqQ0LoZTxf3DRzpreINeiNnLfncqB2oqFMhOXA=.331c02f9-4e82-4e3f-9a25-38bdde2920d1@github.com>
Message-ID: <p62bOeV2FJ-YwNAp3jR3P51qxdjaeKgi_TxolSmpiEI=.4396b947-a1dd-46fc-a37b-c90837e021d9@github.com>

On Thu, 7 Jul 2022 11:11:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When we call JDesktopPane.setDesktopManager(new DefaultDesktopManager()) and try to iconify an internalframe, it results in NPE
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
> at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1030)
> at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1489)
> at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
> at javax.swing.JComponent.paint(JComponent.java:1042)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.updateIcon(AquaInternalFrameDockIconUI.java:193)
> at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.paint(AquaInternalFrameDockIconUI.java:204)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at javax.swing.JLayeredPane.paint(JLayeredPane.java:586) 
> 
> 
> it seems the RepaintManager.getVolatileOffscreenBuffer() is called with JRootPane component for AquaLookAndFeel because of which SwingUtilities.getWindowAncestor(JRootPane) returns null causing NPE.
> 
> Fixed by adding a null check. The JInternalFrame can be successfully iconized now after setting DesktopManager.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9408


From prr at openjdk.org  Sun Jul 17 23:39:10 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 17 Jul 2022 23:39:10 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <rYNJGP4cSjPcnhKXBBTN8ppHuidwZLwjsSUol8gXnGA=.9eee5bd3-50d7-43c6-a9c5-05c8e344867f@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 727:

> 725:      *       ({@code >= 0 and <= getTabCount()})
> 726:      *
> 727:      * @throws IndexOutOfBoundsException if the index is out of range

Seems fine. The existing text actually contradicts the exception text immediately below.

Even though it is therefore arguably a typo, I suggest even so that a CSR be filed for this.

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

PR: https://git.openjdk.org/jdk/pull/9496


From prr at openjdk.org  Mon Jul 18 00:15:59 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 00:15:59 GMT
Subject: RFR: 8064787: [macosx] In Nimbus LaF,
 Ctrl+Alt mnemonic doesn't work
In-Reply-To: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
References: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
Message-ID: <396Uxu4nwNykbAfxL2-7G9zCNuN-0JTd7x9DjaqNW0U=.dd36de20-381b-4ec7-ba76-fd9d2f9bfc5f@github.com>

On Thu, 14 Jul 2022 08:03:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In SwingSet2 application, "File" menu has a visible mnemonic set on F.
> 
> ![image](https://user-images.githubusercontent.com/43534309/178932400-ab70602a-9c4f-4cab-b3b7-0508b26d2ebe.png)
> 
> Now, in MacOS, with Aqua, Java (Metal), and Motif LaF, one can open the menu pressing Ctrl+Alt+F. 
> But with Nimbus L&F, to open File menu, you have to press Alt+F even on OS X.
> 
> It should work with Ctrl+Alt+F as sun/lwawt/macosx/LWCToolkit.java. getFocusAcceleratorKeyMask() 
> has CTRL_MASK | ALT_MASK
> 
> Fix is to add Menu.shortcutKeys in SynthLookAndFeel default table so that it can call SwingUtilities2.getSystemMnemonicKeyMask() which will call either LWCToolkit.getFocusAcceleratorKeyMask() or SunToolkit.getFocusAcceleratorKeyMask() depending on platform.
> 
> No regression test is added as it can be checked with SwingSet2 app.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9488


From prr at openjdk.org  Mon Jul 18 00:17:04 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 00:17:04 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v4]
In-Reply-To: <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
Message-ID: <p7C4DOWrVlO_7qemoqrhj6FqY8SQBUisua8PWug7aNY=.0d9ff85b-20b9-4a89-9d50-a7704a8406d5@github.com>

On Fri, 10 Jun 2022 01:24:48 GMT, Jeremy <duke at openjdk.org> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Revising failing (commented out) scenarios.

Testing looks good.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8943


From prr at openjdk.org  Mon Jul 18 00:33:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 00:33:55 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <W5GczvkRCeyDQncj88nPsU1_Wdl33SUPEDUgAcg5dKU=.4a6f8d80-d0ab-4077-86cf-59f0dbbb6626@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

We need to revert the native code changes to "libfreetype".
These are 3rd party imported files.
After that we should get this pushed and move on and I agree that no matter
the similarity this PR is TOO BIG. Which is I think mostly why it has taken this long and still not done.

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

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8328


From tr at openjdk.org  Mon Jul 18 04:04:03 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 18 Jul 2022 04:04:03 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <ZeZ8ORg9BvWZDkGcKG3XR8UpmzWrB7bxzr_4GJk8KDo=.41ebac9c-5f6c-44e3-8052-936c1951d948@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

> @prrace has indicated that a [compatibility and specification](https://wiki.openjdk.org/display/csr/Main) (CSR) request is needed for this pull request.
> 
> @TejeshR13 please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8290278](https://bugs.openjdk.org/browse/JDK-8290278) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

Yeah sure @prrace .

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

PR: https://git.openjdk.org/jdk/pull/9496


From duke at openjdk.org  Mon Jul 18 04:54:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 18 Jul 2022 04:54:57 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v6]
In-Reply-To: <If-LUw0qmIN6u1ckmCqHqCiTKjL98wSOjHzCxjQSPIE=.4297f1f5-90c5-4b1b-9857-f763379a7d44@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <p9ePxs1myIgvK6VHUg-rlNWJ6ho0xE7JEsJPF5bpCuk=.6917f1d9-3b10-42f6-9926-6cf4d4a53d08@github.com>
 <If-LUw0qmIN6u1ckmCqHqCiTKjL98wSOjHzCxjQSPIE=.4297f1f5-90c5-4b1b-9857-f763379a7d44@github.com>
Message-ID: <0BOx4fIxDD62wJuFA-SCGwn-DAi6AA67bqjQsBHQ_mE=.cdb35625-68fe-4c3a-b1b7-2aa362cc0d78@github.com>

On Fri, 15 Jul 2022 22:11:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JLabel and AbstractButton imageUpdate method description modified
>
> src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2150:
> 
>> 2148:     /**
>> 2149:      * If the button icon for present button state is either <code>null</code>
>> 2150:      * or not an <code>ImageIcon</code> with an <code>Image</code> equal to the
> 
> assuming the intent is correct, "for the current button state" reads better than "for present button state"

"for present button state" text replaced with "for the current button state".

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

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Mon Jul 18 04:54:54 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 18 Jul 2022 04:54:54 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v7]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <yO0Vdm2bdhrp4r_Xzk-UxNICx7WvMOJrPvXCrdhuJew=.31e8e51d-ac23-4641-ac77-d83ec7648f84@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  JLabel and AbstractButton's imageUpdate method description updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/a6693011..dc11ed65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=05-06

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From aghaisas at openjdk.org  Mon Jul 18 05:21:19 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 18 Jul 2022 05:21:19 GMT
Subject: Integrated: 8288948: Few J2DBench tests indicate lower primitive
 drawing performance with metal rendering pipeline
In-Reply-To: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
Message-ID: <KYqshzk9owFjzMolDwc-XOpewtOpa9Vqg0sGVSI5zrQ=.29471386-1eed-4f3d-9238-c14a807f414b@github.com>

On Wed, 22 Jun 2022 16:32:11 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
> 
> **Analysis :** 
> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
> 1) End points (vertices) required for the primitive drawing are put in a buffer.
> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
> 
> **Root Cause of slower performance :**
> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
> 
> **Fix :** 
> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
> The primitive drawing logic is modified to collate adjacent draw calls as below -
> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
> 
> 
> **More insight :** 
> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
> The performance test that we have measure rendering performance of extreme cases such as -
> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
> 
> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
> 
> **Results :**
> The performance results are attached to the JBS.

This pull request has now been integrated.

Changeset: bc7a1ea2
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc7a1ea249d8438e325c36042f7d8fc7eaaf0e40
Stats:     257 lines in 4 files changed: 149 ins; 28 del; 80 mod

8288948: Few J2DBench tests indicate lower primitive drawing performance with metal rendering pipeline

Reviewed-by: avu, prr

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

PR: https://git.openjdk.org/jdk/pull/9245


From psadhukhan at openjdk.org  Mon Jul 18 09:15:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 18 Jul 2022 09:15:44 GMT
Subject: RFR: 6463708: DefaultButtonModel.setMnemonic generates ChangeEvent for
 no change
Message-ID: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>

For a DefaultButtonModel, setMnemonic() generates a ChangeEvent even if the new value is the same as the old value (that is, even if nothing has changed). 
Fix is to fire StateChange event only if the value has changed. 

This is consistent with other places like 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java#L103
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultSingleSelectionModel.java#L79
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultBoundedRangeModel.java#L309

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

Commit messages:
 - Fix
 - 6463708: DefaultButtonModel.setMnemonic generates ChangeEvent for no change
 - 6463708: DefaultButtonModel.setMnemonic generates ChangeEvent for no change

Changes: https://git.openjdk.org/jdk/pull/9536/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6463708
  Stats: 64 lines in 2 files changed: 62 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9536.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9536/head:pull/9536

PR: https://git.openjdk.org/jdk/pull/9536


From aivanov at openjdk.org  Mon Jul 18 12:11:02 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Jul 2022 12:11:02 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v8]
In-Reply-To: <XdKleSzQr_vPuBQQV1yLSHaBrJ_Lijait_Kk9t4JQxE=.ca02477a-2ad3-42a6-bf6a-5cdc186b60d5@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <XdKleSzQr_vPuBQQV1yLSHaBrJ_Lijait_Kk9t4JQxE=.ca02477a-2ad3-42a6-bf6a-5cdc186b60d5@github.com>
Message-ID: <-ufAA10_boM5LIu1RmdEdaRFpWxhLZwQyIS_27ublEc=.b526481f-db8b-4808-9294-50ab0b52dddf@github.com>

On Fri, 15 Jul 2022 19:15:52 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct wrong wording in a comment

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/7805


From psadhukhan at openjdk.org  Mon Jul 18 12:40:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 18 Jul 2022 12:40:09 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <xP683zcdXoC2o3lG14ZAxT-BK0NcEslcWmay92OuonM=.b5fdd69c-f0ee-4d7a-9ebe-0924ccf29b9d@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9496


From azvegint at openjdk.org  Mon Jul 18 14:53:02 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 18 Jul 2022 14:53:02 GMT
Subject: RFR: 6463708: DefaultButtonModel.setMnemonic generates ChangeEvent
 for no change
In-Reply-To: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
References: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
Message-ID: <mZlsRIElaDU2l1F-q6npQqhh8fG_Q3FLr8wKk2Kca6k=.761b1c20-168e-437a-81ed-a960607935c1@github.com>

On Mon, 18 Jul 2022 08:42:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> For a DefaultButtonModel, setMnemonic() generates a ChangeEvent even if the new value is the same as the old value (that is, even if nothing has changed). 
> Fix is to fire StateChange event only if the value has changed. 
> 
> This is consistent with other places like 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java#L103
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultSingleSelectionModel.java#L79
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultBoundedRangeModel.java#L309

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9536


From azvegint at openjdk.org  Mon Jul 18 15:00:47 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 18 Jul 2022 15:00:47 GMT
Subject: RFR: 8290334: Update FreeType to 2.12.1
In-Reply-To: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
References: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
Message-ID: <00LF178s2HhmD7vD2d2IhG2esKwtAvv0JRQ2ylKMBds=.fd625792-d033-4826-9b5c-62a27abe40ab@github.com>

On Fri, 15 Jul 2022 21:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a very minor upgrade from ft 2.12.0 to 2.12.1
> A good number of the changes (from upstream!) are just white space for whatever reason.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9524


From prr at openjdk.org  Mon Jul 18 16:09:06 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 16:09:06 GMT
Subject: Integrated: 8290334: Update FreeType to 2.12.1
In-Reply-To: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
References: <bNeKwAA8pTDHiLlNBavGqdUrtrWFhP0mBBwA4SJcj_c=.042da4f2-2a17-4163-a238-87a0e05a9768@github.com>
Message-ID: <dc_-mpV3qzCS509fJXM-4EzwxNH9E8Je8XvhJLTJXQg=.276206db-ae00-4477-8c5a-abc98f81f575@github.com>

On Fri, 15 Jul 2022 21:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a very minor upgrade from ft 2.12.0 to 2.12.1
> A good number of the changes (from upstream!) are just white space for whatever reason.

This pull request has now been integrated.

Changeset: ea8b75cf
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea8b75cfe453f5806a96ca85dd5e31724750a88f
Stats:     67 lines in 19 files changed: 10 ins; 8 del; 49 mod

8290334: Update FreeType to 2.12.1

Reviewed-by: serb, azvegint

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

PR: https://git.openjdk.org/jdk/pull/9524


From duke at openjdk.org  Mon Jul 18 17:20:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 18 Jul 2022 17:20:08 GMT
Subject: Integrated: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <kgNxmv6OzEQK3mQVd_R6Vhx_IgMVBH82h0a4-SNcSA0=.d50be8bd-d9bd-4be6-ade3-ed1b9d215daf@github.com>

On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

This pull request has now been integrated.

Changeset: efed7a7f
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efed7a7f65c0fa4b757ac6b448d11d7ddebdcc9a
Stats:     97 lines in 5 files changed: 84 ins; 1 del; 12 mod

8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Reviewed-by: prr, rriggs, aturbanov

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

PR: https://git.openjdk.org/jdk/pull/9407


From smandalika at openjdk.org  Mon Jul 18 17:21:12 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 18 Jul 2022 17:21:12 GMT
Subject: Integrated: 8284767: Create an automated test for JDK-4422535
In-Reply-To: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
Message-ID: <zDvd71loLsoN1LrLESHRsNU1tpDTG1HI9OZo6EZdbKw=.d60c622d-e856-4194-8042-7e584d072f33@github.com>

On Wed, 13 Apr 2022 11:02:05 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
> AccessibleValue implementation only accept Integers
> The AccessibleValue implementations of the following components:
> 
> java.awt.Scrollbar
> javax.swing.AbstractButton
> javax.swing.JInternalFrame
> javax.swing.JSplitPane
> javax.swing.JScrollBar
> javax.swing.JProgressBar
> javax.swing.JSlider
> 
> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
> 
> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
> 
> his review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: 5ae43209
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ae4320921b15dcc198d0c71416cd46e5b5c2f85
Stats:     76 lines in 1 file changed: 76 ins; 0 del; 0 mod

8284767: Create an automated test for JDK-4422535

Reviewed-by: prr, achung

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

PR: https://git.openjdk.org/jdk/pull/8220


From prr at openjdk.org  Mon Jul 18 17:22:11 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 17:22:11 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v4]
In-Reply-To: <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>
Message-ID: <mDLPcZ9pmSx9RPx9ev58lCEBBgQr_fAMNPbC5NTXEYs=.b4a853b0-e2f7-4482-ae46-58682e8ec7f7@github.com>

On Sat, 16 Jul 2022 16:31:31 GMT, SWinxy <duke at openjdk.org> wrote:

>> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alter XColor documentation
>   
>   Let's see if this passes the checks

1) The test suites are NOT preventing integration
2) The tests run here are IRRELEVANT to client changes - NO CLIENT TESTS ARE RUN by GHA. Not a single one.
If any client tests need to be run you will need to do it yourself
3) the sponsor label was removed when I requested changes which you have made since
It looks to me as if you can just type /integrate again

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

PR: https://git.openjdk.org/jdk/pull/7096


From smandalika at openjdk.org  Mon Jul 18 17:23:07 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 18 Jul 2022 17:23:07 GMT
Subject: Integrated: 8286172: Create an automated test for JDK-4516019
In-Reply-To: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
Message-ID: <1lz2KZixx6MlaYBOHk_EIP_c9rsGO9KXVazwFNXIOxc=.0cb7f623-3dec-4805-8646-08cc913fa9ad@github.com>

On Thu, 5 May 2022 06:58:26 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
> 
> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
> 
> The test validates the same.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: e72742ee
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e72742eeb5f265e854d098a560cb41c83e93f905
Stats:     121 lines in 1 file changed: 121 ins; 0 del; 0 mod

8286172: Create an automated test for JDK-4516019

Reviewed-by: prr, achung

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

PR: https://git.openjdk.org/jdk/pull/8546


From smandalika at openjdk.org  Mon Jul 18 17:23:11 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Mon, 18 Jul 2022 17:23:11 GMT
Subject: Integrated: 8284524: Create an automated test for JDK-4422362
In-Reply-To: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
Message-ID: <9WYnbfVfYWJzcZgDdfMi0dt4Ld3dZTwLLRVa1nWD2G8=.1da5f650-0218-41fa-aa0d-59bbc6165443@github.com>

On Fri, 8 Apr 2022 09:42:51 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
> 
> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
> AccessibleValue implementation.
> The real maximum value (due to the constraints on BoundedRangeModel) is
> model.getMaximum() - model.getExtent().
> 
> The test verifies that the above is adhered to as expected.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: b9de0a75
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9de0a7556f7be2c6afc6bb41bfa0339b639ff88
Stats:     71 lines in 1 file changed: 71 ins; 0 del; 0 mod

8284524: Create an automated test for JDK-4422362

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/8158


From prr at openjdk.org  Mon Jul 18 19:54:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 19:54:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
Message-ID: <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>

On Fri, 15 Jul 2022 05:20:34 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   properties file reverted back and filesize shown in KB

src/java.desktop/share/classes/sun/swing/FilePane.java line 1207:

> 1205:                     len /= 1024L;
> 1206:                     if (len < 1024L) {
> 1207:                         text = MessageFormat.format(kiloByteString, len);

So ALL of these have an "off by one" issue don't they ?

Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Mon Jul 18 20:01:13 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Mon, 18 Jul 2022 20:01:13 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
 <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>
Message-ID: <FBC5L-kU1Dka8ChdwPS-nzTDGcJHLuV-4euCMH-j9v8=.b4f3b165-3a07-466f-ba3a-86cb801809cd@github.com>

On Mon, 18 Jul 2022 19:50:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   properties file reverted back and filesize shown in KB
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1207:
> 
>> 1205:                     len /= 1024L;
>> 1206:                     if (len < 1024L) {
>> 1207:                         text = MessageFormat.format(kiloByteString, len);
> 
> So ALL of these have an "off by one" issue don't they ?
> 
> Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"

I think this also deserves extracting it into a separate function, and a unit test.
And perhaps another unit test with a non-English locale.

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Mon Jul 18 20:30:17 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Jul 2022 20:30:17 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
Message-ID: <bLQxdJEc-8erJOuMc2Uimz0aNJiSFPIQ50Nu1h-dQdo=.c7c3c217-da31-4441-b06e-af38eb9c20cf@github.com>

On Sat, 28 May 2022 03:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UTF-8 korean fallback

Marked as reviewed by prr (Reviewer).

So Malgun IS listed. But when I am running in a fully Korean configuration,  
Font2DTest is displaying the Korean name for the font - not the English name. So oops, all was just fine. 
This fix seems ready to push

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

PR: https://git.openjdk.org/jdk/pull/7643


From kizune at openjdk.org  Mon Jul 18 20:37:20 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 18 Jul 2022 20:37:20 GMT
Subject: Integrated: 8282526: Default icon is not painted properly
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <zijL8C9mOcFhGf568gQEz41vezSiXmd0XWyOhJzL7Ls=.c95807ad-3247-4747-b7a9-126d1058fc0b@github.com>

On Sun, 13 Mar 2022 21:06:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

This pull request has now been integrated.

Changeset: 6c8d0e61
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c8d0e617ff59eee1313589b10edbf5830774db5
Stats:     99 lines in 3 files changed: 95 ins; 1 del; 3 mod

8282526: Default icon is not painted properly

Reviewed-by: aivanov, prr

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

PR: https://git.openjdk.org/jdk/pull/7805


From honkar at openjdk.org  Mon Jul 18 20:54:08 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 18 Jul 2022 20:54:08 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v2]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <656ubIUx97zw3KKFnpBFwHDEU8ZSQDCdW5nZ8CaqdN0=.c170d461-4c45-49b6-aa4e-bca117427e52@github.com>

> Additional position setting (LEFT_HALF) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  Top left positon added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/fb35ce22..230ca0ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=00-01

  Stats: 25 lines in 1 file changed: 11 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Tue Jul 19 05:53:04 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 19 Jul 2022 05:53:04 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <FBC5L-kU1Dka8ChdwPS-nzTDGcJHLuV-4euCMH-j9v8=.b4f3b165-3a07-466f-ba3a-86cb801809cd@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
 <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>
 <FBC5L-kU1Dka8ChdwPS-nzTDGcJHLuV-4euCMH-j9v8=.b4f3b165-3a07-466f-ba3a-86cb801809cd@github.com>
Message-ID: <QxOrj91M3ndm2MhBFd2ytR3-88nPiKgGD_MX_K2Swp8=.a00f5275-778a-4f27-baac-67901b556985@github.com>

On Mon, 18 Jul 2022 19:59:00 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1207:
>> 
>>> 1205:                     len /= 1024L;
>>> 1206:                     if (len < 1024L) {
>>> 1207:                         text = MessageFormat.format(kiloByteString, len);
>> 
>> So ALL of these have an "off by one" issue don't they ?
>> 
>> Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"
>
> I think this also deserves extracting it into a separate function, and a unit test.
> And perhaps another unit test with a non-English locale.

> So ALL of these have an "off by one" issue don't they ?
> 
> Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"

There is "off by one" issue in this case. One possible solution can be - 


![FileChooser_FileSizes](https://user-images.githubusercontent.com/107542245/179674833-345a7e81-4af2-403e-b9e1-9d690bffeddd.png)

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Tue Jul 19 06:02:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 19 Jul 2022 06:02:57 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <QxOrj91M3ndm2MhBFd2ytR3-88nPiKgGD_MX_K2Swp8=.a00f5275-778a-4f27-baac-67901b556985@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
 <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>
 <FBC5L-kU1Dka8ChdwPS-nzTDGcJHLuV-4euCMH-j9v8=.b4f3b165-3a07-466f-ba3a-86cb801809cd@github.com>
 <QxOrj91M3ndm2MhBFd2ytR3-88nPiKgGD_MX_K2Swp8=.a00f5275-778a-4f27-baac-67901b556985@github.com>
Message-ID: <vPuibybNUVm3ADoMr5BWaZl1PnQEAHM-J5iM5C-s8WQ=.6617e02c-ef7c-4759-896d-39610ed5bccd@github.com>

On Tue, 19 Jul 2022 05:49:20 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> I think this also deserves extracting it into a separate function, and a unit test.
>> And perhaps another unit test with a non-English locale.
>
>> So ALL of these have an "off by one" issue don't they ?
>> 
>> Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"
> 
> There is "off by one" issue in this case. One possible solution can be - 
> 
> 
> ![FileChooser_FileSizes](https://user-images.githubusercontent.com/107542245/179674833-345a7e81-4af2-403e-b9e1-9d690bffeddd.png)

If any file having size  >1024 byte & <2048 byte will be rounded off as 2 KB and so on.
Similarly if file size is >1023KB will show file size as 1MB (rounding off will make file size as 1024KB and then it will convert it to MB).

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Tue Jul 19 06:10:10 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 19 Jul 2022 06:10:10 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v6]
In-Reply-To: <vPuibybNUVm3ADoMr5BWaZl1PnQEAHM-J5iM5C-s8WQ=.6617e02c-ef7c-4759-896d-39610ed5bccd@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7ccVoV6PFEYB_pavVyxehvdjiu1zjeGEukirPDjisco=.701f4266-db5e-4d30-9f33-795d54b95085@github.com>
 <Jr5q2e3T3hJ0o5dHSe7QqEyjHOKImcCA9VxKh-6c6Jw=.56c6e9a9-5a35-42e8-9184-21dfa103efb0@github.com>
 <FBC5L-kU1Dka8ChdwPS-nzTDGcJHLuV-4euCMH-j9v8=.b4f3b165-3a07-466f-ba3a-86cb801809cd@github.com>
 <QxOrj91M3ndm2MhBFd2ytR3-88nPiKgGD_MX_K2Swp8=.a00f5275-778a-4f27-baac-67901b556985@github.com>
 <vPuibybNUVm3ADoMr5BWaZl1PnQEAHM-J5iM5C-s8WQ=.6617e02c-ef7c-4759-896d-39610ed5bccd@github.com>
Message-ID: <vDvd3DZqdyLa-HtLaf6YZX7_Zq7AlxzIUomxcYu0n9c=.da5a21ba-ac19-4df6-9fec-0adc1871813e@github.com>

On Tue, 19 Jul 2022 05:59:33 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>>> So ALL of these have an "off by one" issue don't they ?
>>> 
>>> Here a file that is (for example) 2047 bytes in size will be displayed as "1KB"
>> 
>> There is "off by one" issue in this case. One possible solution can be - 
>> 
>> 
>> ![FileChooser_FileSizes](https://user-images.githubusercontent.com/107542245/179674833-345a7e81-4af2-403e-b9e1-9d690bffeddd.png)
>
> If any file having size  >1024 byte & <2048 byte will be rounded off as 2 KB and so on.
> Similarly if file size is >1023KB will show file size as 1MB (rounding off will make file size as 1024KB and then it will convert it to MB).

![TestFileSize](https://user-images.githubusercontent.com/107542245/179677108-3ef9784e-fa28-464c-8b09-5a940dd0f57a.png)

File size shown by JFileChooser in details view.

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

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Tue Jul 19 06:57:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 19 Jul 2022 06:57:39 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  window positioning changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/230ca0ba..bb981d49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9525


From psadhukhan at openjdk.org  Tue Jul 19 08:30:41 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 19 Jul 2022 08:30:41 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if combo
 box menu is displayed
Message-ID: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>

When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
It seems actionEvent is fired when popup menu is not visible. 
Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
(for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)

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

Commit messages:
 - 8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed
 - 8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed

Changes: https://git.openjdk.org/jdk/pull/9551/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9551&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290399
  Stats: 94 lines in 2 files changed: 92 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9551.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9551/head:pull/9551

PR: https://git.openjdk.org/jdk/pull/9551


From psadhukhan at openjdk.org  Tue Jul 19 08:30:41 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 19 Jul 2022 08:30:41 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed
In-Reply-To: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
Message-ID: <kfcH5K-IUzsn1WTPrGLDi_4ERa0Ft3zXJyHkhCZaA6Q=.ba847f49-0ff4-45d9-9c84-728cacacea69@github.com>

On Tue, 19 Jul 2022 08:13:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
> It seems actionEvent is fired when popup menu is not visible. 
> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)

test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java line 91:

> 89:         pfjFrame.awaitAndCheck();
> 90:     }
> 91: }

Tried automating the test but it seems to call BasicComboBoxUI#focusLost when ENTER key is pressed, which calls actionPerformed thus defeating the purpose.




public class TestEditableComboBox
{
    private static JFrame fr;
    private static JComboBox<String> cb;
    private static Point loc;
    private static Dimension dim;
    private static volatile boolean actionDone = false;

    public TestEditableComboBox()
    {
        // Instructions:
        // Click the arrow to display the menu.
        // While the menu is displayed, edit the text to create a new value.
        // Type return.
        // The action listener should be invoked.

        // Using Aqua LAF, the return dismisses the menu but does invoke action listeners.
        // A second return is needed to invoke actions listeners.
        // This behavior is inconsistent with other LAFs and native NSComboBox.

//        if (true) {
//            try {
//                //UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
//                UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel");
//            } catch (Exception e) {
//                System.err.println(e.toString());
//            }
//        }

        fr = new JFrame("Test Editable Combo Box");
        String[] values = new String[] { "Apple", "Orange", "Pear" };
        cb = new JComboBox<>(values);
        cb.setEditable(true);
        cb.addActionListener(e -> {
            //actionDone = true;
                System.err.println("Action listener called: " + e.getActionCommand());
                });

        Container c = fr.getContentPane();
        c.setLayout(new FlowLayout());
        c.add(cb);
        fr.pack();
        //fr.setBounds(400, 100, 400, 80);
        fr.setLocationRelativeTo(null);
        fr.setVisible(true);
    }

    public static void main(String[] args) throws Exception {

        java.util.List<String> lafs = Arrays.stream(UIManager.getInstalledLookAndFeels())
                                  .map(UIManager.LookAndFeelInfo::getClassName)
                                  .collect(Collectors.toList());
        for (final String laf : lafs) {
            try {
                try {
                    UIManager.setLookAndFeel(laf);
                    System.out.println("Testing L&F: " + laf);
                } catch (UnsupportedLookAndFeelException e) {
                    System.out.println("Skipping unsupported L&F: " + laf);
                }
                SwingUtilities.invokeAndWait(TestEditableComboBox::new);
                SwingUtilities.invokeAndWait(() -> {
                    loc = cb.getLocationOnScreen();
                    dim = cb.getSize();
                });
                Robot robot = new Robot();
                robot.waitForIdle();
                robot.delay(1000);
                robot.mouseMove(loc.x + dim.width - 2, loc.y);
                robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
                robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
                robot.waitForIdle();
                robot.delay(1000);
                robot.keyPress(KeyEvent.VK_A);
                robot.keyRelease(KeyEvent.VK_A);
                robot.waitForIdle();
                robot.delay(1000);
                robot.keyPress(KeyEvent.VK_ENTER);
                robot.keyRelease(KeyEvent.VK_ENTER);
                robot.waitForIdle();
                robot.delay(1000);
//                if (!actionDone) {
//                    throw new RuntimeException("ActionEvent not fired");
//                }
            } finally {
                SwingUtilities.invokeAndWait(() -> {
                    if (fr != null) {
                        fr.dispose();
                    }
                });
            }
        }
    }
}

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

PR: https://git.openjdk.org/jdk/pull/9551


From aturbanov at openjdk.org  Tue Jul 19 13:27:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Jul 2022 13:27:52 GMT
Subject: RFR: 8290162: Reset recursion counter missed in fix of JDK-8224267
In-Reply-To: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
References: <JzMTCSO1pOkS_ogijAKCEdP2vN6gPRQngl2HpdguKMA=.cf2d1356-9511-425f-874c-facab3911657@github.com>
Message-ID: <qoug6HvIAh2XDnyPHrzImA9SKF55opSa54gAsaugPdU=.51cf1059-bd0d-4b57-9f64-58a1e86e08eb@github.com>

On Tue, 12 Jul 2022 09:44:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `recursionCount` counter added in fix of JDK-8224267 is only reset when limit is reached,  so it will behave incorrectly if JOptionPane.showMessageDialog continuously with the same message having newlines, so it needs to be reset also at appropriate location. 
> Fix to reset the counter before the recursive method is called.
> 
> Also, fix added to indicate the original message is truncated by adding ... (ellipsis) to the previous line of text if it recurses more than limit set.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java line 485:

> 483:                 if (recursionCount++ > 200) {
> 484:                     recursionCount = 0;
> 485:                     addMessageComponents(container, cons, new String("..."),

Hm. What was the reason to use `new String` constructor here? Is it some security issue?
Seems redundant to me.

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

PR: https://git.openjdk.org/jdk/pull/9464


From duke at openjdk.org  Tue Jul 19 14:13:58 2022
From: duke at openjdk.org (duke)
Date: Tue, 19 Jul 2022 14:13:58 GMT
Subject: Withdrawn: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame
 support in regression regtesthelpers
In-Reply-To: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
References: <abWDTHr4uorNjVddaR6Ai-ZOn_5XNpg__RO5PSi4z-o=.01f596f9-c7c8-4ccc-8dba-84f28eca25c2@github.com>
Message-ID: <ZRtZOLNUzXdos3K6sZ4Av_crsJtXmCNpxMPNgN57wOU=.b33e5a4e-0603-4074-bff7-838493fce082@github.com>

On Thu, 21 Apr 2022 19:47:32 GMT, Alisen Chung <achung at openjdk.org> wrote:

> added EmbeddedFrame support for macosx in regtesthelpers

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/8348


From prr at openjdk.org  Tue Jul 19 23:13:48 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Jul 2022 23:13:48 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
Message-ID: <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>

On Tue, 19 Jul 2022 06:57:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   window positioning changes

Changes requested by prr (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 273:

> 271:      *                  as arranged up and down.
> 272:      *                  TOP_LEFT_CORNER - test instruction frame positioned at
> 273:      *                  top left corner with main test window beside it.

All of these descriptions are lacking in explaining what goes where
eg
HORIZONTAL should say the instruction window will be placed so that the right edge is to the left of the screen's horizontal centre and the test window will be placed just to the right of it.

TOP_LEFT_CORNER should say the instruction window will be placed so that its top left corner is at the top left corner of the screen and the test window will be placed just to the right of the instruction window.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 277:

> 275:     public static void positionTestWindow(Window testWindow, Position position) {
> 276:         Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
> 277: 

In this method we "randomly" use getX(), or getLocation().x and getY() or  and getLocation().y 
Why can't we be consistent and pick one style ? Seems like getX() and getY() would fit best here.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 292:

> 290:         }
> 291:         else if (position.equals(Position.TOP_LEFT_CORNER)) {
> 292:             frame.setLocation(0,0);

I am very sceptical of this. With a toolbar on the left and a menu bar on the top of the screen I bet you
are neither at x=0 or y=0.
And this code is not allowing the desktop to reposition it and report the updated REAL position back to you
The result will be overlapping windows.
I'm actually dubious of the existing code for much the same reason but it just likely hasn't been seen as a problem there because positioning in the middle of the screen usually gets you where you asked for.

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

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Wed Jul 20 00:04:03 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 20 Jul 2022 00:04:03 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
Message-ID: <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>

On Tue, 19 Jul 2022 23:10:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   window positioning changes
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 292:
> 
>> 290:         }
>> 291:         else if (position.equals(Position.TOP_LEFT_CORNER)) {
>> 292:             frame.setLocation(0,0);
> 
> I am very sceptical of this. With a toolbar on the left and a menu bar on the top of the screen I bet you
> are neither at x=0 or y=0.
> And this code is not allowing the desktop to reposition it and report the updated REAL position back to you
> The result will be overlapping windows.
> I'm actually dubious of the existing code for much the same reason but it just likely hasn't been seen as a problem there because positioning in the middle of the screen usually gets you where you asked for.

@prrace Thank you for reviewing. I do see your point - when taskbars and menu bars are located on top or left side of the screen, they would overlap the test instruction frame.  

Two possible solutions:

1. Going with a fixed amount of offset on where to position the top-left corner of the instruction frame window. Probably this would not be ideal considering different screen settings and platforms.

2. The other approach would be to use [GraphicsEnvironment.getMaximumWindowBounds()](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html#getMaximumWindowBounds()) to get the displayable window size and position the instruction frame accordingly ?

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

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Wed Jul 20 00:12:57 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Jul 2022 00:12:57 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
Message-ID: <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>

On Tue, 19 Jul 2022 23:52:44 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 292:
>> 
>>> 290:         }
>>> 291:         else if (position.equals(Position.TOP_LEFT_CORNER)) {
>>> 292:             frame.setLocation(0,0);
>> 
>> I am very sceptical of this. With a toolbar on the left and a menu bar on the top of the screen I bet you
>> are neither at x=0 or y=0.
>> And this code is not allowing the desktop to reposition it and report the updated REAL position back to you
>> The result will be overlapping windows.
>> I'm actually dubious of the existing code for much the same reason but it just likely hasn't been seen as a problem there because positioning in the middle of the screen usually gets you where you asked for.
>
> @prrace Thank you for reviewing. I do see your point - when taskbars and menu bars are located on top or left side of the screen, they would overlap the test instruction frame.  
> 
> Two possible solutions:
> 
> 1. Going with a fixed amount of offset on where to position the top-left corner of the instruction frame window. Probably this would not be ideal considering different screen settings and platforms.
> 
> 2. The other approach would be to use [GraphicsEnvironment.getMaximumWindowBounds()](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html#getMaximumWindowBounds()) to get the displayable window size and position the instruction frame accordingly ?

More than that - this code needs to call setlocation, and do "whatever" to make sure that is actually pushed to the "window manager" and the REAL location of the window come back. The way the code is written it sets a couple of vars and then reads back its own values .. no chance of finding the REAL location

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

PR: https://git.openjdk.org/jdk/pull/9525


From psadhukhan at openjdk.org  Wed Jul 20 05:49:58 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Jul 2022 05:49:58 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <bLQxdJEc-8erJOuMc2Uimz0aNJiSFPIQ50Nu1h-dQdo=.c7c3c217-da31-4441-b06e-af38eb9c20cf@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
 <bLQxdJEc-8erJOuMc2Uimz0aNJiSFPIQ50Nu1h-dQdo=.c7c3c217-da31-4441-b06e-af38eb9c20cf@github.com>
Message-ID: <TxHODMzDTM7ZtLShknvidHxSoX6FDjFsgZkFFlqKK7A=.e60d6f34-50d9-4136-ab5c-41f0a16bec6b@github.com>

On Mon, 18 Jul 2022 20:27:42 GMT, Phil Race <prr at openjdk.org> wrote:

> So Malgun IS listed. But when I am running in a fully Korean configuration, Font2DTest is displaying the Korean name for the font - not the English name. So oops, all was just fine. This fix seems ready to push

Hopefully we dont have to sit with interpreter in future for CJK fixes :-)

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

PR: https://git.openjdk.org/jdk/pull/7643


From psadhukhan at openjdk.org  Wed Jul 20 05:52:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Jul 2022 05:52:25 GMT
Subject: Integrated: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack
In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
Message-ID: <I3QMygWfaX36yew7vaVr68F5c0dqK6Lbpxoys5bRAkg=.a8edbb92-00b8-47e3-92da-a821bb8c1369@github.com>

On Tue, 1 Mar 2022 08:31:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts

This pull request has now been integrated.

Changeset: 97147915
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/971479153d726ffd8d457a0531f303d357798b3c
Stats:     13 lines in 1 file changed: 4 ins; 0 del; 9 mod

8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack

Reviewed-by: naoto, prr

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

PR: https://git.openjdk.org/jdk/pull/7643


From duke at openjdk.org  Wed Jul 20 08:17:09 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 20 Jul 2022 08:17:09 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  File Size shows upto 1 decimal value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/6b3ae9e5..f29fe0b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=05-06

  Stats: 21 lines in 1 file changed: 8 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 20 08:24:08 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 20 Jul 2022 08:24:08 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
Message-ID: <276U-hbx6keY7b-BgyayDNLAkh33MmQTCXjVmPELjfw=.69f55a13-e435-499a-a4a3-4c301afa848d@github.com>

On Wed, 20 Jul 2022 08:17:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   File Size shows upto 1 decimal value

File size shown in native is upto 1 decimal value. Now JFileChooser also shows filesize upto 1 decimal value similar to native.
There is a change in conversion factor from 1024 to 1000 to show file size as per native. 
![Filesize_Ubuntu](https://user-images.githubusercontent.com/107542245/179933188-4ddd6d9f-8da7-4a8e-8884-652d1bf93c93.png)
![FileSize_JFileChooser](https://user-images.githubusercontent.com/107542245/179933210-12cb3c9f-8d03-4424-90f7-65dbac930034.png)

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul 20 09:20:51 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Jul 2022 09:20:51 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results.
Message-ID: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>

Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

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

Commit messages:
 - Fix
 - 4797982: Setting negative size of JSplitPane divider leads to unexpected results.
 - 4797982: Setting negative size of JSplitPane divider leads to unexpected results.

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

PR: https://git.openjdk.org/jdk/pull/9566


From aghaisas at openjdk.org  Wed Jul 20 11:05:03 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 20 Jul 2022 11:05:03 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
In-Reply-To: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
Message-ID: <kxazPymz6yvpYrrdhxd_mGZtpmi3JOPQDBSPpU3UYUI=.44218d4e-51a0-4306-a093-c466d41c8429@github.com>

On Fri, 15 Jul 2022 11:32:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Reuse displaysync thread for subsequent updates

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 32:

> 30: #import "MTLSurfaceData.h"
> 31: #import "JNIUtilities.h"
> 32: #define KEEP_ALIVE_INC 4

Why only 4?
Have you experimented with lesser or greater values?

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

PR: https://git.openjdk.org/jdk/pull/9512


From duke at openjdk.org  Wed Jul 20 11:39:05 2022
From: duke at openjdk.org (Jeremy)
Date: Wed, 20 Jul 2022 11:39:05 GMT
Subject: Integrated: 8264999: GeneralPath.lineTo() to itself produces jagged
 lines
In-Reply-To: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
Message-ID: <z2K0WPtC7ZiHxMKTPqydx359Cb7EuGnx07jMOMNSeGc=.f211c938-5970-4c63-9d9b-d54978cf96be@github.com>

On Mon, 30 May 2022 01:15:01 GMT, Jeremy <duke at openjdk.org> wrote:

> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
> 
> The new unit test tests the original steps plus several variations.
> 
> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.

This pull request has now been integrated.

Changeset: 4b4d3528
Author:    jeremy <jeremy.wood at mac.com>
Committer: Laurent Bourg?s <lbourges at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b4d35289ad7bfd2c5d9992b7c1fb8507d44a56d
Stats:     347 lines in 2 files changed: 347 ins; 0 del; 0 mod

8264999: GeneralPath.lineTo() to itself produces jagged lines

Reviewed-by: lbourges, prr

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

PR: https://git.openjdk.org/jdk/pull/8943


From angorya at openjdk.org  Wed Jul 20 15:18:35 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 20 Jul 2022 15:18:35 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
Message-ID: <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>

On Wed, 20 Jul 2022 08:17:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   File Size shows upto 1 decimal value

src/java.desktop/share/classes/sun/swing/FilePane.java line 1192:

> 1190:                 setIcon(icon);
> 1191: 
> 1192:             } else if (value instanceof Long len) {

I think this code needs to be extracted into a function, and a unit test added.  Testing with different sizes and supported locales - let's say en_IN (Asian group separator) and ja_JP or zh_CN (no plural forms).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1233:

> 1231: 
> 1232:     public double formatToDoubleValue(long len) {
> 1233:         DecimalFormat df = new DecimalFormat("0.0");

two comments:
1. you can safely return a formatted string instead of another double
2. should there be a group separator?  i.e. should you get a locale-specific NumberFormat instance?

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Wed Jul 20 15:51:00 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Jul 2022 15:51:00 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
 <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
Message-ID: <wwJjwnTGwzgeu8cUqlGc5NPr01ai9q7qiXHd3YRGmgM=.44056526-521f-45e6-b427-eb33c4a6fe5d@github.com>

On Wed, 20 Jul 2022 15:15:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   File Size shows upto 1 decimal value
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1192:
> 
>> 1190:                 setIcon(icon);
>> 1191: 
>> 1192:             } else if (value instanceof Long len) {
> 
> I think this code needs to be extracted into a function, and a unit test added.  Testing with different sizes and supported locales - let's say en_IN (Asian group separator) and ja_JP or zh_CN (no plural forms).

JDK does not do unit tests in this way. There is no place to put it.
We do functional "system" level regression tests.

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

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Thu Jul 21 00:27:04 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 21 Jul 2022 00:27:04 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  added screen insets to account for taskbar position, doc changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/bb981d49..994888bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=02-03

  Stats: 27 lines in 1 file changed: 15 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Thu Jul 21 00:27:06 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 21 Jul 2022 00:27:06 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
Message-ID: <Sc8EES_5Rg0hfKkElmmaTgwRa0sQ30knSACJwKw2uM4=.9065b09a-82da-4d9a-b866-e1146936a2e4@github.com>

On Tue, 19 Jul 2022 23:02:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   window positioning changes
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 273:
> 
>> 271:      *                  as arranged up and down.
>> 272:      *                  TOP_LEFT_CORNER - test instruction frame positioned at
>> 273:      *                  top left corner with main test window beside it.
> 
> All of these descriptions are lacking in explaining what goes where
> eg
> HORIZONTAL should say the instruction window will be placed so that the right edge is to the left of the screen's horizontal centre and the test window will be placed just to the right of it.
> 
> TOP_LEFT_CORNER should say the instruction window will be placed so that its top left corner is at the top left corner of the screen and the test window will be placed just to the right of the instruction window.

@prrace  I have slightly changed the description as per your suggestion. Please let me know if any changes are required.

<img width="1720" alt="Horizontal" src="https://user-images.githubusercontent.com/95945681/180101017-43b7aa84-0a0e-4413-9846-c23d27d2798b.png">

**HORIZONTAL - the test instruction frame is positioned such that the right edge aligns with screen's vertical center and the test window is placed to the right of the instruction frame.**

---------------------------------------------------------------------------------------------------
<img width="1720" alt="vertical" src="https://user-images.githubusercontent.com/95945681/180101260-02679903-1d7b-405b-b687-1bdb3b5a75dc.png">

**VERTICAL - the test instruction frame is positioned such that the bottom edge aligns with the screen's horizontal center and the test window is placed below the instruction frame.**

----------------------------------------------------------------------------------------------------
![TopLeft](https://user-images.githubusercontent.com/95945681/180102430-2723a306-ec93-4801-b768-50302a1e4dda.jpg)

**TOP_LEFT_CORNER - the test instruction frame is positioned such that its top left corner is at the top left corner of the screen and the test window is placed to the right of the instruction frame. (Taskbar placed at the top of the screen in this example)**

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

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Thu Jul 21 00:27:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 21 Jul 2022 00:27:07 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
 <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
Message-ID: <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>

On Wed, 20 Jul 2022 00:09:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Thank you for reviewing. I do see your point - when taskbars and menu bars are located on top or left side of the screen, they would overlap the test instruction frame.  
>> 
>> Two possible solutions:
>> 
>> 1. Going with a fixed amount of offset on where to position the top-left corner of the instruction frame window. Probably this would not be ideal considering different screen settings and platforms.
>> 
>> 2. The other approach would be to use [GraphicsEnvironment.getMaximumWindowBounds()](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/GraphicsEnvironment.html#getMaximumWindowBounds()) to get the displayable window size and position the instruction frame accordingly ?
>
> More than that - this code needs to call setlocation, and do "whatever" to make sure that is actually pushed to the "window manager" and the REAL location of the window come back. The way the code is written it sets a couple of vars and then reads back its own values .. no chance of finding the REAL location

In the recent update the following points are addressed:

- Screen insets are used to account of taskbar position and the placement of the instruction frame at top-left corner
- Position option description update

Changes regarding pushing the latest position to window manager are being evaluated.

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

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Thu Jul 21 06:47:23 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 06:47:23 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <wwJjwnTGwzgeu8cUqlGc5NPr01ai9q7qiXHd3YRGmgM=.44056526-521f-45e6-b427-eb33c4a6fe5d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
 <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
 <wwJjwnTGwzgeu8cUqlGc5NPr01ai9q7qiXHd3YRGmgM=.44056526-521f-45e6-b427-eb33c4a6fe5d@github.com>
Message-ID: <a7No4K00cvX2DXRaZqunUBn7YOPOZB9q9wOw5_lJ3I0=.961f1d8b-f595-4984-8b4f-10a33ac0db98@github.com>

On Wed, 20 Jul 2022 15:47:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1192:
>> 
>>> 1190:                 setIcon(icon);
>>> 1191: 
>>> 1192:             } else if (value instanceof Long len) {
>> 
>> I think this code needs to be extracted into a function, and a unit test added.  Testing with different sizes and supported locales - let's say en_IN (Asian group separator) and ja_JP or zh_CN (no plural forms).
>
> JDK does not do unit tests in this way. There is no place to put it.
> We do functional "system" level regression tests.

I guess extracting this code to a function won't give much advantage as it is not called from multiple places.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 06:47:26 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 06:47:26 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
 <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
Message-ID: <KgMyxYu_r9sJls0KhrCrAnwXzzcLa4z3SqrD6bdflV0=.1d9aa05c-1ad3-4948-9d47-a2c2210a19c7@github.com>

On Wed, 20 Jul 2022 15:11:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   File Size shows upto 1 decimal value
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1233:
> 
>> 1231: 
>> 1232:     public double formatToDoubleValue(long len) {
>> 1233:         DecimalFormat df = new DecimalFormat("0.0");
> 
> two comments:
> 1. you can safely return a formatted string instead of another double
> 2. should there be a group separator?  i.e. should you get a locale-specific NumberFormat instance?

I think as the file size is getting compared so I am returning double value from the method. 
I guess group separator is not required as the file size is calculated in terms of Base 10. So anything above or equal to 1000 will be converted to next size unit. For e.g
If filesize is in terms of KB-
999 - "999 KB"
1000 - "1 MB" ...

Even this portion of code is not getting executed in windows as well as in mac and  in ubuntu, there is no group separator. 

As it is only doing formatting of a numeric number so I think there won't be any issues with locale specific.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 10:08:15 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 10:08:15 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v8]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <reRg7fsAFY88qGfGwlFPcgVJx-9M_an1p5kk1nhmoYo=.5237b137-820f-4792-a0b4-a72cd7c056a1@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  manual test case moved to directory and multiple file size check added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/f29fe0b2..600ac735

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=06-07

  Stats: 85 lines in 7 files changed: 85 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 10:23:37 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 10:23:37 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v9]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <A9uqgDT7ItIUn4hRgo8SJzevyvdujU1DJ7IfvxY6SsE=.4d5547ed-698a-4515-9eb3-bfc845142b12@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  whitespace removed from FileSizeCheck file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/600ac735..31e9252f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 10:23:37 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 10:23:37 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v8]
In-Reply-To: <reRg7fsAFY88qGfGwlFPcgVJx-9M_an1p5kk1nhmoYo=.5237b137-820f-4792-a0b4-a72cd7c056a1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <reRg7fsAFY88qGfGwlFPcgVJx-9M_an1p5kk1nhmoYo=.5237b137-820f-4792-a0b4-a72cd7c056a1@github.com>
Message-ID: <ZcB3GgmqIfbuhSMt6p6837irzsEp5Nh60I_9B_Hwyq4=.9c28b968-2a12-4f9c-a3f3-506d1d24a24d@github.com>

On Thu, 21 Jul 2022 10:08:15 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   manual test case moved to directory and multiple file size check added

Created a directory with bug-id (8288882) name under "open/test/jdk/javax/swing/JFileChooser".
Added manual test case file "FileSizeCheck.java" along with some dummy files to perform filesize checks.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 10:30:07 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 10:30:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v10]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <u8KEbyK__4EqaQnoTE5cUImma1zxzIWt_tb_iTCg2Jc=.8e503948-f790-462d-bca9-183c8dcdadea@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  added os.family tag and updated summary tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/31e9252f..0ccb7521

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Thu Jul 21 10:57:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Jul 2022 10:57:28 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware (>2GB)
Message-ID: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>

If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
This is because
it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
"number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.

Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265

No regression test is added as it involves using filesize of >2GB.

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

Commit messages:
 - 6445283: ProgressMonitorInputStream not large file aware (>2GB)

Changes: https://git.openjdk.org/jdk/pull/9588/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6445283
  Stats: 21 lines in 1 file changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9588.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9588/head:pull/9588

PR: https://git.openjdk.org/jdk/pull/9588


From duke at openjdk.org  Thu Jul 21 11:00:19 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 11:00:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v10]
In-Reply-To: <u8KEbyK__4EqaQnoTE5cUImma1zxzIWt_tb_iTCg2Jc=.8e503948-f790-462d-bca9-183c8dcdadea@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <u8KEbyK__4EqaQnoTE5cUImma1zxzIWt_tb_iTCg2Jc=.8e503948-f790-462d-bca9-183c8dcdadea@github.com>
Message-ID: <RCGxWzUrO8avQ_rXFuWcOzQTjwRmstEZHcma4GiNWSg=.09491462-277e-43c5-8df1-a7687917b58d@github.com>

On Thu, 21 Jul 2022 10:30:07 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added os.family tag and updated summary tag

ZeroFileSizeCheck file has been deleted as it is moved to different directory and is of no longer use.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 11:00:17 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 21 Jul 2022 11:00:17 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v11]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <OJrJm0zejMokivworR3JyWK1GsUeCsWhzwTmJ6RCAj4=.8a4547e0-41e7-47d6-919a-f5bc4a4f81c2@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Deleted ZeroFileSizeCheck file and updated text from 999.0 to 999 in FileSizeCheck file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/0ccb7521..02d4c08b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=09-10

  Stats: 80 lines in 2 files changed: 0 ins; 79 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 21 11:24:40 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 21 Jul 2022 11:24:40 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v9]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <tBnhBxstUAMMtCHBxaXEWLzEspiTNQqFJLNqa9OaBew=.94498040-31b8-4d37-a928-3c0fca1f6458@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Optimize bitmap creation in GlyphRenderData
  
  Get rid of unneeded abstract methods
  
  Use SSIM for OutlineTextRendererEmoji test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/29b68f14..1a2b4d6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=07-08

  Stats: 243 lines in 11 files changed: 130 ins; 64 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Thu Jul 21 11:41:48 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 21 Jul 2022 11:41:48 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v10]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <p3zzGMzbiXL6XuwZrDHeLTWzZeU6eDv78z4SJNBWipE=.8f3d5877-84d6-4694-bbad-6d9835b07b04@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge master
 - Optimize bitmap creation in GlyphRenderData
   
   Get rid of unneeded abstract methods
   
   Use SSIM for OutlineTextRendererEmoji test
 - Fix pointer to long conversion
 - Fix other CRLF
 - Fix GlyphRenderData CRLF
 - 8269806: Fix emoji, ZWJ, variation selectors and font fallback
   
   Also implement unacached rendering of colored outlines and bitmap glyphs
 - 8269806: Added emoji support for Windows
   
   Also pass real glyph type from native code instead of guessing it by rowBytes & width
 - Revert "8269806: Fix rendering of colored glyphs on big font sizes"
   
   This reverts commit e8b1adab923c79a6dd7a5d0b6adfb634c56f67bb.
 - 8269806: Fix rendering of colored glyphs on big font sizes
   
   When using OutlineTextRenderer, fallback to GlyphListPipe for glyphs which doesn't have outlines.
 - 8269806: Fix glyph advance rounding with FM=OFF
 - ... and 3 more: https://git.openjdk.org/jdk/compare/799a2c84...71a6f346

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

Changes: https://git.openjdk.org/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=09
  Stats: 2505 lines in 54 files changed: 2068 ins; 140 del; 297 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From azvegint at openjdk.org  Thu Jul 21 17:47:59 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 21 Jul 2022 17:47:59 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results.
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <Uh7RwGx8mk-3NvOdWMtQV48AC1_o3GGMihly8sYcENQ=.09525b5a-1555-4e06-9618-fac4f6b740c6@github.com>

On Wed, 20 Jul 2022 09:12:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9566


From azvegint at openjdk.org  Thu Jul 21 18:09:03 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 21 Jul 2022 18:09:03 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed
In-Reply-To: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
Message-ID: <X833xff-eTQZS9JeM3pdq2IzVXAHWuxYClYkFcW0UXg=.5d70c38c-6521-4e7b-89a4-941324b65083@github.com>

On Tue, 19 Jul 2022 08:13:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
> It seems actionEvent is fired when popup menu is not visible. 
> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTextField.java#L856

test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java line 82:

> 80:     public static void main(String[] args) throws Exception {
> 81: 
> 82:         UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel");

Shouldn't the test be macOS only?

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

PR: https://git.openjdk.org/jdk/pull/9551


From tr at openjdk.org  Thu Jul 21 18:41:27 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 21 Jul 2022 18:41:27 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
Message-ID: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>

Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

Commit messages:
 - Frame dimension update
 - Fix : Checking if its symlink and setting to file
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - ... and 2 more: https://git.openjdk.org/jdk/compare/c7c20661...82612a0a

Changes: https://git.openjdk.org/jdk/pull/9597/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9597&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8281966
  Stats: 112 lines in 2 files changed: 111 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9597.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9597/head:pull/9597

PR: https://git.openjdk.org/jdk/pull/9597


From azvegint at openjdk.org  Thu Jul 21 19:46:03 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 21 Jul 2022 19:46:03 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB)
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <ibW__716n99XRk6-jxqMGaFiRFKkEJ8f7s79bKUQrus=.64ea4008-13a1-4959-8cee-eeac0f57d0c9@github.com>

On Thu, 21 Jul 2022 10:47:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265

After applying the fix, I see that the tracker window closes when it reaches the limit, while the progress may be still ongoing for a prolonged period time. It doesn't look right to me.

I think we can either change this close condition, either fake progress to `MAX_INT-1` until we actually reach the end.

Anyway it seems like a workaround, real solution would be to migrate to long(probably by adding new constructors and methods to keep compatibility).


> No regression test is added as it involves using filesize of >2GB.

It doesn't have to be a FileInputStream, since ProgressMonitorInputStream accepts InputStream. So we can make a dummy one with no real data backing it.

src/java.desktop/share/classes/javax/swing/ProgressMonitorInputStream.java line 160:

> 158:                 monitor.setProgress(monitor.getMaximum());
> 159:             }
> 160:         }

Looks like Lines 154-167 duplicates code from lines 129-142.
Can we consider to extract it so another method?

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

PR: https://git.openjdk.org/jdk/pull/9588


From honkar at openjdk.org  Thu Jul 21 21:36:20 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 21 Jul 2022 21:36:20 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
 <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
 <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>
Message-ID: <Oio8L0XvJUNU9WJkKJRsFli6EUkVDe8hUgCy4vOFh3g=.ac2c19a6-d11a-45ff-9cf6-7c34e87cc526@github.com>

On Thu, 21 Jul 2022 00:20:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> More than that - this code needs to call setlocation, and do "whatever" to make sure that is actually pushed to the "window manager" and the REAL location of the window come back. The way the code is written it sets a couple of vars and then reads back its own values .. no chance of finding the REAL location
>
> In the recent update the following points are addressed:
> 
> - Screen insets are used to account of taskbar position and the placement of the instruction frame at top-left corner
> - Position option description update
> 
> Changes regarding pushing the latest position to window manager are still being evaluated and in progress.

Following is a proposed solution to push the latest position changes to the window manager.

Robot.waitForIdle() are added between setLocation() and the subsequent getLocation() calls. This ensures any pending location updates are pushed to the window manager before the new location of the frame is in turn used to position the testWindow.

In multiple test window cases ONLY the test instruction frame and the main/root test window are positioned using `positionTestWindow()`, the rest of the windows are positioned within EDT at test-level.

**Impact of the proposed fix:** 
With this change `positionTestWindow()` can no longer be called on EDT at test-level, hence any existing manual tests calling this method on EDT requires changes.

For example: In this particular test, the following line `PassFailJFrame.positionTestWindow(frame,PassFailJFrame.Position.HORIZONTAL)` should be called after `createAndShowGUI()`

https://github.com/openjdk/jdk/blob/d333df8ff59c6242171da1a6d02d05e6a8e65c9d/test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java#L75
 

public static void positionTestWindow(Window testWindow, Position position) throws AWTException {

        if (isEventDispatchThread()) {
            throw new Exception("positionTestWindow() should not be called on EDT");
        }

        robot = new Robot();
        Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();

        if (position.equals(Position.HORIZONTAL)) {
            SwingUtilities.invokeLater(() -> {
                int newX = ((screenSize.width / 2) - frame.getWidth());
                frame.setLocation(newX, frame.getY());
           });

            robot.waitForIdle();
            robot.delay(300);

            SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
                                             frame.getWidth() + 5), frame.getY()));

        } else if (position.equals(Position.VERTICAL)) {
            SwingUtilities.invokeLater(() -> {
                int newY = ((screenSize.height / 2) - frame.getHeight());
                frame.setLocation(frame.getX(), newY);
            });

            robot.waitForIdle();
            robot.delay(300);

            SwingUtilities.invokeLater(() -> testWindow.setLocation(frame.getX(),
                                            (frame.getY() + frame.getHeight() + 5)));

        } else if (position.equals(Position.TOP_LEFT_CORNER)) {
            SwingUtilities.invokeLater(() -> {
                GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment()
                        .getDefaultScreenDevice().getDefaultConfiguration();
                Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
                frame.setLocation(screenInsets.left, screenInsets.top);
            });

            robot.waitForIdle();
            robot.delay(300);

            SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
                   frame.getWidth() + 5), frame.getY()));
        }
    }

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

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Fri Jul 22 05:43:02 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 22 Jul 2022 05:43:02 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v4]
In-Reply-To: <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>
Message-ID: <BFdUn6X4TG6y49XCcFiF436fzc2gbMasGlns8_B-8n8=.fe0634fd-1367-4bcd-b271-26d7c21168a7@github.com>

On Sat, 16 Jul 2022 16:31:31 GMT, SWinxy <duke at openjdk.org> wrote:

>> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alter XColor documentation
>   
>   Let's see if this passes the checks

Ooohhh. I thought the bot would automatically reapply the tag when the checks passed?without me doing /integrate again. Thanks for the clarification.

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

PR: https://git.openjdk.org/jdk/pull/7096


From duke at openjdk.org  Fri Jul 22 07:33:08 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 22 Jul 2022 07:33:08 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <ANI49sDULzq6UsaGOWODTLZ2D5DfLO2-qk6sDkpqnOs=.2b8a8e9c-5c84-4eff-8f57-fc3e87a80898@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
 <ANI49sDULzq6UsaGOWODTLZ2D5DfLO2-qk6sDkpqnOs=.2b8a8e9c-5c84-4eff-8f57-fc3e87a80898@github.com>
Message-ID: <gb9buj3_Tk9QQCvxWEISUMyKcUCuVCLYUMkY6KHmwz0=.e0d48819-777d-46a6-9b6e-2e6bb639fd65@github.com>

On Thu, 7 Jul 2022 20:30:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Please move the CSR back to draft. There are some things that need to change there - and even here - before it is ready

I have updated the CSR. 
Please review https://bugs.openjdk.org/browse/JDK-8289490

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

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Fri Jul 22 07:42:07 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 22 Jul 2022 07:42:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v11]
In-Reply-To: <OJrJm0zejMokivworR3JyWK1GsUeCsWhzwTmJ6RCAj4=.8a4547e0-41e7-47d6-919a-f5bc4a4f81c2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <OJrJm0zejMokivworR3JyWK1GsUeCsWhzwTmJ6RCAj4=.8a4547e0-41e7-47d6-919a-f5bc4a4f81c2@github.com>
Message-ID: <0IB22jWbCuq708ef3L1tiy2ILI8Ru7Nhr8khE3ZKJrc=.a384310c-4c15-451b-9e95-e4601741fc25@github.com>

On Thu, 21 Jul 2022 11:00:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted ZeroFileSizeCheck file and updated text from 999.0 to 999 in FileSizeCheck file

![GTK_LAF](https://user-images.githubusercontent.com/107542245/180388673-72e06cc4-840c-474b-8821-2a735f27e0d8.png)
![Nimbus_LAF](https://user-images.githubusercontent.com/107542245/180388679-4a6bf8ce-ff09-48e7-8065-b5be046770c1.png)

Attached the screenshot for GTK LAF and Nimbus LAF for JFileChooser. 
In GTK LAF, JFileChooser doesn't show the file size.
In Nimbus, JFileChooser shows file sizes correctly.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul 22 07:50:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 22 Jul 2022 07:50:57 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v12]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <p99ZecQzf7LeUOqUF1IL1GFa8D_MOCOWDthoIFFwiJk=.7c2d22e0-4d46-48a7-a572-b397c90f7310@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  declare variable for 1000.0 and method formatToDoubleValue moved inside class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/02d4c08b..99778d96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=10-11

  Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Jul 22 07:53:25 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 22 Jul 2022 07:53:25 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v11]
In-Reply-To: <OJrJm0zejMokivworR3JyWK1GsUeCsWhzwTmJ6RCAj4=.8a4547e0-41e7-47d6-919a-f5bc4a4f81c2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <OJrJm0zejMokivworR3JyWK1GsUeCsWhzwTmJ6RCAj4=.8a4547e0-41e7-47d6-919a-f5bc4a4f81c2@github.com>
Message-ID: <RbY9n_EZrk5lj4sbIAECqyTYIhJFkrI0TGx3IvU-TG0=.24c5a0a0-b2aa-40c1-a318-fc016f63a1f0@github.com>

On Thu, 21 Jul 2022 11:00:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted ZeroFileSizeCheck file and updated text from 999.0 to 999 in FileSizeCheck file

Declared a variable "baseFileSize to replace 1000.0 value. 
Method formatToDoubleValue has been moved inside class DetailsTableCellRenderer.

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

PR: https://git.openjdk.org/jdk/pull/9327


From dnguyen at openjdk.org  Fri Jul 22 08:02:47 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 22 Jul 2022 08:02:47 GMT
Subject: RFR: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS [v2]
In-Reply-To: <8l-nWO156lyVqJNiypjqDT8nEliZrwTq_UZWpUrHNXU=.a3d4bc70-1955-4317-ae1f-203ecbe47b26@github.com>
References: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
 <8l-nWO156lyVqJNiypjqDT8nEliZrwTq_UZWpUrHNXU=.a3d4bc70-1955-4317-ae1f-203ecbe47b26@github.com>
Message-ID: <rwq2IfRWERKT75mSd3Yhq6tBfRcu6_Sd0Yk8oXMyZNU=.07f96498-6c76-4c2d-bf62-6b6df90bcb7b@github.com>

On Fri, 15 Jul 2022 04:57:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
>> Fixed to get the default selected icon and use that if in case the icon for that state is not set.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

I tested your changes and they work correctly. I noticed that you're replacing the else statement that handles when model is NOT enabled and NOT selected. I thought replacing this with an if would leave out some edge cases, but your fallback icon code seems to cover it. Looks good to me as I don't see any other edge cases and the test works correctly.

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/9481


From psadhukhan at openjdk.org  Fri Jul 22 09:09:00 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 09:09:00 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed [v2]
In-Reply-To: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
Message-ID: <ZJF2N0zGpSdzQm2eFEjn4OxQ1AzTw0tOR0saEK9DkfI=.97e4833e-97d3-4f07-bf7b-bb51161998cd@github.com>

> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
> It seems actionEvent is fired when popup menu is not visible. 
> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTextField.java#L856

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test made for macos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9551/files
  - new: https://git.openjdk.org/jdk/pull/9551/files/d333df8f..0af01364

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9551&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9551&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9551


From psadhukhan at openjdk.org  Fri Jul 22 09:09:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 09:09:03 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed [v2]
In-Reply-To: <X833xff-eTQZS9JeM3pdq2IzVXAHWuxYClYkFcW0UXg=.5d70c38c-6521-4e7b-89a4-941324b65083@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
 <X833xff-eTQZS9JeM3pdq2IzVXAHWuxYClYkFcW0UXg=.5d70c38c-6521-4e7b-89a4-941324b65083@github.com>
Message-ID: <p737tL54scIW_KtcDL8w1hKDwNeehannW3uqKscnEa0=.f614def5-7cdf-4a87-9341-4f0439ec0c58@github.com>

On Thu, 21 Jul 2022 18:04:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test made for macos
>
> test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java line 82:
> 
>> 80:     public static void main(String[] args) throws Exception {
>> 81: 
>> 82:         UIManager.setLookAndFeel("com.apple.laf.AquaLookAndFeel");
> 
> Shouldn't the test be macOS only?

done

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

PR: https://git.openjdk.org/jdk/pull/9551


From psadhukhan at openjdk.org  Fri Jul 22 09:15:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 09:15:47 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/9bae202e..a34eae0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=00-01

  Stats: 34 lines in 1 file changed: 11 ins; 18 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9588.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9588/head:pull/9588

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Fri Jul 22 09:15:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 09:15:48 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB)
In-Reply-To: <ibW__716n99XRk6-jxqMGaFiRFKkEJ8f7s79bKUQrus=.64ea4008-13a1-4959-8cee-eeac0f57d0c9@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <ibW__716n99XRk6-jxqMGaFiRFKkEJ8f7s79bKUQrus=.64ea4008-13a1-4959-8cee-eeac0f57d0c9@github.com>
Message-ID: <mB4RSnRt4bicLMxanY7gG0VYHIBa6mU2GTbiSpSOHPk=.97b4e5f0-804c-41cd-aa5a-9338fe8a7795@github.com>

On Thu, 21 Jul 2022 19:42:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> After applying the fix, I see that the tracker window closes when it reaches the limit, while the progress may be still ongoing for a prolonged period time. It doesn't look right to me.
> 
> I think we can either change this close condition, either fake progress to MAX_INT-1 until we actually reach the end.
> 
> Anyway it seems like a workaround, real solution would be to migrate to long(probably by adding new constructors and methods to keep compatibility).

Yes, the tracker closes when it reaches MAX INT limit 2147483647 since the progress tracking method setProgress() accepts "int". 
We can keep the progress meter at end ie 100% without closing even after reading 2147483647  bytes, till it reaches EOF
or 
we could add new setProgress() method with long as you suggested. I had thought about it but was not sure about the practicality of this scenario, so just thought of addressing by closing the tracker.
Also, InputStream.available() returns an "int" so I guessed filesize > MAX_INT is not supported which is another reason I did not go for "long"

I will update the fix for the former.

> It doesn't have to be a FileInputStream, since ProgressMonitorInputStream accepts InputStream. So we can make a dummy one with no real data backing it.

I tried creating ByteArrayInputStream of 3GB but it fails with NegativeArraySizeException because of overflow so I am not sure if it's possible.

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

PR: https://git.openjdk.org/jdk/pull/9588


From avu at openjdk.org  Fri Jul 22 09:28:50 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 22 Jul 2022 09:28:50 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
In-Reply-To: <kxazPymz6yvpYrrdhxd_mGZtpmi3JOPQDBSPpU3UYUI=.44218d4e-51a0-4306-a093-c466d41c8429@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <kxazPymz6yvpYrrdhxd_mGZtpmi3JOPQDBSPpU3UYUI=.44218d4e-51a0-4306-a093-c466d41c8429@github.com>
Message-ID: <4pjnJcMRkwg_NYs0fjzmqV4wZSYQuKRsIPPHfh19tFM=.a5d99b9f-8cd5-47cf-9682-54bf2a5f2f15@github.com>

On Wed, 20 Jul 2022 11:00:32 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Reuse displaysync thread for subsequent updates
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 32:
> 
>> 30: #import "MTLSurfaceData.h"
>> 31: #import "JNIUtilities.h"
>> 32: #define KEEP_ALIVE_INC 4
> 
> Why only 4?
> Have you experimented with lesser or greater values?

Yes,  4 is enough to not produce extra stops for animations with relatively high frequency (20+ FPS). I've tested it on RenderPerfTest. If you have other scenarios handy I can check them too.

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

PR: https://git.openjdk.org/jdk/pull/9512


From psadhukhan at openjdk.org  Fri Jul 22 09:31:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 09:31:38 GMT
Subject: RFR: 4890041: Remove TAB and Shift TAB from Popup Menu in Motif Look &
 Feel
Message-ID: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>

This is a cleanup of unneeded TAB and Shift TAB keybindings for PopupMenu.selectedWindowInputMapBindings which is consistent with other L&Fs as can be seen here

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1131

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L702

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L806

No regression test added for this code cleanup

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

Commit messages:
 - 4890041: Remove TAB and Shift TAB from Popup Menu in Motif Look & Feel

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

PR: https://git.openjdk.org/jdk/pull/9609


From azvegint at openjdk.org  Fri Jul 22 11:20:47 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Jul 2022 11:20:47 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed [v2]
In-Reply-To: <ZJF2N0zGpSdzQm2eFEjn4OxQ1AzTw0tOR0saEK9DkfI=.97e4833e-97d3-4f07-bf7b-bb51161998cd@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
 <ZJF2N0zGpSdzQm2eFEjn4OxQ1AzTw0tOR0saEK9DkfI=.97e4833e-97d3-4f07-bf7b-bb51161998cd@github.com>
Message-ID: <tW74SA_YnmZQuKz5o-zU7sYlWUFBVBP4pXeHFbsKPYI=.4e1dc34a-6075-430c-9a25-ab7da2e70245@github.com>

On Fri, 22 Jul 2022 09:09:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
>> It seems actionEvent is fired when popup menu is not visible. 
>> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
>> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTextField.java#L856
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test made for macos

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9551


From azvegint at openjdk.org  Fri Jul 22 12:11:48 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Jul 2022 12:11:48 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB)
In-Reply-To: <mB4RSnRt4bicLMxanY7gG0VYHIBa6mU2GTbiSpSOHPk=.97b4e5f0-804c-41cd-aa5a-9338fe8a7795@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <ibW__716n99XRk6-jxqMGaFiRFKkEJ8f7s79bKUQrus=.64ea4008-13a1-4959-8cee-eeac0f57d0c9@github.com>
 <mB4RSnRt4bicLMxanY7gG0VYHIBa6mU2GTbiSpSOHPk=.97b4e5f0-804c-41cd-aa5a-9338fe8a7795@github.com>
Message-ID: <PqwqIAfKs54bXo1RI4oalBx8FvLXeWw8ODwUl3zlrlY=.9dcf09ab-d9eb-49a3-8db5-283ad9cde33b@github.com>

On Fri, 22 Jul 2022 09:11:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Yes, the tracker closes when it reaches MAX INT limit 2147483647 since the progress tracking method setProgress() accepts "int". We can keep the progress meter at end ie 100% without closing even after reading 2147483647 bytes, till it reaches EOF or we could add new setProgress() method with long as you suggested. I had thought about it but was not sure about the practicality of this scenario, so just thought of addressing by closing the tracker. Also, InputStream.available() returns an "int" so I guessed filesize > MAX_INT is not supported which is another reason I did not go for "long"

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/InputStream.html#available()

>Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking, which may be 0, or 0 when end of stream is detected. 


So `InputStream.available()` is not intended to get a real input stream data length.

Maybe we should work with `InputStream.available()` not only in constructor, but in `ProgressMonitorInputStream.read()` methods too, since `available()` value can change during the data read.

For example, we have `FileInputStream` with a 4GB file:

- at the beginning we have MAX INT `available()`
- after 1GB read we still have MAX INT available
but 
- after 3GB read we have 1GB available
- after 4GB read we have 0 available

And we can somehow update progress bar based on this data.

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

PR: https://git.openjdk.org/jdk/pull/9588


From azvegint at openjdk.org  Fri Jul 22 12:15:05 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Jul 2022 12:15:05 GMT
Subject: RFR: 4890041: Remove TAB and Shift TAB from Popup Menu in Motif
 Look & Feel
In-Reply-To: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
References: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
Message-ID: <V2ZjCNp5ZmEkixjS42JRf-UN0FYAQe64CwJJTQBJOmI=.bfb05d6d-bd4b-485e-b3ac-e991c0f62143@github.com>

On Fri, 22 Jul 2022 09:23:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a cleanup of unneeded TAB and Shift TAB keybindings for PopupMenu.selectedWindowInputMapBindings which is consistent with other L&Fs as can be seen here
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L702
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L806
> 
> No regression test added for this code cleanup

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9609


From psadhukhan at openjdk.org  Fri Jul 22 12:22:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Jul 2022 12:22:52 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
Message-ID: <P2aNlmh48sJ_Yf7--SQhPQhGj37BQlDWejk2BWyMGso=.b38ac83c-e70e-4e25-b760-41bb6e6b8cb7@github.com>

On Fri, 22 Jul 2022 09:15:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
>> This is because
>> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
>> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
>> 
>> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
>> 
>> No regression test is added as it involves using filesize of >2GB.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

But it seems in.available() does not change when we read from the stream. For eg, if we read 512 bytes from stream, I would expect (2147483647 -512) bytes but I still see available() returns 2147483647 so this will not work AFICS

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

PR: https://git.openjdk.org/jdk/pull/9588


From azvegint at openjdk.org  Fri Jul 22 13:09:57 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Jul 2022 13:09:57 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
Message-ID: <z-fru6_dhJ6ZhvrwitfY2OZGEKCmQhTzmaIOAgV1ZcM=.284f43e7-fabb-4544-a6db-222b08086724@github.com>

On Fri, 22 Jul 2022 09:15:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
>> This is because
>> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
>> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
>> 
>> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
>> 
>> No regression test is added as it involves using filesize of >2GB.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9588


From azvegint at openjdk.org  Fri Jul 22 13:09:58 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Jul 2022 13:09:58 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <P2aNlmh48sJ_Yf7--SQhPQhGj37BQlDWejk2BWyMGso=.b38ac83c-e70e-4e25-b760-41bb6e6b8cb7@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
 <P2aNlmh48sJ_Yf7--SQhPQhGj37BQlDWejk2BWyMGso=.b38ac83c-e70e-4e25-b760-41bb6e6b8cb7@github.com>
Message-ID: <hAL6MyxDO0JPfION8yLzYKOp_tge2kxV6VVZkw7d98A=.f6ee9726-4e87-43ee-8703-cc920e902e7c@github.com>

On Fri, 22 Jul 2022 12:19:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> But it seems in.available() does not change when we read from the stream. For eg, if we read 512 bytes from stream, I would expect (2147483647 -512) bytes but I still see available() returns 2147483647 so this will not work AFICS

It does, you can play with [this](https://gist.github.com/azvegint/65b30efa2749e5af3fae6a247c344677) and provide large file as argument.

However, frequent calling of `available()` may reduce performance, so I agree with your solution.


> I tried creating ByteArrayInputStream of 3GB but it fails with NegativeArraySizeException because of overflow so I am not sure if it's possible.

You can try something like:

InputStream inputStream = new InputStream() {
    final long SIZE = (long) (Integer.MAX_VALUE * 1.5);
    long read = 0;

    @Override
    public int available() {
        return (int) Math.min(SIZE - read, Integer.MAX_VALUE);
    }

    @Override
    public int read() {
        return (SIZE - read++ > 0) ? 1 : -1;
    }
};

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

PR: https://git.openjdk.org/jdk/pull/9588


From prr at openjdk.org  Fri Jul 22 18:37:15 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 18:37:15 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <oxzE3FbIvMsrq1D_XvYXvWjjP_5XSeYsRb_SvveJzHU=.197ce00c-e651-4b3c-9438-e8e2bf1dacaa@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9496


From duke at openjdk.org  Fri Jul 22 18:41:08 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 22 Jul 2022 18:41:08 GMT
Subject: Integrated: 8286270: [java.desktop] Replace color search in XColors
 with a switch statement
In-Reply-To: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
Message-ID: <fcBcmlLDR6QYyecqEcim1mqwbuKrxSs3QpG7l3v8bDs=.1e620bca-f6dd-430a-8895-4622c73c82ea@github.com>

On Sat, 15 Jan 2022 03:44:17 GMT, SWinxy <duke at openjdk.org> wrote:

> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand.

This pull request has now been integrated.

Changeset: ef8486a1
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef8486a1a40c8b65d3db6048c3dc79802073148d
Stats:     1300 lines in 1 file changed: 508 ins; 784 del; 8 mod

8286270: [java.desktop] Replace color search in XColors with a switch statement

Reviewed-by: prr, azvegint

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

PR: https://git.openjdk.org/jdk/pull/7096


From duke at openjdk.org  Fri Jul 22 18:47:10 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 22 Jul 2022 18:47:10 GMT
Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with
 a switch statement [v4]
In-Reply-To: <mDLPcZ9pmSx9RPx9ev58lCEBBgQr_fAMNPbC5NTXEYs=.b4a853b0-e2f7-4482-ae46-58682e8ec7f7@github.com>
References: <WdcUUlBYTEbTwZy8DZo4PCU-qyGqnOvXiy5A-aRp1A4=.80e0191d-14c1-4bf4-a6fd-d79d158ba71a@github.com>
 <L8uMNlxgA8SNzmMlpbLKX8qvNIWE7s-YIXn5KBpIMuc=.8f29770b-bf7e-485a-93dc-b73dbf0e7755@github.com>
 <mDLPcZ9pmSx9RPx9ev58lCEBBgQr_fAMNPbC5NTXEYs=.b4a853b0-e2f7-4482-ae46-58682e8ec7f7@github.com>
Message-ID: <8PzHcRQ355L35gbk768nQBJ2aEh7ie39LXwnQKNBXoo=.23f2dcb8-4d44-41c7-a0e3-27c545c643f9@github.com>

On Mon, 18 Jul 2022 17:18:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alter XColor documentation
>>   
>>   Let's see if this passes the checks
>
> 1) The test suites are NOT preventing integration
> 2) The tests run here are IRRELEVANT to client changes - NO CLIENT TESTS ARE RUN by GHA. Not a single one.
> If any client tests need to be run you will need to do it yourself
> 3) the sponsor label was removed when I requested changes which you have made since
> It looks to me as if you can just type /integrate again

Awesome! Thanks lots for your help @prrace.

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

PR: https://git.openjdk.org/jdk/pull/7096


From prr at openjdk.org  Fri Jul 22 19:03:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 19:03:04 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
In-Reply-To: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
Message-ID: <M7cubXskcQYIJ_F8i-UfmMRgl2tlZTYUZy6XqmX1Lmk=.f35f88ca-fc05-4b92-928a-43597afedf5d@github.com>

On Fri, 15 Jul 2022 11:32:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Reuse displaysync thread for subsequent updates

Looking at the RenderPerfTest numbers ClipFlatOvalAA went down .. but everything else improved by at the very least a statistically significant amount so why did that one test get worse ?

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

PR: https://git.openjdk.org/jdk/pull/9512


From prr at openjdk.org  Fri Jul 22 19:04:02 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 19:04:02 GMT
Subject: RFR: 6463708: DefaultButtonModel.setMnemonic generates ChangeEvent
 for no change
In-Reply-To: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
References: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
Message-ID: <EXRBC9Ucuy7F7Bv0viMejA0gRnPx_ZJrsVmjhQzhYV0=.d4d25422-2c28-4c95-973c-c487abc78d27@github.com>

On Mon, 18 Jul 2022 08:42:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> For a DefaultButtonModel, setMnemonic() generates a ChangeEvent even if the new value is the same as the old value (that is, even if nothing has changed). 
> Fix is to fire StateChange event only if the value has changed. 
> 
> This is consistent with other places like 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java#L103
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultSingleSelectionModel.java#L79
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultBoundedRangeModel.java#L309

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9536


From prr at openjdk.org  Fri Jul 22 19:09:07 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 19:09:07 GMT
Subject: RFR: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed [v2]
In-Reply-To: <ZJF2N0zGpSdzQm2eFEjn4OxQ1AzTw0tOR0saEK9DkfI=.97e4833e-97d3-4f07-bf7b-bb51161998cd@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
 <ZJF2N0zGpSdzQm2eFEjn4OxQ1AzTw0tOR0saEK9DkfI=.97e4833e-97d3-4f07-bf7b-bb51161998cd@github.com>
Message-ID: <Rw3lEeqYttplAjBCgCgexAeWY7CJyK1xDS06ZxOrif8=.0dd1b7b0-9786-44ef-a6cb-ba2b9c7736be@github.com>

On Fri, 22 Jul 2022 09:09:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
>> It seems actionEvent is fired when popup menu is not visible. 
>> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
>> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTextField.java#L856
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test made for macos

OK .. although the existing code even if it is surprising, looks very deliberate .. which makes me a little leery.
But we've plenty of time in JDK 20 to see if this causes a problem.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9551


From prr at openjdk.org  Fri Jul 22 19:09:58 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 19:09:58 GMT
Subject: RFR: 4890041: Remove TAB and Shift TAB from Popup Menu in Motif
 Look & Feel
In-Reply-To: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
References: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
Message-ID: <W_kI_-Sxt2v-vDUQ4Q3BjH0-BmsWRwb2Pl1os5aS-Bg=.31102c7a-1285-42c4-98fe-56fbdbc85278@github.com>

On Fri, 22 Jul 2022 09:23:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a cleanup of unneeded TAB and Shift TAB keybindings for PopupMenu.selectedWindowInputMapBindings which is consistent with other L&Fs as can be seen here
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L702
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L806
> 
> No regression test added for this code cleanup

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9609


From honkar at openjdk.org  Fri Jul 22 19:12:18 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 22 Jul 2022 19:12:18 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <mvM-GN2-aFxmiJeHnbeMCNZdNG7De1Lmoh7Y_XgNutk=.2d58be37-8dc3-4e86-a1eb-814dc2501532@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Minor suggestion: how about we add index to the comparison?

` {@code (index >= 0 && index <= getTabCount())}` since index adds more clarity to the comparison and additionally to keep it consistent across the JTabbedPane similar to -

https://github.com/openjdk/jdk/blob/ef8486a1a40c8b65d3db6048c3dc79802073148d/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L1089

https://github.com/openjdk/jdk/blob/ef8486a1a40c8b65d3db6048c3dc79802073148d/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L1264

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

PR: https://git.openjdk.org/jdk/pull/9496


From prr at openjdk.org  Fri Jul 22 19:57:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 19:57:04 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
Message-ID: <Q82ffLAlqfjtWLSm4NzlBhz3dMIPyCXGAI91lmeyjT4=.2214c301-a12d-434d-85d0-a72b4b379af7@github.com>

On Fri, 22 Jul 2022 09:15:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
>> This is because
>> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
>> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
>> 
>> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
>> 
>> No regression test is added as it involves using filesize of >2GB.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

It isn't clear to me that this is "better".
Before although it would jump to zero it would continue to increment and so the user would know something is happening. Now it just gets to max and looks "stuck".
So I don't think it should be fixed this way.

If we could find a way to use longs here .. but then there are other problems .. 
The ProgressMonitor usage seems a bit less than ideal to me.
This class bases its estimate of max to pass to ProgressMonitor on InputStream.available().
If it is a real file, then this may be fine .. but available() returns an int .. so I suppose can't tell you the real size of a large file.
If it is any other kind of stream, then the size estimate is perhaps worse than useless.
It must be continually re-evaluating max in such a case ? Right ?

Perhaps that tells us what we should do 

Rather than sitting at max, or jumping back to zero, we can go back to something like
90% .. or 50% .. and so we are signalling we've had to re-evaluate where we are but ar still reading.

BTW I don't see why you need a large file for a test. You can just have an InputStream subclass which keeps generating data ..

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

PR: https://git.openjdk.org/jdk/pull/9588


From prr at openjdk.org  Fri Jul 22 20:21:05 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 20:21:05 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results.
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <9hfoq-KISlellozm7Hya4ft8Cr-nZObZwiopfkc_Bro=.f814479c-9c49-4739-ab65-3daae8f0afcc@github.com>

On Wed, 20 Jul 2022 09:12:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 427:

> 425:             = "The size of the divider.")
> 426:     public void setDividerSize(int newSize) {
> 427:         if (newSize < 0) {

What are the "unexpected results" of < 0 ?
Should it perhaps be 1 ? 
And what about this ?
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#setDividerSize(int)

And we need a CSR ...

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

PR: https://git.openjdk.org/jdk/pull/9566


From prr at openjdk.org  Fri Jul 22 20:35:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 20:35:04 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <Oio8L0XvJUNU9WJkKJRsFli6EUkVDe8hUgCy4vOFh3g=.ac2c19a6-d11a-45ff-9cf6-7c34e87cc526@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
 <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
 <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>
 <Oio8L0XvJUNU9WJkKJRsFli6EUkVDe8hUgCy4vOFh3g=.ac2c19a6-d11a-45ff-9cf6-7c34e87cc526@github.com>
Message-ID: <D7CXLkmYxl9GC4AoLqbovxPebCPHiOvvvIMpZZ59SiI=.96c517ae-224e-48e2-bc6a-c191b60acda7@github.com>

On Thu, 21 Jul 2022 21:31:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> In the recent update the following points are addressed:
>> 
>> - Screen insets are used to account of taskbar position and the placement of the instruction frame at top-left corner
>> - Position option description update
>> 
>> Changes regarding pushing the latest position to window manager are still being evaluated and in progress.
>
> Following is a proposed solution to push the latest position changes to the window manager.
> 
> Robot.waitForIdle() are added between setLocation() and the subsequent getLocation() calls. This ensures any pending location updates are pushed to the window manager before the new location of the frame is in turn used to position the testWindow.
> 
> In multiple test window cases ONLY the test instruction frame and the main/root test window are positioned using `positionTestWindow()`, the rest of the windows are positioned within EDT at test-level.
> 
> **Impact of the proposed fix:** 
> With this change `positionTestWindow()` can no longer be called on EDT at test-level, hence any existing manual tests calling this method on EDT requires changes.
> 
> For example: In this particular test, the following line `PassFailJFrame.positionTestWindow(frame,PassFailJFrame.Position.HORIZONTAL)` should be called after `createAndShowGUI()`
> 
> https://github.com/openjdk/jdk/blob/d333df8ff59c6242171da1a6d02d05e6a8e65c9d/test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java#L75
>  
> 
> public static void positionTestWindow(Window testWindow, Position position) throws AWTException {
> 
>         if (isEventDispatchThread()) {
>             throw new Exception("positionTestWindow() should not be called on EDT");
>         }
> 
>         robot = new Robot();
>         Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
> 
>         if (position.equals(Position.HORIZONTAL)) {
>             SwingUtilities.invokeLater(() -> {
>                 int newX = ((screenSize.width / 2) - frame.getWidth());
>                 frame.setLocation(newX, frame.getY());
>            });
>             // waits until the queue is flushed
>             robot.waitForIdle();
>             robot.delay(300);
> 
>             SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
>                                              frame.getWidth() + 5), frame.getY()));
> 
>         } else if (position.equals(Position.VERTICAL)) {
>             SwingUtilities.invokeLater(() -> {
>                 int newY = ((screenSize.height / 2) - frame.getHeight());
>                 frame.setLocation(frame.getX(), newY);
>             });
> 
>             robot.waitForIdle();
>             robot.delay(300);
> 
>             SwingUtilities.invokeLater(() -> testWindow.setLocation(frame.getX(),
>                                             (frame.getY() + frame.getHeight() + 5)));
> 
>         } else if (position.equals(Position.TOP_LEFT_CORNER)) {
>             SwingUtilities.invokeLater(() -> {
>                 GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment()
>                         .getDefaultScreenDevice().getDefaultConfiguration();
>                 Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
>                 frame.setLocation(screenInsets.left, screenInsets.top);
>             });
> 
>             robot.waitForIdle();
>             robot.delay(300);
> 
>             SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
>                    frame.getWidth() + 5), frame.getY()));
>         }
>     }

We should discuss that impact. 
This method is useful to simplify the logic of individual tests but is it now becoming awkward to use ?
Or is it something that we should have required from the beginning  ?
And why invokeLater and not invokeAndWait ? I'd have expected Later to not work for this case ..

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

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Fri Jul 22 20:44:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 20:44:04 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v7]
In-Reply-To: <yO0Vdm2bdhrp4r_Xzk-UxNICx7WvMOJrPvXCrdhuJew=.31e8e51d-ac23-4641-ac77-d83ec7648f84@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <yO0Vdm2bdhrp4r_Xzk-UxNICx7WvMOJrPvXCrdhuJew=.31e8e51d-ac23-4641-ac77-d83ec7648f84@github.com>
Message-ID: <Ds72XF6O9pXbWkz-psEAjc-qEbTN4etVLFxuM8mh-Yk=.8dc0b8af-0328-421b-b44b-d1dcfe262f75@github.com>

On Mon, 18 Jul 2022 04:54:54 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JLabel and AbstractButton's imageUpdate method description updated

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2152:

> 2150:      * or not an <code>ImageIcon</code> with an <code>Image</code> equal to the
> 2151:      * passed in <code>Image</code>, return <code>false</code>; otherwise it
> 2152:      * will delegate to the super-class.

We should use {@code ..} style here too.

src/java.desktop/share/classes/javax/swing/JLabel.java line 881:

> 879:      * equal to the passed in <code>Image</code>, return <code>false</code>;
> 880:      * otherwise it will delegate to the super-class.
> 881:      *

Hmm. I just noticed this doesn't have any @params .. we should add them since we are here.
I don't think they need to be included in the CSR since it isn't relevant.
Also let's use {@code ..} style since we are completely replacing all the text.

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

PR: https://git.openjdk.org/jdk/pull/9240


From prr at openjdk.org  Fri Jul 22 21:03:25 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 21:03:25 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v7]
In-Reply-To: <E0pDWi1iUz3AMepRb2mu7uUP5WHxm0D2QoghiMf-BBA=.f4833691-c376-4e44-967c-be6c0f34a58b@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <E0pDWi1iUz3AMepRb2mu7uUP5WHxm0D2QoghiMf-BBA=.f4833691-c376-4e44-967c-be6c0f34a58b@github.com>
Message-ID: <lbp4UojRy3zTxlKm8--5_hBOmUbmejvdcxGWdJqDnPM=.d8a1cb2a-3f79-4bc9-a1a5-88f707b5e997@github.com>

On Fri, 8 Jul 2022 08:26:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
>> Java does not honour these key combination in editor.
>> 
>> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove altgraph mapping

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 648:

> 646:      * Name of the <code>Action</code> for moving the caret
> 647:      * to the begin of a line it not at the begin already or
> 648:      * upward one line otherwise.

begin -> beginning (or write start instead)
and I think you mean "if not" not "it not"
Also use {@code Action}
So in all
* Name of the {@code Action} for moving the caret to the beginning of the current line,
* or up to the beginning of the previous line if the caret is already at the beginning of the line.
*

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 657:

> 655:      * to the end of a line if not at the end already
> 656:      * or downward one line otherwise.
> 657:      * @see #getActions

* Name of the {@code Action} for moving the caret to the end of the current line,
* or down to the end of the next line if the caret is already at the end of the line.

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 2089:

> 2087:         @SuppressWarnings("deprecation")
> 2088:         public void actionPerformed(ActionEvent e) {
> 2089:             System.out.println("EndLineDownAction");

remove the println

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 2110:

> 2108: 
> 2109:                         if (magicPosition == null && (direction == SwingConstants.NORTH || direction == SwingConstants.SOUTH)) {
> 2110:                             Rectangle r = (bidiCaret != null) ?

break this line

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

PR: https://git.openjdk.org/jdk/pull/9230


From prr at openjdk.org  Fri Jul 22 21:09:03 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 21:09:03 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <i1j6IdscphAEzQfKKIJ4S-bxpNySfuOAn9HoDvLvkj0=.f149a7f4-c2ba-41a4-bacf-98a61e5035cc@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Like several other tests fixes I don't understand how this improves stability

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

PR: https://git.openjdk.org/jdk/pull/9202


From honkar at openjdk.org  Fri Jul 22 21:34:03 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 22 Jul 2022 21:34:03 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <D7CXLkmYxl9GC4AoLqbovxPebCPHiOvvvIMpZZ59SiI=.96c517ae-224e-48e2-bc6a-c191b60acda7@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
 <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
 <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>
 <Oio8L0XvJUNU9WJkKJRsFli6EUkVDe8hUgCy4vOFh3g=.ac2c19a6-d11a-45ff-9cf6-7c34e87cc526@github.com>
 <D7CXLkmYxl9GC4AoLqbovxPebCPHiOvvvIMpZZ59SiI=.96c517ae-224e-48e2-bc6a-c191b60acda7@github.com>
Message-ID: <m26VF1VjWs40ZnxcpdNFop_Fhx7Y1KXePNVaPRDpedY=.da4e837b-f025-4c8b-8093-834ea289de97@github.com>

On Fri, 22 Jul 2022 20:31:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Following is a proposed solution to push the latest position changes to the window manager.
>> 
>> Robot.waitForIdle() are added between setLocation() and the subsequent getLocation() calls. This ensures any pending location updates are pushed to the window manager before the new location of the frame is in turn used to position the testWindow.
>> 
>> In multiple test window cases ONLY the test instruction frame and the main/root test window are positioned using `positionTestWindow()`, the rest of the windows are positioned within EDT at test-level.
>> 
>> **Impact of the proposed fix:** 
>> With this change `positionTestWindow()` can no longer be called on EDT at test-level, hence any existing manual tests calling this method on EDT requires changes.
>> 
>> For example: In this particular test, the following line `PassFailJFrame.positionTestWindow(frame,PassFailJFrame.Position.HORIZONTAL)` should be called after `createAndShowGUI()`
>> 
>> https://github.com/openjdk/jdk/blob/d333df8ff59c6242171da1a6d02d05e6a8e65c9d/test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java#L75
>>  
>> 
>> public static void positionTestWindow(Window testWindow, Position position) throws AWTException {
>> 
>>         if (isEventDispatchThread()) {
>>             throw new Exception("positionTestWindow() should not be called on EDT");
>>         }
>> 
>>         robot = new Robot();
>>         Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
>> 
>>         if (position.equals(Position.HORIZONTAL)) {
>>             SwingUtilities.invokeLater(() -> {
>>                 int newX = ((screenSize.width / 2) - frame.getWidth());
>>                 frame.setLocation(newX, frame.getY());
>>            });
>>             // waits until the queue is flushed
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>             SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
>>                                              frame.getWidth() + 5), frame.getY()));
>> 
>>         } else if (position.equals(Position.VERTICAL)) {
>>             SwingUtilities.invokeLater(() -> {
>>                 int newY = ((screenSize.height / 2) - frame.getHeight());
>>                 frame.setLocation(frame.getX(), newY);
>>             });
>> 
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>             SwingUtilities.invokeLater(() -> testWindow.setLocation(frame.getX(),
>>                                             (frame.getY() + frame.getHeight() + 5)));
>> 
>>         } else if (position.equals(Position.TOP_LEFT_CORNER)) {
>>             SwingUtilities.invokeLater(() -> {
>>                 GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment()
>>                         .getDefaultScreenDevice().getDefaultConfiguration();
>>                 Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
>>                 frame.setLocation(screenInsets.left, screenInsets.top);
>>             });
>> 
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>             SwingUtilities.invokeLater(() -> testWindow.setLocation((frame.getX() +
>>                    frame.getWidth() + 5), frame.getY()));
>>         }
>>     }
>
> We should discuss that impact. 
> This method is useful to simplify the logic of individual tests but is it now becoming awkward to use ?
> Or is it something that we should have required from the beginning  ?
> And why invokeLater and not invokeAndWait ? I'd have expected Later to not work for this case ..

The interleaving does seem to make the code more complex. And at test-level, it causes some confusion as few method need to called within EDT and few out of EDT. 

I wanted to check if there was a simpler, much clearer approach and evaluate possible options before proceeding.

I might have gone with invokeLater, since we are calling waitForIdle() later  and it waits until the queue is empty. But I think invokeAndWait would be a better option here.

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

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Fri Jul 22 22:55:01 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Jul 2022 22:55:01 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
 <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
Message-ID: <khQg82b9Vyg4tjyTlzLe0tWh90V7luDECEhFZzQStKc=.6d599101-cffb-4190-bdc6-3891eaaeb809@github.com>

On Mon, 11 Jul 2022 10:01:18 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Correct. Now let's suppose that the rendering thread - unblocked at the time - is adding more records such that
> ArrayList needs to grow. Now ArrayList starts relocating its underlying storage array at the time as dispose() returns

First, the only way that list grows is here :
share/classes/sun/font/StrikeCache.java
static void disposeStrike(final FontStrikeDisposer disposer) {
..

rq.flushAndInvokeNow(new Runnable() {
                    public void run() {
                        doDispose(disposer);
                        Disposer.pollRemove();
                    }
                });
..
}

where Disposer.pollRemove() is adding to the ArrayList deferredRecords

This disposeStrike method() is called from the dispose() method in
share/classes/sun/font/FontStrikeDisposer.java

So the ArrayList must have FINISHED "relocating its underlying storage array" BEFORE dispose() returns.

So all the following text you have implying concurrent adds / removes etc etc doesn't make sense to me.

What I can imagine is that the storage change may not yet be visible to the Disposer thread,
or becomes visible as it is in the process of clearing the deferred records.

So the change to use the ConcurrentLinkedDeque would - if it does what I suppose - fix that.
it would ensure all the changes made on the render thread are immediately visible to the dispose thread.
So let's take that change since it can only make things safer

However I don't think you've explained how it leads to the crash.
Your comment " "double-free" is likely with the second free called from one of the dispose() methods"
and the surrounding text again doesn't add up to me. I read you as saying there are two dispose() methods
but there shouldn't be two operating on the same data and the  Strike one is synchronized and ensures
it only frees once .. 

My guess - and the stack trace in the bug perhaps bears this out since it implicates BufImgSurfaceData
- nothing to do with fonts  .. is that this is a non-synchronized dispose() method
allocated from here
0x0000000107afc4e0(0x00007ff636c574a0)
java.lang.Exception
    at java.desktop/sun.java2d.DefaultDisposerRecord.<init>(DefaultDisposerRecord.java:55)
    at java.desktop/sun.java2d.Disposer.addRecord(Disposer.java:107)
    at java.desktop/sun.awt.image.BufImgSurfaceData.initRaster(Native Method)


And DrawRotatedStringUsingRotatedFont.java does cycle through a lot of BufferedImage instances too ..

> Are you implying that test/jdk/java/awt/Graphics2D/DrawString/DisposerTest.java is useless in the headless mode?
> Then I can mark it as headful.

It is useless to test this in headless mode since there is no RenderQueue .. and so this whole scenario never happens
I think it sufficient to make the EXISTING test headful .. the harness will report a failure automatically if there's a crash

Both new tests don't seem needed and the 2nd one doesn't seem to be testing the issue at all ..
as I wrote above we do not run these concurrently and your test does nothing to block the disposer thread.

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

PR: https://git.openjdk.org/jdk/pull/9362


From duke at openjdk.org  Sat Jul 23 08:54:56 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sat, 23 Jul 2022 08:54:56 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v11]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <7ZtS5xbEBg0bsTQns0hqEuDhQDmwwteO91e1M8pIOT0=.5ba8b3c6-f9cf-46bb-9f01-d96866e1b063@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:

  Disable colored outlines on Linux to be able to build with old system Freetype

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/71a6f346..07150fbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=09-10

  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From psadhukhan at openjdk.org  Mon Jul 25 09:46:08 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 25 Jul 2022 09:46:08 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results.
In-Reply-To: <9hfoq-KISlellozm7Hya4ft8Cr-nZObZwiopfkc_Bro=.f814479c-9c49-4739-ab65-3daae8f0afcc@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <9hfoq-KISlellozm7Hya4ft8Cr-nZObZwiopfkc_Bro=.f814479c-9c49-4739-ab65-3daae8f0afcc@github.com>
Message-ID: <6UhkgddZRQuJwKvDaT7iMxWJ06VwweJzECD38CBiZ7Q=.0b943921-3540-42fb-8c71-8f53917ff88d@github.com>

On Fri, 22 Jul 2022 20:19:02 GMT, Phil Race <prr at openjdk.org> wrote:

> What are the "unexpected results" of < 0 ?

Normally, JSplitPane is expected to show 2 components either horizontally or vertically depending on if it is VERTICAL_SPLIT or HORIZONTAL_SPLIT but in case of -ve size, it only shows 1 component which might be construed as unexpected. KeyPress in 1st component if it's JTextArea seems to get lost as nothing is shown.

> Should it perhaps be 1 ?

It could have 3 cases
- set to 0 (it will not have any visible divider)
- set to 1 (it will have least visible divider)
- just return
I initially thought setting it to 0 as by default, the "dividerSize" variable is 0

but now, I think 3rd option of "just return" should be better as then it will fallback to default SplitPane.dividerSize value as L&F set it to some default value like
in Metal L&F it is 10 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1371
in Aqua, it is 9 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java#L847
in Basic L&F, it is 7 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1342

so if we set divider size to -ve and then call getDividerSize() it will return the default L&F specific divider size.

> we need a CSR

Canyou please clarify why? Is it because we are changing the behavior?
But, I guess, all bug fix(es) change the code to "correct" behavior and here also, we are rectifying the behavior without changing any spec/signature. 
I thought a CSR would have been needed if we had returned IAE. Here, I guess we are changing the implementation detail. Should I raise CSR for implementation detail?

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

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Mon Jul 25 09:48:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 25 Jul 2022 09:48:16 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v2]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <vEf9IL2DXeREJ-i5VZXhcrqW4SfhMeHiSX-x_vo1cxM=.6346d001-b068-4917-a547-4851e1c6fa6f@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix to return L&F specific divider size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/40ddca94..758dfb8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=00-01

  Stats: 28 lines in 3 files changed: 18 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Mon Jul 25 10:36:02 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 25 Jul 2022 10:36:02 GMT
Subject: Integrated: 8170794: [macosx] Error when using setDesktopManager on a
 JDesktopPane on MacOS X with Look and Feel Aqua
In-Reply-To: <x67mXpqQ0LoZTxf3DRzpreINeiNnLfncqB2oqFMhOXA=.331c02f9-4e82-4e3f-9a25-38bdde2920d1@github.com>
References: <x67mXpqQ0LoZTxf3DRzpreINeiNnLfncqB2oqFMhOXA=.331c02f9-4e82-4e3f-9a25-38bdde2920d1@github.com>
Message-ID: <pq7bRfXGTXh6KWJKLK0Dy6P8-yrJPLcP2mWXrPEXY20=.64dc4816-23dc-4ef8-8340-76087967fce4@github.com>

On Thu, 7 Jul 2022 11:11:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When we call JDesktopPane.setDesktopManager(new DefaultDesktopManager()) and try to iconify an internalframe, it results in NPE
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
> at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1030)
> at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1489)
> at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
> at javax.swing.JComponent.paint(JComponent.java:1042)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.updateIcon(AquaInternalFrameDockIconUI.java:193)
> at com.apple.laf.AquaInternalFrameDockIconUI$ScaledImageLabel.paint(AquaInternalFrameDockIconUI.java:204)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at javax.swing.JComponent.paint(JComponent.java:1065)
> at javax.swing.JLayeredPane.paint(JLayeredPane.java:586) 
> 
> 
> it seems the RepaintManager.getVolatileOffscreenBuffer() is called with JRootPane component for AquaLookAndFeel because of which SwingUtilities.getWindowAncestor(JRootPane) returns null causing NPE.
> 
> Fixed by adding a null check. The JInternalFrame can be successfully iconized now after setting DesktopManager.

This pull request has now been integrated.

Changeset: d0c365a7
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0c365a7b91de2fdfacdb0e107174549b7a9860e
Stats:     106 lines in 2 files changed: 105 ins; 0 del; 1 mod

8170794: [macosx] Error when using setDesktopManager on a JDesktopPane on MacOS X with Look and Feel Aqua

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9408


From martin.desruisseaux at geomatys.com  Mon Jul 25 12:04:32 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 25 Jul 2022 14:04:32 +0200
Subject: equals inconsistent with hashCode in AffineTransform
Message-ID: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>

Hello

I'm not sure if the pull request below has been noticed, since I have 
not seen evaluation. This is about the equals(Object) method being 
inconsistent with hashCode() in the AffineTransform class. This bug 
prevents the use of AffineTransform as keys in HashMap, unless 
AffineTransform construction is well-controlled or some workaround is 
applied before any use as key.

There is 2 different ways to fix this bug. The one proposed in current 
pull request tries to minimize the behavioral change compared to current 
implementation.

https://github.com/openjdk/jdk/pull/9121

 ??? ??? Martin




From job at kimmeringer.de  Mon Jul 25 12:12:26 2022
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Mon, 25 Jul 2022 14:12:26 +0200
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
Message-ID: <122e722a-c97c-adcf-9e57-d50b6a03e99e@kimmeringer.de>



Am 25.07.2022 um 14:04 schrieb Martin Desruisseaux:

>This bug prevents the use of AffineTransform as keys in HashMap, unless
> AffineTransform construction is well-controlled or some workaround is
> applied before any use as key.

AffineTransform isn't immutable so it can't be used as key in Maps anyway.


Best regards,

Lothar Kimmeringer


From kevin.rushforth at oracle.com  Mon Jul 25 12:20:45 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 25 Jul 2022 05:20:45 -0700
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
Message-ID: <31569beb-4699-1e89-8819-e679b01cc09a@oracle.com>

Your pull request is not yet ready for review (RFR), since it is not 
associated with a JBS bug ID, so it is unlikely that reviewers on this 
list are looking at it. You can file a bug against "Client Libraries" / 
"2d" at https://bugreport.java.com/ (or find a sponsor on this list who 
is willing to file it for you), and then change the title of your PR to 
include that bug ID in the title. See 
https://openjdk.org/guide/#life-of-a-pr for how to format your title.

Once your PR is RFR, you can expect that there will be some discussion 
on it, since you propose to change the implementation of equals, rather 
than limiting your change to the implementation of hashCode.

-- Kevin


On 7/25/2022 5:04 AM, Martin Desruisseaux wrote:
> Hello
>
> I'm not sure if the pull request below has been noticed, since I have 
> not seen evaluation. This is about the equals(Object) method being 
> inconsistent with hashCode() in the AffineTransform class. This bug 
> prevents the use of AffineTransform as keys in HashMap, unless 
> AffineTransform construction is well-controlled or some workaround is 
> applied before any use as key.
>
> There is 2 different ways to fix this bug. The one proposed in current 
> pull request tries to minimize the behavioral change compared to 
> current implementation.
>
> https://github.com/openjdk/jdk/pull/9121
>
> ??? ??? Martin
>
>



From kevin.rushforth at oracle.com  Mon Jul 25 12:29:37 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 25 Jul 2022 05:29:37 -0700
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <122e722a-c97c-adcf-9e57-d50b6a03e99e@kimmeringer.de>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
 <122e722a-c97c-adcf-9e57-d50b6a03e99e@kimmeringer.de>
Message-ID: <42e5e7c8-e0dd-3c25-d00b-442d22ab992a@oracle.com>



On 7/25/2022 5:12 AM, Lothar Kimmeringer wrote:
>
>
> Am 25.07.2022 um 14:04 schrieb Martin Desruisseaux:
>
>> This bug prevents the use of AffineTransform as keys in HashMap, unless
>> AffineTransform construction is well-controlled or some workaround is
>> applied before any use as key.
>
> AffineTransform isn't immutable so it can't be used as key in Maps 
> anyway.

That's not quite right. Mutable object can, and frequently are, used in 
Maps, as long as you don't mutate them while they are in a Map. Without 
commenting on this specific PR, it is still a best practice for hashCode 
and equals to be consistent for mutable objects.

-- Kevin


>
>
> Best regards,
>
> Lothar Kimmeringer



From martin.desruisseaux at geomatys.com  Mon Jul 25 13:32:40 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 25 Jul 2022 15:32:40 +0200
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <31569beb-4699-1e89-8819-e679b01cc09a@oracle.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
 <31569beb-4699-1e89-8819-e679b01cc09a@oracle.com>
Message-ID: <112bf996-92ed-c4ae-179d-f460e23f967a@geomatys.com>

Le 25/07/2022 ? 14:20, Kevin Rushforth a ?crit?:
> (?snip?) You can file a bug against "Client Libraries" / "2d" at 
> https://bugreport.java.com/ (or find a sponsor on this list who is 
> willing to file it for you), and then change the title of your PR to 
> include that bug ID in the title.

I was not aware of this link, I thought that only OpenJDK committers 
could fill bug reports. Thanks for the link, this is done and got 
internal review ID : 9073683.


> Once your PR is RFR, you can expect that there will be some discussion 
> on it, since you propose to change the implementation of equals, 
> rather than limiting your change to the implementation of hashCode.

Yes this is expected. Note that change to equals method can not be 
avoided since current implementation is inconsistent with itself 
(A.equals(A) can return false). About how to make equals consistent with 
hashCode, as said previously there is at least 2 possible ways of doing 
that.

 ??? Martin




From kevin.rushforth at oracle.com  Mon Jul 25 13:46:43 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 25 Jul 2022 06:46:43 -0700
Subject: [External] : Re: equals inconsistent with hashCode in
 AffineTransform
In-Reply-To: <112bf996-92ed-c4ae-179d-f460e23f967a@geomatys.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
 <31569beb-4699-1e89-8819-e679b01cc09a@oracle.com>
 <112bf996-92ed-c4ae-179d-f460e23f967a@geomatys.com>
Message-ID: <5887063b-d76e-c04a-435c-ba5cdad03b8f@oracle.com>



On 7/25/2022 6:32 AM, Martin Desruisseaux wrote:
> Le 25/07/2022 ? 14:20, Kevin Rushforth a ?crit?:
>> (?snip?) You can file a bug against "Client Libraries" / "2d" at 
>> https://bugreport.java.com/? (or find a sponsor on this list who is 
>> willing to file it for you), and then change the title of your PR to 
>> include that bug ID in the title.
>
> I was not aware of this link, I thought that only OpenJDK committers 
> could fill bug reports. Thanks for the link, this is done and got 
> internal review ID : 9073683.

You're welcome. Btw, you can't use this ID in your PR, since the 
internal ID is transient. Once it is transferred to the JDK project in 
JBS it will get a permanent ID that you can use.

>> Once your PR is RFR, you can expect that there will be some 
>> discussion on it, since you propose to change the implementation of 
>> equals, rather than limiting your change to the implementation of 
>> hashCode.
>
> Yes this is expected. Note that change to equals method can not be 
> avoided since current implementation is inconsistent with itself 
> (A.equals(A) can return false). About how to make equals consistent 
> with hashCode, as said previously there is at least 2 possible ways of 
> doing that.

This can be discussed during the review.

-- Kevin



>
> ??? Martin
>
>



From asemenov at openjdk.org  Mon Jul 25 16:31:28 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 25 Jul 2022 16:31:28 GMT
Subject: RFR: 8286313 [macos] Voice over reads the boolean value as null in the
 JTable
Message-ID: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>

I have a Table which is extended from AbstractTableModel with String, integer and Boolean values ( to represent checkbox). When the row is selected Voice over reads the Boolean value as null. 

@azuev-java @mrserb @prrace please review.

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

Commit messages:
 - 8286313 [macos] Voice over reads the boolean value as null in the JTable

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

PR: https://git.openjdk.org/jdk/pull/9629


From philip.race at oracle.com  Mon Jul 25 17:02:51 2022
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 Jul 2022 10:02:51 -0700
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
Message-ID: <325c4002-bf9a-ec80-bbea-e798d4a53ccd@oracle.com>

The PR isn't valid - it isn't using a valid bug id so skara tooling 
hasn't marked it RFR,
so no one has even noticed it ..
Looks to me as if this is an incident ID not a bug id.

-phil.

On 7/25/22 5:04 AM, Martin Desruisseaux wrote:
> Hello
>
> I'm not sure if the pull request below has been noticed, since I have 
> not seen evaluation. This is about the equals(Object) method being 
> inconsistent with hashCode() in the AffineTransform class. This bug 
> prevents the use of AffineTransform as keys in HashMap, unless 
> AffineTransform construction is well-controlled or some workaround is 
> applied before any use as key.
>
> There is 2 different ways to fix this bug. The one proposed in current 
> pull request tries to minimize the behavioral change compared to 
> current implementation.
>
> https://github.com/openjdk/jdk/pull/9121
>
> ??? ??? Martin
>
>



From philip.race at oracle.com  Mon Jul 25 17:13:08 2022
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 Jul 2022 10:13:08 -0700
Subject: equals inconsistent with hashCode in AffineTransform
In-Reply-To: <325c4002-bf9a-ec80-bbea-e798d4a53ccd@oracle.com>
References: <ff573b0d-9df3-825d-3800-99dc4a65971f@geomatys.com>
 <325c4002-bf9a-ec80-bbea-e798d4a53ccd@oracle.com>
Message-ID: <a7c463f0-dcec-84ec-6c1b-da40720b675d@oracle.com>

I see my reply is one of several.
I have moved your incident so it is now a real bug id
https://bugs.openjdk.org/browse/JDK-8290973

Have you read : https://openjdk.org/guide/#fixing-a-bug ?

-phil.

On 7/25/22 10:02 AM, Philip Race wrote:
> The PR isn't valid - it isn't using a valid bug id so skara tooling 
> hasn't marked it RFR,
> so no one has even noticed it ..
> Looks to me as if this is an incident ID not a bug id.
>
> -phil.
>
> On 7/25/22 5:04 AM, Martin Desruisseaux wrote:
>> Hello
>>
>> I'm not sure if the pull request below has been noticed, since I have 
>> not seen evaluation. This is about the equals(Object) method being 
>> inconsistent with hashCode() in the AffineTransform class. This bug 
>> prevents the use of AffineTransform as keys in HashMap, unless 
>> AffineTransform construction is well-controlled or some workaround is 
>> applied before any use as key.
>>
>> There is 2 different ways to fix this bug. The one proposed in 
>> current pull request tries to minimize the behavioral change compared 
>> to current implementation.
>>
>> https://github.com/openjdk/jdk/pull/9121
>>
>> ??? ??? Martin
>>
>>
>



From duke at openjdk.org  Mon Jul 25 17:38:52 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Mon, 25 Jul 2022 17:38:52 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
Message-ID: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>

`AffineTransform.equals(Object)` and `hashCode()` break two contracts:

* `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
* `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.

This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

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

Commit messages:
 - AffineTransform.equals(Object) is sometime inconsistent with itself and with hashCode().

Changes: https://git.openjdk.org/jdk/pull/9121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290973
  Stats: 108 lines in 2 files changed: 100 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9121/head:pull/9121

PR: https://git.openjdk.org/jdk/pull/9121


From duke at openjdk.org  Mon Jul 25 17:38:54 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Mon, 25 Jul 2022 17:38:54 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <v2jTkWax6KoKjXm3ViYAfNAavVduYhzmIN23cJ3Uz78=.d699ec9d-b15f-4c2a-9c27-a1dee63a38f1@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

Hello, this is a reminder for a pull request: in the `AffineTransform` class, `hashCode()` is inconsistent with `equals(Object)`. The problem occurs with NaN and ?0 coefficients. In particular, the problem with zero values prevents the use of `AffineTransorm` as keys in `HashMap`, unless all zero values are forced to the same sign by `AffineTransform` construction or by pre-processing before using an `AffineTransform` instance as a key.

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

PR: https://git.openjdk.org/jdk/pull/9121


From philip.race at oracle.com  Mon Jul 25 17:44:24 2022
From: philip.race at oracle.com (Philip Race)
Date: Mon, 25 Jul 2022 10:44:24 -0700
Subject: RFR: 8290973: In AffineTransform, equals(Object) is inconsistent
 with hashCode()
In-Reply-To: <v2jTkWax6KoKjXm3ViYAfNAavVduYhzmIN23cJ3Uz78=.d699ec9d-b15f-4c2a-9c27-a1dee63a38f1@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
 <v2jTkWax6KoKjXm3ViYAfNAavVduYhzmIN23cJ3Uz78=.d699ec9d-b15f-4c2a-9c27-a1dee63a38f1@github.com>
Message-ID: <5b7b0c3a-6ce4-d0b5-cb50-c0f85c6eac20@oracle.com>

Hardly a "reminder". The PR is just 10 minutes old. Anything before the 
rfr label was added does not count.

-phil.

On 7/25/22 10:38 AM, Martin Desruisseaux wrote:
> On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:
>
>> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
>>
>> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
>> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
>>
>> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.
> Hello, this is a reminder for a pull request: in the `AffineTransform` class, `hashCode()` is inconsistent with `equals(Object)`. The problem occurs with NaN and ?0 coefficients. In particular, the problem with zero values prevents the use of `AffineTransorm` as keys in `HashMap`, unless all zero values are forced to the same sign by `AffineTransform` construction or by pre-processing before using an `AffineTransform` instance as a key.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/9121



From martin.desruisseaux at geomatys.com  Mon Jul 25 19:41:38 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 25 Jul 2022 21:41:38 +0200
Subject: RFR: 8290973: In AffineTransform, equals(Object) is inconsistent
 with hashCode()
In-Reply-To: <5b7b0c3a-6ce4-d0b5-cb50-c0f85c6eac20@oracle.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
 <v2jTkWax6KoKjXm3ViYAfNAavVduYhzmIN23cJ3Uz78=.d699ec9d-b15f-4c2a-9c27-a1dee63a38f1@github.com>
 <5b7b0c3a-6ce4-d0b5-cb50-c0f85c6eac20@oracle.com>
Message-ID: <0d4b9b5e-3f2f-f367-c85c-26ed36595553@geomatys.com>

Hello Phil

Le 25/07/2022 ? 19:44, Philip Race a ?crit?:

> Hardly a "reminder". The PR is just 10 minutes old. Anything before 
> the rfr label was added does not count.
>
Sorry for that noise, but I didn't sent that message today. That message 
was written 14 days ago on GitHub, in reaction to the bot telling me 
that the issue was inactive for 4 weeks and was going to be closed if I 
didn't wrote something. The two last messages from "me" were actually 
sent automatically by some bot, presumably the same one that added the 
"rfr" label.

> Have you read : https://openjdk.org/guide/#fixing-a-bug ?
>
I was not aware of that page. The last time that I contributed, I have 
been told to read https://openjdk.org/contribute/.

 ??? Thanks,

 ??? ??? Martin




From prr at openjdk.org  Mon Jul 25 21:34:44 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 25 Jul 2022 21:34:44 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v2]
In-Reply-To: <vEf9IL2DXeREJ-i5VZXhcrqW4SfhMeHiSX-x_vo1cxM=.6346d001-b068-4917-a547-4851e1c6fa6f@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <vEf9IL2DXeREJ-i5VZXhcrqW4SfhMeHiSX-x_vo1cxM=.6346d001-b068-4917-a547-4851e1c6fa6f@github.com>
Message-ID: <OYzuFuNeGwIDrO8Tb35ISe0XbBSmx1q6hkTAZTGQYJI=.24c62a74-2fe8-4097-b751-247cf990d6cf@github.com>

On Mon, 25 Jul 2022 09:48:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix to return L&F specific divider size

>>we need a CSR

> Canyou please clarify why? Is it because we are changing the behavior?

So instead you propose to change from one un-specified behaviour to another un-specified behaviour ?

It seems to me we should be updating javadoc to say what should happen.
The "just return" sounds good to me .. in javadoc terms that would be "values < 1 are ignored" ..

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

PR: https://git.openjdk.org/jdk/pull/9566


From tr at openjdk.org  Tue Jul 26 04:22:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 26 Jul 2022 04:22:48 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <mvM-GN2-aFxmiJeHnbeMCNZdNG7De1Lmoh7Y_XgNutk=.2d58be37-8dc3-4e86-a1eb-814dc2501532@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <mvM-GN2-aFxmiJeHnbeMCNZdNG7De1Lmoh7Y_XgNutk=.2d58be37-8dc3-4e86-a1eb-814dc2501532@github.com>
Message-ID: <9KnnyA0Qu8gG8L08W1yJbQYlcFEvR5RRSWQGd8D0qGk=.b500324d-bc90-4e0e-8ef5-63b9c2ea6da2@github.com>

On Fri, 22 Jul 2022 19:07:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Minor suggestion: how about we add index to the comparison?
> 
> ` {@code (index >= 0 && index <= getTabCount())}` since index adds more clarity to the comparison and additionally to keep it consistent across the JTabbedPane similar to -
> 
> https://github.com/openjdk/jdk/blob/ef8486a1a40c8b65d3db6048c3dc79802073148d/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L1089
> 
> https://github.com/openjdk/jdk/blob/ef8486a1a40c8b65d3db6048c3dc79802073148d/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L1264

Yeah @honkar-jdk , thank you for noticing it, will update it accordingly.

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

PR: https://git.openjdk.org/jdk/pull/9496


From psadhukhan at openjdk.org  Tue Jul 26 04:37:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 26 Jul 2022 04:37:22 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v3]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <7wuAaNf_Ws-i2JlMhvXiQVOBh7FGECzrX4pkAxx5rGA=.fedd80b3-c61e-482a-a824-85b7b4943954@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Clarify behavior in javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/758dfb8a..a5a9ec88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=01-02

  Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Tue Jul 26 04:48:58 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 26 Jul 2022 04:48:58 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v3]
In-Reply-To: <7wuAaNf_Ws-i2JlMhvXiQVOBh7FGECzrX4pkAxx5rGA=.fedd80b3-c61e-482a-a824-85b7b4943954@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <7wuAaNf_Ws-i2JlMhvXiQVOBh7FGECzrX4pkAxx5rGA=.fedd80b3-c61e-482a-a824-85b7b4943954@github.com>
Message-ID: <SxWE2DTYCBfCJ2cM1rPdyBj99eZm-ubQ5MXqbQNyWjY=.92678e7f-eb85-4155-a414-ae62262a98c9@github.com>

On Tue, 26 Jul 2022 04:37:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify behavior in javadoc

OK. javadoc clarified and CSR raised https://bugs.openjdk.org/browse/JDK-8290992

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

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Tue Jul 26 04:55:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 26 Jul 2022 04:55:44 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v4]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/a5a9ec88..b486ea4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9566


From tr at openjdk.org  Tue Jul 26 05:10:37 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 26 Jul 2022 05:10:37 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v2]
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated as per Review Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9496/files
  - new: https://git.openjdk.org/jdk/pull/9496/files/fe9a41b8..96f77204

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9496


From duke at openjdk.org  Tue Jul 26 05:57:24 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 26 Jul 2022 05:57:24 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v8]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <qWdUVLnfkWUtF5NGTKpfoLUINLnomgam3PbfnYe3IgQ=.8b263989-96b5-4576-9ad1-d94067f1a6e4@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  param added to JLabel's imageUpdate method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/dc11ed65..0bb04e8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=06-07

  Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jul 26 05:57:26 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 26 Jul 2022 05:57:26 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v7]
In-Reply-To: <yO0Vdm2bdhrp4r_Xzk-UxNICx7WvMOJrPvXCrdhuJew=.31e8e51d-ac23-4641-ac77-d83ec7648f84@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <yO0Vdm2bdhrp4r_Xzk-UxNICx7WvMOJrPvXCrdhuJew=.31e8e51d-ac23-4641-ac77-d83ec7648f84@github.com>
Message-ID: <U3SqoMGVTKzEv5Aw_F6kbzDyrBJ6knosj2txCtgED3k=.54406211-4e4f-4416-b73d-d12b23305bef@github.com>

On Mon, 18 Jul 2022 04:54:54 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JLabel and AbstractButton's imageUpdate method description updated

params added for JLabel's imageUpdate method and {@code ...} style used in description.

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

PR: https://git.openjdk.org/jdk/pull/9240


From asotona at openjdk.org  Tue Jul 26 08:32:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Jul 2022 08:32:00 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
Message-ID: <KXflC0s1JhTfM6RXbd-Cnord8y7OMmsLCcl4ixuWGE0=.f8327203-6dba-42d1-9563-e6fa563aa61d@github.com>

On Mon, 27 Jun 2022 09:25:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

ping to keep the PR open

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

PR: https://git.openjdk.org/jdk/pull/8599


From honkar at openjdk.org  Tue Jul 26 16:03:07 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 26 Jul 2022 16:03:07 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v2]
In-Reply-To: <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>
Message-ID: <brpUwBtjkPCKhVDV-pqCxuWu3j1h25feFYbb2h7Pv7c=.9ad2d5bf-5b81-4186-96e3-250d871396f8@github.com>

On Tue, 26 Jul 2022 05:10:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per Review Comments

Marked as reviewed by honkar (Author).

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

PR: https://git.openjdk.org/jdk/pull/9496


From aturbanov at openjdk.org  Tue Jul 26 19:18:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 26 Jul 2022 19:18:24 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v12]
In-Reply-To: <p99ZecQzf7LeUOqUF1IL1GFa8D_MOCOWDthoIFFwiJk=.7c2d22e0-4d46-48a7-a572-b397c90f7310@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <p99ZecQzf7LeUOqUF1IL1GFa8D_MOCOWDthoIFFwiJk=.7c2d22e0-4d46-48a7-a572-b397c90f7310@github.com>
Message-ID: <Wangty3jsRuPVL35oLb5z5X8NaTU3pZMomBf389iCiQ=.fcf3b8b6-1ae4-4944-94fb-8428f6ecfc1a@github.com>

On Fri, 22 Jul 2022 07:50:57 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   declare variable for 1000.0 and method formatToDoubleValue moved inside class

src/java.desktop/share/classes/sun/swing/FilePane.java line 1195:

> 1193:             } else if (value instanceof Long len) {
> 1194:                 if (listViewWindowsStyle) {
> 1195:                     if(len == 0) {

let's add space after `if`

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Tue Jul 26 20:25:13 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 26 Jul 2022 20:25:13 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v8]
In-Reply-To: <qWdUVLnfkWUtF5NGTKpfoLUINLnomgam3PbfnYe3IgQ=.8b263989-96b5-4576-9ad1-d94067f1a6e4@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <qWdUVLnfkWUtF5NGTKpfoLUINLnomgam3PbfnYe3IgQ=.8b263989-96b5-4576-9ad1-d94067f1a6e4@github.com>
Message-ID: <T9Waq2BN5QAD9hV5fTBuOwX4gHJGu89ONeNJgmTIJA0=.53d55aa7-931c-45a3-b404-f55e3b98653c@github.com>

On Tue, 26 Jul 2022 05:57:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   param added to JLabel's imageUpdate method

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9240


From prr at openjdk.org  Tue Jul 26 21:53:00 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 26 Jul 2022 21:53:00 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v4]
In-Reply-To: <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>
Message-ID: <HbybM5ypO3apM0UhS1LICIeNW5fCTs51bLypK9O5lzU=.4b9a8017-c55f-4422-ae1f-0868a5623d3d@github.com>

On Tue, 26 Jul 2022 04:55:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 423:

> 421:      * @implNote Divider sizes < 1 are ignored.
> 422:      *           {@code SplitPane.dividerSize} L&amp;F specific value
> 423:      *           will instead be used.

This isn't the same as ignoring it. Suppose we do
setDividerSize(5);
setDividerSize(-1);

what is the value after both of these - per your ignoring code 5, but per your doc it will be whatever the default was before you started to change it.

I think it sufficient to say it will be ignored and drop the 2nd clause.

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

PR: https://git.openjdk.org/jdk/pull/9566


From duke at openjdk.org  Wed Jul 27 04:31:58 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 27 Jul 2022 04:31:58 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  space added as per review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/99778d96..4dbd5849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Jul 27 04:32:02 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 27 Jul 2022 04:32:02 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v12]
In-Reply-To: <Wangty3jsRuPVL35oLb5z5X8NaTU3pZMomBf389iCiQ=.fcf3b8b6-1ae4-4944-94fb-8428f6ecfc1a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <p99ZecQzf7LeUOqUF1IL1GFa8D_MOCOWDthoIFFwiJk=.7c2d22e0-4d46-48a7-a572-b397c90f7310@github.com>
 <Wangty3jsRuPVL35oLb5z5X8NaTU3pZMomBf389iCiQ=.fcf3b8b6-1ae4-4944-94fb-8428f6ecfc1a@github.com>
Message-ID: <Vuj3Kl1D9VjPgbGvLwJ5owBXNLh2e6wso2zPPNUeZnY=.3140ca01-b381-467e-a6e3-578aa1834637@github.com>

On Tue, 26 Jul 2022 19:14:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   declare variable for 1000.0 and method formatToDoubleValue moved inside class
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1195:
> 
>> 1193:             } else if (value instanceof Long len) {
>> 1194:                 if (listViewWindowsStyle) {
>> 1195:                     if(len == 0) {
> 
> let's add space after `if`

space added.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Wed Jul 27 05:01:02 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 05:01:02 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v5]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <zHb3GOFbcDBpMUm40PGCSJyYmJ6k_dCMc4X7Jmfd1E4=.27dd8b6f-5280-46bc-97f5-9ec46aab0b5f@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Javadoc correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/b486ea4f..beb1f573

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Wed Jul 27 05:05:04 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 05:05:04 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v4]
In-Reply-To: <HbybM5ypO3apM0UhS1LICIeNW5fCTs51bLypK9O5lzU=.4b9a8017-c55f-4422-ae1f-0868a5623d3d@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>
 <HbybM5ypO3apM0UhS1LICIeNW5fCTs51bLypK9O5lzU=.4b9a8017-c55f-4422-ae1f-0868a5623d3d@github.com>
Message-ID: <-6Q3PwJGsIEuC8WWTy9-RQNbW4xNQQLsxOwedaZkCMY=.81034072-2a94-4332-becd-d1442cef341d@github.com>

On Tue, 26 Jul 2022 21:49:21 GMT, Phil Race <prr 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/JSplitPane.java line 423:
> 
>> 421:      * @implNote Divider sizes < 1 are ignored.
>> 422:      *           {@code SplitPane.dividerSize} L&amp;F specific value
>> 423:      *           will instead be used.
> 
> This isn't the same as ignoring it. Suppose we do
> setDividerSize(5);
> setDividerSize(-1);
> 
> what is the value after both of these - per your ignoring code 5, but per your doc it will be whatever the default was before you started to change it.
> 
> I think it sufficient to say it will be ignored and drop the 2nd clause.

Ok. Modified javadoc and CSR

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

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Wed Jul 27 07:29:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 07:29:25 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v3]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <gQwgZoHwexxdVssGUHQ-aL4qU0FOfdvLexH2qM2dy-M=.9f7f2f6f-5ed4-4f5d-ad8b-45581d8c14af@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - Fix
 - Add test
 - Get available data after MAX_INT data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/a34eae0b..a83a28bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=01-02

  Stats: 99 lines in 2 files changed: 95 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9588.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9588/head:pull/9588

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Wed Jul 27 07:31:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 07:31:34 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v4]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <B3LWhsG_5xTm8M27y8R0KmQIhajgmpBtyDtJysl8xVI=.a7b921b3-adba-4662-9ada-ccb7961cb310@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/a83a28bc..eb58aeae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Wed Jul 27 07:33:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 07:33:30 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v5]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <KoTw2nnBWjraQk9DFSda8tQNpTxqH9VLukjulfm0l-U=.26edf1c5-5967-4d1d-a919-0747a332137d@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/eb58aeae..16d5651b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Wed Jul 27 08:08:26 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 08:08:26 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v6]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <U0l3hgKQsLon5mShHc-xzhIxl10HdMoBeqL_SezNEgc=.4c43aaaf-0b98-4ad5-9e75-a84a41fe0087@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/16d5651b..29e5b8c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9588.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9588/head:pull/9588

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Wed Jul 27 08:08:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 08:08:28 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v2]
In-Reply-To: <Q82ffLAlqfjtWLSm4NzlBhz3dMIPyCXGAI91lmeyjT4=.2214c301-a12d-434d-85d0-a72b4b379af7@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <BaIhVOaEtLGjd2W4XR6J-aOFrM4t-gNlIxCFJuBdqTw=.146bf34c-8d21-49f1-b052-95e11b7f16d3@github.com>
 <Q82ffLAlqfjtWLSm4NzlBhz3dMIPyCXGAI91lmeyjT4=.2214c301-a12d-434d-85d0-a72b4b379af7@github.com>
Message-ID: <uTJqtGigLt4I9RV1zFEgDhsLFqhe3Ep8vwtOIelZ7e0=.4b3763eb-37b5-4e53-a24f-39ac77cdd9c1@github.com>

On Fri, 22 Jul 2022 19:54:59 GMT, Phil Race <prr at openjdk.org> wrote:

> Before although it would jump to zero it would continue to increment and so the user would know something is happening. Now it just gets to max and looks "stuck".

Actually, the progressbar will be **blank** as ProgressMonitorInputStream will call `setProgress(nread+=nr)` ie with -ve value due to integer overflow so progress bar will not be 0 but somewhat (-)2147483125 so **we will not see any increment** also in the progressbar till it reaches 0 from such -ve value

I guess it will be weird to jump back from 99% to ~50% and start again in the same progress monitor (not sure if it's possible also as we support int and not long)
so
I modified the fix to recalculate the available size after MAX_INT is read and close the current progress monitor and recreate another progress monitor with recalculated max and show the progress from MAX_INT onwards to EOF.

> BTW I don't see why you need a large file for a test. You can just have an InputStream subclass which keeps generating data ..

I have added a test.

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

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Wed Jul 27 11:22:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 27 Jul 2022 11:22:09 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v7]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <ybl4KTCVOfOK3wGNct6TfsmDHbdh_O8bGej-cOsfDbw=.0e0864e8-2a42-4c6d-97f5-4a51a900f66d@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/29e5b8c5..13a1dd50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/9588


From duke at openjdk.org  Wed Jul 27 14:05:11 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 27 Jul 2022 14:05:11 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
Message-ID: <LQLjKDIJx8jT2AZAekUVnI5ZpTqqzr4WJwCAeDkQV1I=.09518192-53a8-49e9-9dc3-be3a326f0228@github.com>

On Wed, 27 Jul 2022 04:31:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added as per review comment

@prrace @andy-goryachev-oracle Please review the changes.

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

PR: https://git.openjdk.org/jdk/pull/9327


From angorya at openjdk.org  Wed Jul 27 15:26:52 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 27 Jul 2022 15:26:52 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v7]
In-Reply-To: <a7No4K00cvX2DXRaZqunUBn7YOPOZB9q9wOw5_lJ3I0=.961f1d8b-f595-4984-8b4f-10a33ac0db98@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Mzi2VuiVqwdlpT8eHCTiNP1ZfK7anC83f7Td_lj9v8M=.58b90957-651e-454d-a85b-2610a34e2b55@github.com>
 <RjW0-eBwDpxPDUKnu9Z7MKeDRn-OsKJLKqP3B1ozJp8=.37ee0077-9be8-4ba3-967f-26b7e299d046@github.com>
 <wwJjwnTGwzgeu8cUqlGc5NPr01ai9q7qiXHd3YRGmgM=.44056526-521f-45e6-b427-eb33c4a6fe5d@github.com>
 <a7No4K00cvX2DXRaZqunUBn7YOPOZB9q9wOw5_lJ3I0=.961f1d8b-f595-4984-8b4f-10a33ac0db98@github.com>
Message-ID: <jA0AWxi0fujzGJ9hetNJVIHEavTqmNosHZC55vWrwak=.6da1b4c5-6be9-4d44-8cbe-d253c138d8cb@github.com>

On Thu, 21 Jul 2022 06:44:26 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JDK does not do unit tests in this way. There is no place to put it.
>> We do functional "system" level regression tests.
>
> I guess extracting this code to a function won't give much advantage as it is not called from multiple places.

I do not understand how it is possible to develop without unit tests.  

I would test this function with 0, 1, and (N-1, N, N+1) where N is in range of
1000, 1024, 1_000_000, 1024*1024, 1_000_000_000, 1024^3, 1_000_000_000_000, 1024^4.
(I doubt you can create 1TB test file)

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

PR: https://git.openjdk.org/jdk/pull/9327


From angorya at openjdk.org  Wed Jul 27 15:26:56 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 27 Jul 2022 15:26:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
Message-ID: <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>

On Wed, 27 Jul 2022 04:31:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1193:

> 1191:                 setIcon(icon);
> 1192: 
> 1193:             } else if (value instanceof Long len) {

quick question:
can we use pattern matching (value instanceof Long len) here?  won't this create a problem in java8 ?

src/java.desktop/share/classes/sun/swing/FilePane.java line 1205:

> 1203:                 } else {
> 1204:                     double kbVal = formatToDoubleValue(len);
> 1205:                     len = (long)kbVal;

This code still looks sus to me - there is no need to assign len (it goes out of scope pretty quickly) and formatToDoubleValue() should just format and return a formatted String.

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

PR: https://git.openjdk.org/jdk/pull/9327


From angorya at openjdk.org  Wed Jul 27 17:25:59 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 27 Jul 2022 17:25:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
Message-ID: <hNbFrj3XHTxkKOCoxzs71Z_AF-pwCtIXyXPOieXLuy4=.ceee7469-0d08-4023-a256-ff8c1e10b5b4@github.com>

On Wed, 27 Jul 2022 04:31:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1215:

> 1213:                         } else {
> 1214:                             double gbVal = formatToDoubleValue(len);
> 1215:                             text = MessageFormat.format(gigaByteString, gbVal);

should we also handle "{0} TB" cases?

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

PR: https://git.openjdk.org/jdk/pull/9327


From angorya at openjdk.org  Wed Jul 27 17:40:50 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 27 Jul 2022 17:40:50 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
Message-ID: <I02cSxhuu4FbnHR_c1HoxKRP52i3l9FKrF7XrosTz7k=.aca65a08-4e6b-4f19-bb46-323ed8d90a48@github.com>

On Wed, 27 Jul 2022 04:31:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1233:

> 1231: 
> 1232:         public double formatToDoubleValue(long len) {
> 1233:             DecimalFormat df = new DecimalFormat("0.0");

DecimalFormat("0.0") does not provide locale-specific group separator, which may come to play.
for example "1,000 TB"

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Wed Jul 27 18:08:50 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 27 Jul 2022 18:08:50 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
Message-ID: <CspU2k7HJr6vXET1Bw8l5re6J7DuT81i_QphqEIhHyU=.66731952-3781-4446-90e4-8a4cc3b6122f@github.com>

On Wed, 27 Jul 2022 04:31:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added as per review comment

1) Do not check in files - you can generate these at run time and then delete them
2) This also means you don't need the extra level of folder - which should be named something else than the bug id anyway

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

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9327


From naoto at openjdk.org  Wed Jul 27 18:13:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 27 Jul 2022 18:13:34 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
Message-ID: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>

Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

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

Commit messages:
 - Fix 0x25 c2b in IBM864

Changes: https://git.openjdk.org/jdk/pull/9661/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290488
  Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9661/head:pull/9661

PR: https://git.openjdk.org/jdk/pull/9661


From prr at openjdk.org  Wed Jul 27 19:16:52 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 27 Jul 2022 19:16:52 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v2]
In-Reply-To: <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>
Message-ID: <zIg1OcPvdDi3sInmgOa-Svz4NIiNKCzQNuCrkoPWkoA=.f5e87d94-b978-46db-9155-3fc253c621b0@github.com>

On Tue, 26 Jul 2022 05:10:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per Review Comments

src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 726:

> 724:      * @param index the position to insert this new tab
> 725:      *       {@code (index >= 0 && index <= tab count)}
> 726:      *

Now you've made it more like code, except for less like code by changing getTabCount() to tab count.

I suggest
* @param index the position to insert this new tab
* where {@code (index >= 0 && index <= getTabCount())}

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

PR: https://git.openjdk.org/jdk/pull/9496


From iris at openjdk.org  Wed Jul 27 19:19:13 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 27 Jul 2022 19:19:13 GMT
Subject: RFR: 8290488: IBM864 character encoding implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <LbcT88DhJEewWKOSosyd8ihEcZ-06OiVUmCaQq40ICg=.c4b4fa6c-cce9-4f53-8ec0-5a3107d6db68@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9661


From prr at openjdk.org  Wed Jul 27 23:59:44 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 27 Jul 2022 23:59:44 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v4]
In-Reply-To: <-6Q3PwJGsIEuC8WWTy9-RQNbW4xNQQLsxOwedaZkCMY=.81034072-2a94-4332-becd-d1442cef341d@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>
 <HbybM5ypO3apM0UhS1LICIeNW5fCTs51bLypK9O5lzU=.4b9a8017-c55f-4422-ae1f-0868a5623d3d@github.com>
 <-6Q3PwJGsIEuC8WWTy9-RQNbW4xNQQLsxOwedaZkCMY=.81034072-2a94-4332-becd-d1442cef341d@github.com>
Message-ID: <wR8bpqEyCiTHXEsv-CCOJR2U_GQ19_MXdst2hZC7esk=.8b26428e-3789-4ab4-b234-12ff4ff690f1@github.com>

On Wed, 27 Jul 2022 05:01:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JSplitPane.java line 423:
>> 
>>> 421:      * @implNote Divider sizes < 1 are ignored.
>>> 422:      *           {@code SplitPane.dividerSize} L&amp;F specific value
>>> 423:      *           will instead be used.
>> 
>> This isn't the same as ignoring it. Suppose we do
>> setDividerSize(5);
>> setDividerSize(-1);
>> 
>> what is the value after both of these - per your ignoring code 5, but per your doc it will be whatever the default was before you started to change it.
>> 
>> I think it sufficient to say it will be ignored and drop the 2nd clause.
>
> Ok. Modified javadoc and CSR

My apologies, but because I focused on the rest of it, I overlooked you had made this an implNote.
That seems odd. Do you really intend to imply that some other implementation of Java should be allowed
to do something with negative values ? If so that would be a compatibility issue ..

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

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Thu Jul 28 04:07:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 04:07:55 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove implNote tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/beb1f573..ec9429aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Thu Jul 28 04:07:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 04:07:55 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v4]
In-Reply-To: <wR8bpqEyCiTHXEsv-CCOJR2U_GQ19_MXdst2hZC7esk=.8b26428e-3789-4ab4-b234-12ff4ff690f1@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <pzMrm6O545_MRvq7oFIy1h5hVLeCeTB-hrOKombgUEU=.06fbf50d-bc94-4e05-bb8e-10ee68e96456@github.com>
 <HbybM5ypO3apM0UhS1LICIeNW5fCTs51bLypK9O5lzU=.4b9a8017-c55f-4422-ae1f-0868a5623d3d@github.com>
 <-6Q3PwJGsIEuC8WWTy9-RQNbW4xNQQLsxOwedaZkCMY=.81034072-2a94-4332-becd-d1442cef341d@github.com>
 <wR8bpqEyCiTHXEsv-CCOJR2U_GQ19_MXdst2hZC7esk=.8b26428e-3789-4ab4-b234-12ff4ff690f1@github.com>
Message-ID: <hjJnx9icrSDPL9tJuHG0UEf94B9Hn-VN6S9lUYTwOoM=.96cbc03f-dfac-4bd6-8c51-1e60ac6cc59b@github.com>

On Wed, 27 Jul 2022 23:57:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ok. Modified javadoc and CSR
>
> My apologies, but because I focused on the rest of it, I overlooked you had made this an implNote.
> That seems odd. Do you really intend to imply that some other implementation of Java should be allowed
> to do something with negative values ? If so that would be a compatibility issue ..

Yes, actually I was thinking in that sense, as I was not sure if other impl. will allow -ve values and just wanted to mention that our impl dont.
But, I guess as you pointed, we should make it disallowed for all. Modified PR and CSR.

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

PR: https://git.openjdk.org/jdk/pull/9566


From tanksherman27 at gmail.com  Thu Jul 28 05:18:26 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 28 Jul 2022 13:18:26 +0800
Subject: Does AWT always use it's own version of bad_alloc?
Message-ID: <CAP2b4GMsuVy5eqhBgaPb-_vmOgN1AT3501KfZvyJOy1iiHLZJw@mail.gmail.com>

Sorry if this is a bit of a silly question, but does awt.dll on Windows
always use it's own definition of bad_alloc from alloc.h, even if compiled
in debug mode? Or does it use the standard library implementation in
certain configurations? (new operator, etc) Asking since I'm not
particularly well versed with libawt, and the header inclusions are a
little confusing.

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220728/fc2163a3/attachment.htm>

From psadhukhan at openjdk.org  Thu Jul 28 06:48:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 06:48:27 GMT
Subject: Integrated: 8290399: [macos] Aqua LAF does not fire an action event if
 combo box menu is displayed
In-Reply-To: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
References: <aMzdEQX35f5GTOSOI6Uq-gkcGlCE8-1z3H9JJS4IQ5I=.d7fc8199-d092-468c-a3b7-660112719203@github.com>
Message-ID: <3RmlUUlMgoZoUO3OLtdDDQbPIj0FVSERO27dE2FvA0o=.5b0ebc85-0cd7-4186-9641-eb6ae247512e@github.com>

On Tue, 19 Jul 2022 08:13:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the user types Enter in an editable combo box, Aqua LAF fails to fire an action event if the menu is displayed.
> It seems actionEvent is fired when popup menu is not visible. 
> Fix is to make sure ActionEvent is fired irrespective of popup visiblity as is done in other L&F 
> (for ex, in MetalL&F it calls "ENTER", JTextField.notifyAction, where it calls postActionEvent irrespectively)
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTextField.java#L856

This pull request has now been integrated.

Changeset: 93f96d8c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93f96d8c9eb2c7e1579cc99002eefb6bf019742b
Stats:     95 lines in 2 files changed: 93 ins; 2 del; 0 mod

8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed

Reviewed-by: azvegint, prr

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

PR: https://git.openjdk.org/jdk/pull/9551


From tr at openjdk.org  Thu Jul 28 06:51:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 06:51:47 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v3]
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <aqf5fof7vckClyXIqeKzrRsPytmB-5Bp15nDWxWnL2c=.9133e918-bacd-498b-b545-df919d7da43a@github.com>

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9496/files
  - new: https://git.openjdk.org/jdk/pull/9496/files/96f77204..7f3e9302

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9496


From tr at openjdk.org  Thu Jul 28 06:51:50 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 06:51:50 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v2]
In-Reply-To: <zIg1OcPvdDi3sInmgOa-Svz4NIiNKCzQNuCrkoPWkoA=.f5e87d94-b978-46db-9155-3fc253c621b0@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <DcAk9M8fb9CiezzUDMkwdHUEQoomEL7MX1h7nkBMqmQ=.9dd3ba49-795f-43b7-b272-db895c8f4ce7@github.com>
 <zIg1OcPvdDi3sInmgOa-Svz4NIiNKCzQNuCrkoPWkoA=.f5e87d94-b978-46db-9155-3fc253c621b0@github.com>
Message-ID: <7v5Ng_v-RvP1OMSQmaUc22YmA_BbLinGBZcL8of6gRU=.13e1326a-6064-4515-8dab-d7358c6d00e1@github.com>

On Wed, 27 Jul 2022 19:13:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated as per Review Comments
>
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 726:
> 
>> 724:      * @param index the position to insert this new tab
>> 725:      *       {@code (index >= 0 && index <= tab count)}
>> 726:      *
> 
> Now you've made it more like code, except for less like code by changing getTabCount() to tab count.
> 
> I suggest
> * @param index the position to insert this new tab
> * where {@code (index >= 0 && index <= getTabCount())}

Updated @prrace .......

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

PR: https://git.openjdk.org/jdk/pull/9496


From psadhukhan at openjdk.org  Thu Jul 28 08:39:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 08:39:46 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v8]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <0-RBRu4rlGbERo6KF-0KdmNVX7nCGb6rkjbFDWVErcY=.6cc5faf4-9bb1-4c5d-9213-e85c3ff0f151@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/3fa91217..392b415a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=06-07

  Stats: 12 lines in 1 file changed: 4 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Thu Jul 28 08:49:59 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 08:49:59 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v8]
In-Reply-To: <0-RBRu4rlGbERo6KF-0KdmNVX7nCGb6rkjbFDWVErcY=.6cc5faf4-9bb1-4c5d-9213-e85c3ff0f151@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <0-RBRu4rlGbERo6KF-0KdmNVX7nCGb6rkjbFDWVErcY=.6cc5faf4-9bb1-4c5d-9213-e85c3ff0f151@github.com>
Message-ID: <t_S7FM6N02jUKCd51G98YlI3Lig50K-Yb9cKkMxv56U=.79a03689-a7a9-426e-b598-ed6045745c96@github.com>

On Thu, 28 Jul 2022 08:39:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
>> Java does not honour these key combination in editor.
>> 
>> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Modified and CSR added https://bugs.openjdk.org/browse/JDK-8291468

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

PR: https://git.openjdk.org/jdk/pull/9230


From duke at openjdk.org  Thu Jul 28 10:08:24 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 10:08:24 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  creating and deleting test files dynamically

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/4dbd5849..084a82a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=12-13

  Stats: 193 lines in 8 files changed: 107 ins; 86 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 28 10:09:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 10:09:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <CspU2k7HJr6vXET1Bw8l5re6J7DuT81i_QphqEIhHyU=.66731952-3781-4446-90e4-8a4cc3b6122f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <CspU2k7HJr6vXET1Bw8l5re6J7DuT81i_QphqEIhHyU=.66731952-3781-4446-90e4-8a4cc3b6122f@github.com>
Message-ID: <d_Mw0T63psEsYJpe6isU7xVt4UC1PyRPxd2UufKPMHc=.956e348c-f1f2-4b29-93ec-aab5705d92dc@github.com>

On Wed, 27 Jul 2022 18:05:29 GMT, Phil Race <prr at openjdk.org> wrote:

> 1. Do not check in files - you can generate these at run time and then delete them
> 
>     2. This also means you don't need the extra level of folder - which should be named something else than the bug id anyway

Deleted the previously checked in test files. Added the code to create and delete the test files at run time.
FileSizeCheck manual test case file moved outside the folder and kept inside JFileChooser directory. So, there is no extra level of folder now.

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

PR: https://git.openjdk.org/jdk/pull/9327


From tr at openjdk.org  Thu Jul 28 11:56:33 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 11:56:33 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
Message-ID: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>

`DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

Commit messages:
 - Fix : graphics null check
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c7c20661...12511ec1

Changes: https://git.openjdk.org/jdk/pull/9673/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6521141
  Stats: 279 lines in 1 file changed: 121 ins; 0 del; 158 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

PR: https://git.openjdk.org/jdk/pull/9673


From psadhukhan at openjdk.org  Thu Jul 28 12:53:07 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 28 Jul 2022 12:53:07 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>

On Thu, 28 Jul 2022 11:47:03 GMT, Tejesh R <tr at openjdk.org> wrote:

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

I guess exposing no-args public constructor was wrong and it should have been protected from beginning.
Also, please add a testcase.

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 349:

> 347:             info().log(toShortString() +
> 348:                     " Setting clipRect: " + (new Rectangle(x, y, width, height)) +
> 349:                     " New clipRect: " + graphics.getClip());

Why this line change is needed? Probably you have added some tabs..Remove this change and similarly from other logs down below.

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

PR: https://git.openjdk.org/jdk/pull/9673


From tr at openjdk.org  Thu Jul 28 14:42:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 14:42:47 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
Message-ID: <uZhxBvVvsWcgVlrmIxwnLCkEtmISbnwTVnqgRb09j6A=.1fe795f9-1d1e-4f19-b5b1-b905065d79d6@github.com>

On Thu, 28 Jul 2022 12:49:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 349:
> 
>> 347:             info().log(toShortString() +
>> 348:                     " Setting clipRect: " + (new Rectangle(x, y, width, height)) +
>> 349:                     " New clipRect: " + graphics.getClip());
> 
> Why this line change is needed? Probably you have added some tabs..Remove this change and similarly from other logs down below.

I think auto indentation has caused this, will undo these tabs changes.

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

PR: https://git.openjdk.org/jdk/pull/9673


From tr at openjdk.org  Thu Jul 28 14:48:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 14:48:54 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
Message-ID: <YIjNCAUwAcWrix0WLTB25lQ-Dl9vTl1xjZ-Uom7N6Cw=.898ffd6d-fecc-456c-bdd2-e882333d7c26@github.com>

On Thu, 28 Jul 2022 12:50:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess exposing no-args public constructor was wrong and it should have been protected from beginning. Also, please add a testcase.

Yeah, its been used internally by other constructors after setting the `graphics` instances. Exposing it as public causes user to create it without `graphics` been set. I tried modifying it to protected and ran the test, but some html test fails.

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

PR: https://git.openjdk.org/jdk/pull/9673


From kcr at openjdk.org  Thu Jul 28 15:14:32 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 28 Jul 2022 15:14:32 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <YIjNCAUwAcWrix0WLTB25lQ-Dl9vTl1xjZ-Uom7N6Cw=.898ffd6d-fecc-456c-bdd2-e882333d7c26@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
 <YIjNCAUwAcWrix0WLTB25lQ-Dl9vTl1xjZ-Uom7N6Cw=.898ffd6d-fecc-456c-bdd2-e882333d7c26@github.com>
Message-ID: <c5ljvi-pn9NmfZ_kI0ATJrTzfYxmI1bsCYYWzCxzoFo=.1b3f8953-275f-4717-9817-6c999500746a@github.com>

On Thu, 28 Jul 2022 14:45:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> > I guess exposing no-args public constructor was wrong and it should have been protected from beginning. Also, please add a testcase.
> 
> Yeah, its been used internally by other constructors after setting the `graphics` instances. Exposing it as public causes user to create it without `graphics` been set. I tried modifying it to protected and ran the test, but some html test fails.

Even if it hadn't failed the test, you cannot simply change a method, constructor, or field in a public (or protected) class in an exported package from public to protected, since that would be an incompatible API change (at least not without a very compelling reason and a lot of discussion, and even then, probably not).

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

PR: https://git.openjdk.org/jdk/pull/9673


From tr at openjdk.org  Thu Jul 28 15:25:33 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 15:25:33 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <c5ljvi-pn9NmfZ_kI0ATJrTzfYxmI1bsCYYWzCxzoFo=.1b3f8953-275f-4717-9817-6c999500746a@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <lQjUPLB7Zi-LBIK_aGFQRIR06STQu51fBAoCiasoQjI=.9ebf3a32-aa8a-4dbe-bf7a-eda735a6665f@github.com>
 <YIjNCAUwAcWrix0WLTB25lQ-Dl9vTl1xjZ-Uom7N6Cw=.898ffd6d-fecc-456c-bdd2-e882333d7c26@github.com>
 <c5ljvi-pn9NmfZ_kI0ATJrTzfYxmI1bsCYYWzCxzoFo=.1b3f8953-275f-4717-9817-6c999500746a@github.com>
Message-ID: <wKtf5ATDUKhnxFPEYzRcyuG7eKn2R4jYNC145YhXk8k=.de1cc3e0-ed95-49f2-96f0-ba2a88fd892d@github.com>

On Thu, 28 Jul 2022 15:10:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > > I guess exposing no-args public constructor was wrong and it should have been protected from beginning. Also, please add a testcase.
> > 
> > 
> > Yeah, its been used internally by other constructors after setting the `graphics` instances. Exposing it as public causes user to create it without `graphics` been set. I tried modifying it to protected and ran the test, but some html test fails.
> 
> Even if it hadn't failed the test, you cannot simply change a method, constructor, or field in a public (or protected) class in an exported package from public to protected, since that would be an incompatible API change (at least not without a very compelling reason and a lot of discussion, and even then, probably not).

Yeah, sure @kevinrushforth.

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

PR: https://git.openjdk.org/jdk/pull/9673


From angorya at openjdk.org  Thu Jul 28 15:36:49 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 28 Jul 2022 15:36:49 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <I02cSxhuu4FbnHR_c1HoxKRP52i3l9FKrF7XrosTz7k=.aca65a08-4e6b-4f19-bb46-323ed8d90a48@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <I02cSxhuu4FbnHR_c1HoxKRP52i3l9FKrF7XrosTz7k=.aca65a08-4e6b-4f19-bb46-323ed8d90a48@github.com>
Message-ID: <BUjynUK2uNIpYkvWChtodLEhUz-YSvuEcmYRq-iITG8=.c837e08b-ee26-4501-9eea-f686195f2fd2@github.com>

On Wed, 27 Jul 2022 17:37:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1233:
> 
>> 1231: 
>> 1232:         public double formatToDoubleValue(long len) {
>> 1233:             DecimalFormat df = new DecimalFormat("0.0");
> 
> DecimalFormat("0.0") does not provide locale-specific group separator, which may come to play.
> for example "1,000 TB"

also, it always formats numbers to have one decimal point, even for whole numbers (10.0)
is this intended functionality?  should "0.#" be used instead?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 28 16:07:46 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 16:07:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
Message-ID: <HSELFjhjjFNC7LbKjpPAMmG0E-w1AMIbp4BKYVe1hhQ=.aa98c3d7-4726-4925-9a07-b8a524a4e771@github.com>

On Wed, 27 Jul 2022 15:15:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1193:
> 
>> 1191:                 setIcon(icon);
>> 1192: 
>> 1193:             } else if (value instanceof Long len) {
> 
> quick question:
> can we use pattern matching (value instanceof Long len) here?  won't this create a problem in java8 ?

As this don't get back ported to java 8 , so I guess it won't create any problem.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 28 16:11:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 16:11:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <BUjynUK2uNIpYkvWChtodLEhUz-YSvuEcmYRq-iITG8=.c837e08b-ee26-4501-9eea-f686195f2fd2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <I02cSxhuu4FbnHR_c1HoxKRP52i3l9FKrF7XrosTz7k=.aca65a08-4e6b-4f19-bb46-323ed8d90a48@github.com>
 <BUjynUK2uNIpYkvWChtodLEhUz-YSvuEcmYRq-iITG8=.c837e08b-ee26-4501-9eea-f686195f2fd2@github.com>
Message-ID: <lhOdf32gJ3PZECNsHOiszH4Q7Z-xx5Svai5DL4RZggo=.d322fcbd-8bf4-4480-be1c-354adc9f75d1@github.com>

On Thu, 28 Jul 2022 15:32:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1233:
>> 
>>> 1231: 
>>> 1232:         public double formatToDoubleValue(long len) {
>>> 1233:             DecimalFormat df = new DecimalFormat("0.0");
>> 
>> DecimalFormat("0.0") does not provide locale-specific group separator, which may come to play.
>> for example "1,000 TB"
>
> also, it always formats numbers to have one decimal point, even for whole numbers (10.0)
> is this intended functionality?  should "0.#" be used instead?

Group separator may come into picture if file size is in terms of TB, otherwise for files having sizes in bytes , KB, MB and so on will be converted to next higher unit if size > 999.

e.g. 
1000 bytes - 1KB
1000 KB - 1 MB and so on...

So, I guess group separator may not come into play.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 28 16:18:37 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 16:18:37 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <lhOdf32gJ3PZECNsHOiszH4Q7Z-xx5Svai5DL4RZggo=.d322fcbd-8bf4-4480-be1c-354adc9f75d1@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <I02cSxhuu4FbnHR_c1HoxKRP52i3l9FKrF7XrosTz7k=.aca65a08-4e6b-4f19-bb46-323ed8d90a48@github.com>
 <BUjynUK2uNIpYkvWChtodLEhUz-YSvuEcmYRq-iITG8=.c837e08b-ee26-4501-9eea-f686195f2fd2@github.com>
 <lhOdf32gJ3PZECNsHOiszH4Q7Z-xx5Svai5DL4RZggo=.d322fcbd-8bf4-4480-be1c-354adc9f75d1@github.com>
Message-ID: <ajCiFrAa7Cs5Fut4j2NsL2u4oe9wnvcRosn6Ud5ZoYg=.124d876a-8a49-4acd-a6aa-0b45148feede@github.com>

On Thu, 28 Jul 2022 16:09:37 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> also, it always formats numbers to have one decimal point, even for whole numbers (10.0)
>> is this intended functionality?  should "0.#" be used instead?
>
> Group separator may come into picture if file size is in terms of TB, otherwise for files having sizes in bytes , KB, MB and so on will be converted to next higher unit if size > 999.
> 
> e.g. 
> 1000 bytes - 1KB
> 1000 KB - 1 MB and so on...
> 
> So, I guess group separator may not come into play.

> also, it always formats numbers to have one decimal point, even for whole numbers (10.0) is this intended functionality? should "0.#" be used instead?

JFileChooser is not showing one decimal point for whole numbers. 
e.g. 1000 KB file is shown as 1 MB. 

![image](https://user-images.githubusercontent.com/107542245/181587024-b05786c6-2c92-4230-9fb2-bcb5fdda1082.png)

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

PR: https://git.openjdk.org/jdk/pull/9327


From aoqi at openjdk.org  Thu Jul 28 16:18:44 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 28 Jul 2022 16:18:44 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
Message-ID: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>

`vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".

The issue could be reproduced by zero.

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

Commit messages:
 - 8291508: Fix some tests with "requires vm.continuations"

Changes: https://git.openjdk.org/jdk/pull/9677/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291508
  Stats: 4 lines in 4 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9677.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677

PR: https://git.openjdk.org/jdk/pull/9677


From duke at openjdk.org  Thu Jul 28 16:21:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 16:21:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
Message-ID: <X_lUfQM50BdLgWCBZBddAEKhzayn1ymRwCZiCHxr-x0=.b84ec065-026e-457e-9d4e-ef04e78b65d8@github.com>

On Wed, 27 Jul 2022 15:18:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1205:
> 
>> 1203:                 } else {
>> 1204:                     double kbVal = formatToDoubleValue(len);
>> 1205:                     len = (long)kbVal;
> 
> This code still looks sus to me - there is no need to assign len (it goes out of scope pretty quickly) and formatToDoubleValue() should just format and return a formatted String.

As the returned value has been used in comparison with 1000.0 , so returning a double value from formatToDoubleValue().

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jul 28 16:26:51 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 28 Jul 2022 16:26:51 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <hNbFrj3XHTxkKOCoxzs71Z_AF-pwCtIXyXPOieXLuy4=.ceee7469-0d08-4023-a256-ff8c1e10b5b4@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <hNbFrj3XHTxkKOCoxzs71Z_AF-pwCtIXyXPOieXLuy4=.ceee7469-0d08-4023-a256-ff8c1e10b5b4@github.com>
Message-ID: <3i9NhhA9uOwoONVXSWIheUF5nJAWlovGjSWkEy3XYmA=.84130a6d-2245-44b6-86fb-b389be3a0240@github.com>

On Wed, 27 Jul 2022 17:23:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1215:
> 
>> 1213:                         } else {
>> 1214:                             double gbVal = formatToDoubleValue(len);
>> 1215:                             text = MessageFormat.format(gigaByteString, gbVal);
> 
> should we also handle "{0} TB" cases?

Files having "TB" sizes may not be handled now.

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

PR: https://git.openjdk.org/jdk/pull/9327


From tr at openjdk.org  Thu Jul 28 16:34:29 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 16:34:29 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v2]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <_PAcwZSdknneuxMd3uJBGIGXgJPhnpAg4V3IwbsOYzk=.f2a51d22-6010-4f66-b848-b00616d9a215@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Undo of Auto Indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/12511ec1..04d444e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=00-01

  Stats: 152 lines in 1 file changed: 0 ins; 0 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

PR: https://git.openjdk.org/jdk/pull/9673


From honkar at openjdk.org  Thu Jul 28 17:52:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 28 Jul 2022 17:52:39 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
Message-ID: <E5dPfpi59wE54Ol2mNCswnhlbO71e_SD7DMYqrhK4EA=.8db80d6c-b9b2-48ae-bd62-f6538376ceeb@github.com>

On Thu, 21 Jul 2022 00:27:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added screen insets to account for taskbar position, doc changes

Another approach would be to use a [JSplitPane](https://docs.oracle.com/javase/tutorial/uiswing/components/splitpane.html) to have the instruction frame and the main test frame in one window. Left half/top as instruction frame and Right half/ bottom as the main test window and this also provides HORIZONTAL_SPLIT or VERTICAL_SPLIT orientation equivalent to HORIZONTAL and VERTICAL positioning of PassFailJFrame.

Advantage of this approach:
- No need to manually position the instruction frame and then the test window, as it will be one window - JSplitPane 
- Entire window (test + instruction frame) need to be positioned only once.
- With this change, we might no longer need positionTestWindow() method, additionally the framework code will be simple and straightforward.

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

PR: https://git.openjdk.org/jdk/pull/9525


From tr at openjdk.org  Thu Jul 28 17:54:36 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 17:54:36 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v3]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <A_wfRKnKmj3bY6OD_2t9FJWme4F7usEuWWmeKtBSy-M=.b5621a1d-2f76-4355-b402-5fff3d20000e@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/04d444e3..a9dbc1b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=01-02

  Stats: 76 lines in 1 file changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

PR: https://git.openjdk.org/jdk/pull/9673


From tr at openjdk.org  Thu Jul 28 18:08:31 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 28 Jul 2022 18:08:31 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v4]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Removed whitespace error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/a9dbc1b6..bc363443

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=02-03

  Stats: 76 lines in 1 file changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

PR: https://git.openjdk.org/jdk/pull/9673


From prr at openjdk.org  Thu Jul 28 18:15:21 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 28 Jul 2022 18:15:21 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v4]
In-Reply-To: <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>
Message-ID: <7jFj84z3Ga9TmOmjrONunWq8FvrSqzkepEpy-8p61lk=.c6e379a6-d411-4ff6-8e8d-b2e6c132a5d2@github.com>

On Thu, 28 Jul 2022 18:08:31 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed whitespace error

You wrote " The graphics object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. "

which reads a bit like if the user does
DebugGraphics dg = new DebugGraphics();
they must then follow it up with
dg.setGraphics(g);
however there's no such method.

So any DebugGraphics created this way is useless.
You can't use it for debugging 
Making it protected won't prevent mis-use.
Someone could subclass and provide a public no-args constructor and the problem will recur.

The javadoc for the class says :
DebugGraphics objects are rarely created by hand

So likely no one should be doing this.

I'd just add javadoc saying "This constructor should not be called by applications, it
is for internal use only. When called directly it will create an un-usable instance".

The only other thing I can think of is to try to figure out by using
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass())

if it was called from outside DebugGraphics, and if so install some other graphics instead.

something like .. 
if (graphics == null && stackWalker.getCallerClass() != this.class ) {
   BufferedImage bi = new BufferedImage(1,1,BufferedImage.TYPE_INT_RGB);
   graphics = bi.createGraphics();
}

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

PR: https://git.openjdk.org/jdk/pull/9673


From prr at openjdk.org  Thu Jul 28 18:27:51 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 28 Jul 2022 18:27:51 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
Message-ID: <4Q6eWOqovfME193_XucDD47EsBfEK1ZyYO0_A4wwRGA=.7e843d34-2c43-4c30-9a9d-725095fd2312@github.com>

On Thu, 28 Jul 2022 04:07:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implNote tag

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9566


From prr at openjdk.org  Thu Jul 28 20:54:36 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 28 Jul 2022 20:54:36 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v7]
In-Reply-To: <ybl4KTCVOfOK3wGNct6TfsmDHbdh_O8bGej-cOsfDbw=.0e0864e8-2a42-4c6d-97f5-4a51a900f66d@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <ybl4KTCVOfOK3wGNct6TfsmDHbdh_O8bGej-cOsfDbw=.0e0864e8-2a42-4c6d-97f5-4a51a900f66d@github.com>
Message-ID: <r62pBAKJ1HuvunFJmputCDTtwpj6iRFe6uo-YU83zlw=.6754a49c-1265-46e1-887d-b3f62e33678e@github.com>

On Wed, 27 Jul 2022 11:22:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
>> This is because
>> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
>> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
>> 
>> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
>> 
>> No regression test is added as it involves using filesize of >2GB.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/ProgressMonitorInputStream.java line 93:

> 91:         }
> 92:         parentComponent = parentComponent;
> 93:         message = message;

These are both wrong I am sure. You want to assign to this.<var> don't you ? Not update the local var.

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

PR: https://git.openjdk.org/jdk/pull/9588


From prr at openjdk.org  Thu Jul 28 20:57:34 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 28 Jul 2022 20:57:34 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v3]
In-Reply-To: <aqf5fof7vckClyXIqeKzrRsPytmB-5Bp15nDWxWnL2c=.9133e918-bacd-498b-b545-df919d7da43a@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <aqf5fof7vckClyXIqeKzrRsPytmB-5Bp15nDWxWnL2c=.9133e918-bacd-498b-b545-df919d7da43a@github.com>
Message-ID: <6ijY-OBTbT62bM0U4My6R34lVa7bK4MgzCLx63G1-04=.3697644e-80b2-4377-9d7c-230a2f5253f0@github.com>

On Thu, 28 Jul 2022 06:51:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 728:

> 726:      *
> 727:      * @throws IndexOutOfBoundsException if the index is out of range
> 728:      *         {@code (index < 0 || index > tab count)}

I expected you to change this one too !

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

PR: https://git.openjdk.org/jdk/pull/9496


From achung at openjdk.org  Thu Jul 28 21:15:35 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 28 Jul 2022 21:15:35 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v3]
In-Reply-To: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
Message-ID: <0hhffy2SpuysI5bjvTZ1zZM1vQjNcUVWJiNtzzag9yI=.f8eab509-2be9-4934-94d3-231570685c9d@github.com>

> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
> 
> The test is passing on all platforms after this change.

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

  reverted icon change, skipped running test on Aqua L&F

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9436/files
  - new: https://git.openjdk.org/jdk/pull/9436/files/ca002830..8a626c96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=01-02

  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9436.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9436/head:pull/9436

PR: https://git.openjdk.org/jdk/pull/9436


From honkar at openjdk.org  Thu Jul 28 22:05:09 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 28 Jul 2022 22:05:09 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide the previous
 visible tab component
Message-ID: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>

A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.

Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.

Following are the before and after fix screenshots-

![image](https://user-images.githubusercontent.com/95945681/181642658-bc6ccf25-8b62-485e-8128-801331418ce6.png)

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

Commit messages:
 - added summary and removed commented lines
 - JTabbedPane setComponentAt changes

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

PR: https://git.openjdk.org/jdk/pull/9681


From tr at openjdk.org  Fri Jul 29 04:47:37 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 29 Jul 2022 04:47:37 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v4]
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <qAsR9jCF1Dp1TzaDnnu0c6_8Dsr7R4lLFcBrPrUO0bI=.46c9bf65-e04f-491a-af63-cb3738b8d8d4@github.com>

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9496/files
  - new: https://git.openjdk.org/jdk/pull/9496/files/7f3e9302..a3d6ba46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9496&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9496


From tr at openjdk.org  Fri Jul 29 04:47:39 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 29 Jul 2022 04:47:39 GMT
Subject: RFR: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab [v3]
In-Reply-To: <6ijY-OBTbT62bM0U4My6R34lVa7bK4MgzCLx63G1-04=.3697644e-80b2-4377-9d7c-230a2f5253f0@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
 <aqf5fof7vckClyXIqeKzrRsPytmB-5Bp15nDWxWnL2c=.9133e918-bacd-498b-b545-df919d7da43a@github.com>
 <6ijY-OBTbT62bM0U4My6R34lVa7bK4MgzCLx63G1-04=.3697644e-80b2-4377-9d7c-230a2f5253f0@github.com>
Message-ID: <d1UsD3TL5zSKvoopv0K3CYtSRElrQdGa8FDolR8Jecs=.b8272e76-b38b-4378-97e1-6f8fe446b8b8@github.com>

On Thu, 28 Jul 2022 20:54:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 728:
> 
>> 726:      *
>> 727:      * @throws IndexOutOfBoundsException if the index is out of range
>> 728:      *         {@code (index < 0 || index > tab count)}
> 
> I expected you to change this one too !

Updated @prrace .

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

PR: https://git.openjdk.org/jdk/pull/9496


From tr at openjdk.org  Fri Jul 29 05:16:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 29 Jul 2022 05:16:54 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v4]
In-Reply-To: <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>
Message-ID: <PvCJheX4g7NzhFcI9L_g5py0g3D_kGsGwD6sbAgEUg0=.d6dcc2b5-86a1-4920-9471-6a74b44455b5@github.com>

On Thu, 28 Jul 2022 18:08:31 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed whitespace error

> 

Yeah, this looks like a better idea @prrace. I will update the java doc and also will create the BufferedImage graphics from the no-arg constructor. With this we will be warning about the usage of no-arg constructor to user and also handle NPE cases.

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

PR: https://git.openjdk.org/jdk/pull/9673


From swinxythecat at gmail.com  Fri Jul 29 06:25:09 2022
From: swinxythecat at gmail.com (SWinxy)
Date: Fri, 29 Jul 2022 02:25:09 -0400
Subject: Migrating show/hide code to setVisible
Message-ID: <CAPRuVTUksEdw48BRPRvCR9hmkXnQ3n5padPCt-uMoNJjA7DPLQ@mail.gmail.com>

The show() and hide() methods of java.awt.Component have been deprecated
for a long time now (JDK 1.1, 25 years ago), and a substantial bit of code
is duplicated between them?rather unnecessarily. I think that their code
should be merged into the preferred setVisible(boolean) method. The
deprecated show(), hide(), and show(boolean) would call setVisible(boolean)
with the corresponding value. They won't be deprecated for removal.

>From what I can tell, a migration can be done pretty easily. The headache I
imagine can result is with mixing inheritances/overrides. Thoughts?

-SWinxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220729/9b8b9d32/attachment.htm>

From psadhukhan at openjdk.org  Fri Jul 29 11:37:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 29 Jul 2022 11:37:24 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v8]
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <MffVEaVcelIOX62iYehvHzBPLurM8F8RRQNWb79NB3A=.1ad71f5c-d9ca-44ba-a88d-bb4b8097f0af@github.com>

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Rectify assignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9588/files
  - new: https://git.openjdk.org/jdk/pull/9588/files/13a1dd50..1df0d582

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9588&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Fri Jul 29 11:37:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 29 Jul 2022 11:37:27 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v7]
In-Reply-To: <r62pBAKJ1HuvunFJmputCDTtwpj6iRFe6uo-YU83zlw=.6754a49c-1265-46e1-887d-b3f62e33678e@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <ybl4KTCVOfOK3wGNct6TfsmDHbdh_O8bGej-cOsfDbw=.0e0864e8-2a42-4c6d-97f5-4a51a900f66d@github.com>
 <r62pBAKJ1HuvunFJmputCDTtwpj6iRFe6uo-YU83zlw=.6754a49c-1265-46e1-887d-b3f62e33678e@github.com>
Message-ID: <PY8R0dBk5jn2I5T3GMZwcH3RTbguQ7oG7Oo8xEQnOuA=.77d6cf5c-6288-4aec-96a8-f33357005e51@github.com>

On Thu, 28 Jul 2022 20:41:38 GMT, Phil Race <prr 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/ProgressMonitorInputStream.java line 93:
> 
>> 91:         }
>> 92:         parentComponent = parentComponent;
>> 93:         message = message;
> 
> These are both wrong I am sure. You want to assign to this.<var> don't you ? Not update the local var.

Yes. Thanks for pointing out. Updated..

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

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Fri Jul 29 11:40:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 29 Jul 2022 11:40:35 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component
In-Reply-To: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
Message-ID: <cHU2mKahjQKn5zHRk91Z4RTYuj4a-GsiR1-LY37hA6w=.e98f537d-f42f-450c-8f34-a41c4e5d9902@github.com>

On Thu, 28 Jul 2022 21:38:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.
> 
> Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.
> 
> Following are the before and after fix screenshots-
> 
> ![image](https://user-images.githubusercontent.com/95945681/181658303-ff3a7df7-5af6-4e76-a103-45d4d76480c3.png)

src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1603:

> 1601:                 if (this.visComp != null &&
> 1602:                         !this.visComp.equals(component)) {
> 1603:                     // previous component visibility is set to false

It seems `isVisible` is checked before changing the visibility..Should we do it here too?

test/jdk/javax/swing/JTabbedPane/TabbedPaneBug.java line 35:

> 33: /*
> 34:  * @test
> 35:  * @bug 8265586

bugid wrong

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

PR: https://git.openjdk.org/jdk/pull/9681


From tr at openjdk.org  Fri Jul 29 14:24:34 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 29 Jul 2022 14:24:34 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Fix: Java doc modified and Graphics contexts created in null case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/bc363443..22bc13a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=03-04

  Stats: 138 lines in 1 file changed: 11 ins; 121 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

PR: https://git.openjdk.org/jdk/pull/9673


From andy.goryachev at oracle.com  Fri Jul 29 15:15:01 2022
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 29 Jul 2022 15:15:01 +0000
Subject: Migrating show/hide code to setVisible
In-Reply-To: <CAPRuVTUksEdw48BRPRvCR9hmkXnQ3n5padPCt-uMoNJjA7DPLQ@mail.gmail.com>
References: <CAPRuVTUksEdw48BRPRvCR9hmkXnQ3n5padPCt-uMoNJjA7DPLQ@mail.gmail.com>
Message-ID: <BL0PR10MB2948825F5AF240336AD9862DE5999@BL0PR10MB2948.namprd10.prod.outlook.com>

I am afraid that this change will instantly break >80% of all deployed applications.  Same for setSize()/resize().

-andy



From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of SWinxy <swinxythecat at gmail.com>
Date: Thursday, 2022/07/28 at 23:25
To: client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Migrating show/hide code to setVisible
The show() and hide() methods of java.awt.Component have been deprecated for a long time now (JDK 1.1, 25 years ago), and a substantial bit of code is duplicated between them?rather unnecessarily. I think that their code should be merged into the preferred setVisible(boolean) method. The deprecated show(), hide(), and show(boolean) would call setVisible(boolean) with the corresponding value. They won't be deprecated for removal.

>From what I can tell, a migration can be done pretty easily. The headache I imagine can result is with mixing inheritances/overrides. Thoughts?

-SWinxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220729/a51a674c/attachment.htm>

From philip.race at oracle.com  Fri Jul 29 16:45:13 2022
From: philip.race at oracle.com (Philip Race)
Date: Fri, 29 Jul 2022 09:45:13 -0700
Subject: Migrating show/hide code to setVisible
In-Reply-To: <BL0PR10MB2948825F5AF240336AD9862DE5999@BL0PR10MB2948.namprd10.prod.outlook.com>
References: <CAPRuVTUksEdw48BRPRvCR9hmkXnQ3n5padPCt-uMoNJjA7DPLQ@mail.gmail.com>
 <BL0PR10MB2948825F5AF240336AD9862DE5999@BL0PR10MB2948.namprd10.prod.outlook.com>
Message-ID: <89064c0e-a16f-b273-d1bd-f60a97a25cfd@oracle.com>

I'm not sure it would necessarily break things but it is churn (today 
setVisible(boolean) actually calls show(boolean)! )
that doesn't help anything that I can see. We'd still have show() and 
hide() .. so what would it solve ?

FWIW I never really liked that show() and hide() were deprecated.
There nothing wrong with them, but folks were being encouraged
to adopt the Java Beans component model practices so were directed to 
setFoo() and getFoo()

I'd almost consider UN-deprecating them .. but it isn't a priority ..
.. and JavaFX uses show() and hide()

https://openjfx.io/javadoc/17/javafx.graphics/javafx/stage/Window.html#show()

-phil.



On 7/29/22 8:15 AM, Andy Goryachev wrote:
>
> I am afraid that this change will instantly break >80% of all deployed 
> applications.? Same for setSize()/resize().
>
> -andy
>
> *From: *client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf 
> of SWinxy <swinxythecat at gmail.com>
> *Date: *Thursday, 2022/07/28 at 23:25
> *To: *client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
> *Subject: *Migrating show/hide code to setVisible
>
> The show() and hide() methods of java.awt.Component have been 
> deprecated for a long time now (JDK 1.1, 25 years ago), and a 
> substantial bit of code is duplicated between them?rather 
> unnecessarily. I think that their code should be merged into the 
> preferred setVisible(boolean) method. The deprecated show(), hide(), 
> and show(boolean) would call setVisible(boolean) with the 
> corresponding value. They won't be deprecated for removal.
>
> From what I can tell, a migration can be done pretty?easily. The 
> headache I imagine can result?is with mixing inheritances/overrides. 
> Thoughts?
>
> -SWinxy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220729/4019f33c/attachment.htm>

From prr at openjdk.org  Fri Jul 29 16:53:45 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 29 Jul 2022 16:53:45 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
Message-ID: <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>

On Fri, 29 Jul 2022 14:24:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix: Java doc modified and Graphics contexts created in null case

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 87:

> 85:         //  directly.
> 86:         StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 87:         if ((graphics == null) && (walker.getCallerClass() != this.getClass())) {

I don't know if creating a StackWalker is expensive but I think it should be done only if graphics == null

Also the version of getInstance() being called here might throw SecurityException
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getInstance(java.lang.StackWalker.Option)

So you'll need to wrap it in a doPrivileged.

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

PR: https://git.openjdk.org/jdk/pull/9673


From achung at openjdk.org  Fri Jul 29 18:18:03 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 29 Jul 2022 18:18:03 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
Message-ID: <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>

> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
> 
> The test is passing on all platforms after this change.

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

  reverted changes to AquaButtonUI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9436/files
  - new: https://git.openjdk.org/jdk/pull/9436/files/8a626c96..d35a2fd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9436&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9436


From aivanov at openjdk.org  Fri Jul 29 18:31:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 29 Jul 2022 18:31:15 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>

On Thu, 21 Jul 2022 18:31:46 GMT, Tejesh R <tr at openjdk.org> wrote:

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

I wonder if it's possible to create the symbolic link for the tester. Does [Files.html.createSymbolicLink](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#createSymbolicLink(java.nio.file.Path,java.nio.file.Path,java.nio.file.attribute.FileAttribute...)) not work?

It would be much more convenient for the tester and you would open the `JFileChooser` in the directory where you created the target and the link.

It may even be possible to automate the test altogether. If you explicitly set the L&F to Metal, you can use mnemonics and keyboard to select the link inside the directory and verify if `valueChanged` resets the file to `null`.

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

> 747:                             } else {
> 748:                                 chooser.setSelectedFile(null);
> 749:                             }

What about the case where multiselection is enabled? It likely needs updating too.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 32:

> 30:             is valid on ValueChanged property listener.
> 31:    @run main FileChooserSymLinkTest
> 32: */

May I ask to place these tags before the class declaration?

Add the asterisk to each line, like you see in the copyright and other tests.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 45:

> 43: import javax.swing.WindowConstants;
> 44: 
> 45: public class FileChooserSymLinkTest{

Suggestion:

public class FileChooserSymLinkTest {

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 76:

> 74:                 2. Create a Symbolic link targeting the created test directory.
> 75:                     ex : mklink /D c:\\link c:\\target
> 76:                 3. In JFileChooser, navigate to "link" created directed.

?navigate to directory where you created the link. In this example, to C:\ drive.

Please use the capital C: for the drive.

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9597


From aivanov at openjdk.org  Fri Jul 29 18:31:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 29 Jul 2022 18:31:15 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
In-Reply-To: <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
Message-ID: <Cy227uR6Q9jzZe_jiureJYILenkC5nKUQni6a0k1qdY=.aa2e0cae-0329-4376-aafc-7ec36f7b768b@github.com>

On Fri, 29 Jul 2022 18:14:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 749:
> 
>> 747:                             } else {
>> 748:                                 chooser.setSelectedFile(null);
>> 749:                             }
> 
> What about the case where multiselection is enabled? It likely needs updating too.

Are symbolic links to files handled correctly?

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

PR: https://git.openjdk.org/jdk/pull/9597


From prr at openjdk.org  Fri Jul 29 18:52:38 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 29 Jul 2022 18:52:38 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
Message-ID: <87xd8iWEiU8xjdyYFioFUTBx_Dd8yDu8mJG_tbSyWR4=.b7e2d624-90d1-4cfa-996b-542c13920724@github.com>

On Fri, 29 Jul 2022 18:18:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
>> 
>> The test is passing on all platforms after this change.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted changes to AquaButtonUI

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9436


From prr at openjdk.org  Fri Jul 29 20:15:09 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 29 Jul 2022 20:15:09 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
Message-ID: <-srPIdM3RYbMenCDfg4mKzRdbk--0ueP2Ohmy6XsV-I=.900b8130-c941-4814-916c-f3a9a3dd202e@github.com>

On Thu, 21 Jul 2022 00:27:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added screen insets to account for taskbar position, doc changes

I can confirm that on Linux / Gnome with menu bar at the top and
toolbar on the left, that the requested location of 0,0 is not where
the window is placed but if called immediately both getLocation()
and getLocationOnScreen() may report back (0,0) leading to incorrect
positioning of the 2nd window.

Calling Toolkit.sync() isn't enough to ensure it is always correct.
In two runs of the same test code (my code below but without a sleep call) in one
case it then reports (0,0) and in another (74,27) - the actual location.

Calling isVisible() or isShowing() don't help.

The simplest thing that works every time for me is to add a short sleep()
to give time for everything to be processed. I didn't need the Robot.
It works both off and on the EDT.
Not 100% satisfactory as there really ought to be a better way but it seems
much more reliable than what we had and it keeps it easy to use.
I only tried this on Ubuntu 22.04 .. you'll need to test some other platforms 
So just give that a try but do KEEP the insets calculations for the safest results.
import java.awt.*;

public class F {

 public static void main(String[] args) throws Exception {
    //doit();
    EventQueue.invokeAndWait(F::doit);
 }

 public static void doit() {

    Frame f1 = new Frame("Frame 1");
    f1.setSize(300,200);
    f1.setLocation(0,0);
    f1.show();

    Toolkit.getDefaultToolkit().sync();
    try { Thread.sleep(500); } catch (InterruptedException e) {}
    System.out.println("screen location ="+f1.getLocationOnScreen());
    System.out.println("frame location ="+f1.getLocation());
    System.out.println("frame size ="+f1.getSize());

    int f2x = f1.getLocation().x+f1.getWidth();
    int f2y = f1.getY();
    System.out.println("desired frame 2 location = " + f2x + ", "+ f2y);
    Frame f2 = new Frame("Frame 2");
    f2.setSize(200,300);
    f2.setLocation(f2x, f2y);
    f2.show();
    System.out.println("frame 2 location = " + f2.getLocation());
 }
}

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

PR: https://git.openjdk.org/jdk/pull/9525


From dnguyen at openjdk.org  Fri Jul 29 20:34:04 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 29 Jul 2022 20:34:04 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
Message-ID: <l7zwE9wKuxocZGq3A-bSvjWQxaYxKYkrXLt0ZsI10eQ=.e0cd7082-a793-4fc8-aff1-8b7658109c4f@github.com>

On Fri, 29 Jul 2022 18:18:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
>> 
>> The test is passing on all platforms after this change.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted changes to AquaButtonUI

test/jdk/java/awt/image/multiresolution/MultiresolutionIconTest.java line 131:

> 129:     private boolean checkPressedColor(int x, int y, Color ok) {
> 130: 
> 131:         r.mouseMove(x+5, y+5);

What's the purpose of moving the robot mouse move +5 in the x and y directions if the fix is to skip the test in MacOS?

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

PR: https://git.openjdk.org/jdk/pull/9436


From achung at openjdk.org  Fri Jul 29 20:34:04 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 29 Jul 2022 20:34:04 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <l7zwE9wKuxocZGq3A-bSvjWQxaYxKYkrXLt0ZsI10eQ=.e0cd7082-a793-4fc8-aff1-8b7658109c4f@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
 <l7zwE9wKuxocZGq3A-bSvjWQxaYxKYkrXLt0ZsI10eQ=.e0cd7082-a793-4fc8-aff1-8b7658109c4f@github.com>
Message-ID: <9u4zGlNojMg-QsD-1lG8Qjvc6XccaHHEghAPZ5HZKQM=.22bd86f7-2bd5-43c0-82b2-d37e6f405816@github.com>

On Fri, 29 Jul 2022 20:29:17 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted changes to AquaButtonUI
>
> test/jdk/java/awt/image/multiresolution/MultiresolutionIconTest.java line 131:
> 
>> 129:     private boolean checkPressedColor(int x, int y, Color ok) {
>> 130: 
>> 131:         r.mouseMove(x+5, y+5);
> 
> What's the purpose of moving the robot mouse move +5 in the x and y directions if the fix is to skip the test in MacOS?

The test isn't being skipped on macOS, only AquaL&F. The mouse move +5 is a workaround for the test failing on macOS-aarch64 systems because of a cursor zoom on mouse move issue.

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

PR: https://git.openjdk.org/jdk/pull/9436


From dnguyen at openjdk.org  Fri Jul 29 20:43:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 29 Jul 2022 20:43:54 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
Message-ID: <dx5mU05NF2XEdsp0LIq4PAKvz148_X16GvRHY_QnvQ4=.6d7b9e59-84ff-4372-bce0-7870afd64bc5@github.com>

On Fri, 29 Jul 2022 18:18:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
>> 
>> The test is passing on all platforms after this change.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted changes to AquaButtonUI

Marked as reviewed by dnguyen (Author).

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

PR: https://git.openjdk.org/jdk/pull/9436


From dnguyen at openjdk.org  Fri Jul 29 20:43:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 29 Jul 2022 20:43:55 GMT
Subject: RFR: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java [v4]
In-Reply-To: <9u4zGlNojMg-QsD-1lG8Qjvc6XccaHHEghAPZ5HZKQM=.22bd86f7-2bd5-43c0-82b2-d37e6f405816@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
 <9meFZDPqfTN1KFfMY7FobphWiLwxW3vv8DMXLphEcdg=.eb306536-8c5e-4067-98dc-35110cc4c33f@github.com>
 <l7zwE9wKuxocZGq3A-bSvjWQxaYxKYkrXLt0ZsI10eQ=.e0cd7082-a793-4fc8-aff1-8b7658109c4f@github.com>
 <9u4zGlNojMg-QsD-1lG8Qjvc6XccaHHEghAPZ5HZKQM=.22bd86f7-2bd5-43c0-82b2-d37e6f405816@github.com>
Message-ID: <knDOOhZtysd-hYiCCDQrz0FFnBeWFy0Tk5wqNzQhCdo=.406f8d5c-7544-431f-8a55-db7da71df2ab@github.com>

On Fri, 29 Jul 2022 20:31:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/image/multiresolution/MultiresolutionIconTest.java line 131:
>> 
>>> 129:     private boolean checkPressedColor(int x, int y, Color ok) {
>>> 130: 
>>> 131:         r.mouseMove(x+5, y+5);
>> 
>> What's the purpose of moving the robot mouse move +5 in the x and y directions if the fix is to skip the test in MacOS?
>
> The test isn't being skipped on macOS, only AquaL&F. The mouse move +5 is a workaround for the test failing on macOS-aarch64 systems because of a cursor zoom on mouse move issue.

Got it. Poor phrasing on my part; meant Aqua L&F as you mentioned. I was just curious about the additional change to the x & y.

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

PR: https://git.openjdk.org/jdk/pull/9436


From honkar at openjdk.org  Fri Jul 29 21:08:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 29 Jul 2022 21:08:39 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <-srPIdM3RYbMenCDfg4mKzRdbk--0ueP2Ohmy6XsV-I=.900b8130-c941-4814-916c-f3a9a3dd202e@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <-srPIdM3RYbMenCDfg4mKzRdbk--0ueP2Ohmy6XsV-I=.900b8130-c941-4814-916c-f3a9a3dd202e@github.com>
Message-ID: <iDKl3lwfjKcDnfE9tOv8xMBG1xCEVt_dTjvl7MBqc20=.b6d81d15-ca99-43a4-9bf7-3f7322f0edbe@github.com>

On Fri, 29 Jul 2022 20:12:47 GMT, Phil Race <prr at openjdk.org> wrote:

> I can confirm that on Linux / Gnome with menu bar at the top and
> toolbar on the left, that the requested location of 0,0 is not where
> the window is placed but if called immediately both getLocation()

@prrace Thank you for checking it on Linux. Adding a delay would be the best option to get the updated location values in this scenario then.

Another approach that I had in mind was to change PassFailJFrame to use a JSplitPane (single window) for instructions and test window. This way there is no hassle of managing the positioning of 2 windows as described above https://github.com/openjdk/jdk/pull/9525#issuecomment-1198453250

Please let me know your suggestions on JSplitPane approach.

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

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Fri Jul 29 21:13:05 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 29 Jul 2022 21:13:05 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <iDKl3lwfjKcDnfE9tOv8xMBG1xCEVt_dTjvl7MBqc20=.b6d81d15-ca99-43a4-9bf7-3f7322f0edbe@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <-srPIdM3RYbMenCDfg4mKzRdbk--0ueP2Ohmy6XsV-I=.900b8130-c941-4814-916c-f3a9a3dd202e@github.com>
 <iDKl3lwfjKcDnfE9tOv8xMBG1xCEVt_dTjvl7MBqc20=.b6d81d15-ca99-43a4-9bf7-3f7322f0edbe@github.com>
Message-ID: <G9VwPsZNCrXQHyXg5jHd-Hp6n96JnSiSd60Dm1Un1r8=.64fa01a0-4fcd-4a86-8a5c-cca78a723dd7@github.com>

On Fri, 29 Jul 2022 21:04:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Please let me know your suggestions on JSplitPane approach.

I think it very unlikely a JSplitPane would satisfy all test requirements.

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

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Fri Jul 29 21:26:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 29 Jul 2022 21:26:39 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <G9VwPsZNCrXQHyXg5jHd-Hp6n96JnSiSd60Dm1Un1r8=.64fa01a0-4fcd-4a86-8a5c-cca78a723dd7@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <-srPIdM3RYbMenCDfg4mKzRdbk--0ueP2Ohmy6XsV-I=.900b8130-c941-4814-916c-f3a9a3dd202e@github.com>
 <iDKl3lwfjKcDnfE9tOv8xMBG1xCEVt_dTjvl7MBqc20=.b6d81d15-ca99-43a4-9bf7-3f7322f0edbe@github.com>
 <G9VwPsZNCrXQHyXg5jHd-Hp6n96JnSiSd60Dm1Un1r8=.64fa01a0-4fcd-4a86-8a5c-cca78a723dd7@github.com>
Message-ID: <JzVPFgd8HNOItC6GMHJvTxtcBn0WD9jfZzQ6oiBNcpc=.56a42fbc-0107-47df-aec8-dda4645156e9@github.com>

On Fri, 29 Jul 2022 21:10:39 GMT, Phil Race <prr at openjdk.org> wrote:

> > Please let me know your suggestions on JSplitPane approach.
> 
> I think it very unlikely a JSplitPane would satisfy all test requirements.

@prrace Do you mean - a multiple frame test scenario or any other scenario is particular? We could readjust the splits (divider location) based on different test requirements and make the test window optional (if required). 
Currently for the multiple frame scenario - we have a instruction window and a root test frame , the rest of the frames are arranged at test-level.

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

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Fri Jul 29 22:05:40 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 29 Jul 2022 22:05:40 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
Message-ID: <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>

On Thu, 21 Jul 2022 00:27:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added screen insets to account for taskbar position, doc changes

Well .. there surely must be test scenarios where a Frame is required. Perhaps the test moves it, iconifies, needs
a specific size .. expects focus to move in a certain order between components in the frame .. wants to use
heavyweight AWT components .. .in some of these I expect the extra instruction part doesn't matter but you only have to find ONE case where it matters .. then there's the fact you'd have to rewrite all the existing tests. And why a JSplitPane, anyway ? Odd choice. 

I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

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

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Fri Jul 29 23:53:52 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 29 Jul 2022 23:53:52 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
Message-ID: <4Bqqt3ia8gCYIRqhVx0nLbBEhrC7M0IV39VJwjATGCc=.aca6134e-d892-48b7-90b3-644e81a0b64b@github.com>

On Fri, 29 Jul 2022 22:01:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added screen insets to account for taskbar position, doc changes
>
> Well .. there surely must be test scenarios where a Frame is required. Perhaps the test moves it, iconifies, needs
> a specific size .. expects focus to move in a certain order between components in the frame .. wants to use
> heavyweight AWT components .. .in some of these I expect the extra instruction part doesn't matter but you only have to find ONE case where it matters .. then there's the fact you'd have to rewrite all the existing tests. And why a JSplitPane, anyway ? Odd choice. 
> 
> I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

@prrace I do see your point and the broader range of testing requirements that might need to be supported by the test framework in future such as iconifying/ minimizing test frames.

Earlier when I suggested JSplitPane, I was looking it from ease of positioning, disposing and that most of the manual tests had more or less - one instruction frame and one test window which could be achieved using the JSplitPane. I probably missed analyzing the part about broader support of framework for future test cases.

> Another approach would be to use a [JSplitPane](https://docs.oracle.com/javase/tutorial/uiswing/components/splitpane.html) to have the instruction frame and the main test frame as one window. Left half/top as instruction frame and Right half/ bottom as the main test window and this also provides HORIZONTAL_SPLIT or VERTICAL_SPLIT orientation equivalent to HORIZONTAL and VERTICAL positioning of PassFailJFrame.
> 
> Advantage of this approach:
> 
> * No need to manually position the instruction frame and then the test window, as it will be one window - JSplitPane
> * Entire window (test + instruction frame) need to be positioned only once.
> * With this change, we might no longer need positionTestWindow() method, additionally the framework code will be simple and straightforward.

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

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Sat Jul 30 00:28:13 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 30 Jul 2022 00:28:13 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
Message-ID: <VDP6V8PuELQ3JqT5pHV3aa0VdBayUlF5wMcrJJMYQSk=.a09ad2c2-4552-4c26-905d-6ba93e00a27b@github.com>

> A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.
> 
> Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.
> 
> Following are the before and after fix screenshots-
> 
> ![image](https://user-images.githubusercontent.com/95945681/181658303-ff3a7df7-5af6-4e76-a103-45d4d76480c3.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  bug id changed, added isVisible check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9681/files
  - new: https://git.openjdk.org/jdk/pull/9681/files/2a9cd459..ef823ee7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9681&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9681&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9681.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9681/head:pull/9681

PR: https://git.openjdk.org/jdk/pull/9681


From honkar at openjdk.org  Sat Jul 30 00:29:54 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 30 Jul 2022 00:29:54 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <cHU2mKahjQKn5zHRk91Z4RTYuj4a-GsiR1-LY37hA6w=.e98f537d-f42f-450c-8f34-a41c4e5d9902@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
 <cHU2mKahjQKn5zHRk91Z4RTYuj4a-GsiR1-LY37hA6w=.e98f537d-f42f-450c-8f34-a41c4e5d9902@github.com>
Message-ID: <yElNBRXFSX1iOiSD-kGyYgGGl2zaDV8cLC_OHO9W8Ug=.96604f59-2f41-4b0d-82c9-a9089f5d5b3c@github.com>

On Fri, 29 Jul 2022 11:35:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bug id changed, added isVisible check
>
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1603:
> 
>> 1601:                 if (this.visComp != null &&
>> 1602:                         !this.visComp.equals(component)) {
>> 1603:                     // previous component visibility is set to false
> 
> It seems `isVisible` is checked before changing the visibility..Should we do it here too?

I thought it might be redundant since the setVisible() checks for visibility of component within show() and hide(). But to add clarity I have add `isVisible` check.

> test/jdk/javax/swing/JTabbedPane/TabbedPaneBug.java line 35:
> 
>> 33: /*
>> 34:  * @test
>> 35:  * @bug 8265586
> 
> bugid wrong

Updated

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

PR: https://git.openjdk.org/jdk/pull/9681


From alex.andryushkin at corista.com  Thu Jul  7 10:30:44 2022
From: alex.andryushkin at corista.com (Alex Andryushkin)
Date: Thu, 07 Jul 2022 10:30:44 -0000
Subject: Question re -Dsun.java2d.cmm possible available options
Message-ID: <CAP-W_Nu1jP-M-W+fKs15xi0p0EZzHif=OiVqtXsK1j-iMSUWng@mail.gmail.com>

Hello,

I am sorry for the wide distribution or if I am reaching out to the wrong
group.

I am running into issues with using awt/java2d color conversion between ICC
profiles.
It seems to be boiling down to the native library (little-csm) used in
java2d.cmm.lcms by default.
At the same time I think there is an option -Dsun.java2d.cmm defaulting to
sun.java2d.cmm.lcms.LcmsServiceProvider, hence it feels that there could be
other providers, hopefully not dependent on little-csm. But I was not able
to find any.

Question: Are there known alternatives to
sun.java2d.cmm.lcms.LcmsServiceProvider, which can be used as an override,
with -Dsun.java2d.cmm option. Preferably a pure-java implementation, even
though it will be slower.

Thank you,
~ Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220707/d39e78d2/attachment.htm>