From alanb at openjdk.java.net  Tue Jun  1 12:50:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 12:50:29 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <dVFpffOKyZHh8laXoFtu1wOUx8nLCS9d12qsoSUE5Bk=.632c4211-41df-40b4-8e07-ee8c3cb249f5@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the  middle of the declaration?

The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message.

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

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

From weijun at openjdk.java.net  Tue Jun  1 15:06:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:06:41 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v7]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <DSVYh67KJe9RW8wMcOpG0R8F4Jx4HYzwW66XEV-EH1w=.cb0b76eb-c433-4ed1-bf62-e227082768f3@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  rename setSecurityManagerDirect to implSetSecurityManager

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06

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

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

From weijun at openjdk.java.net  Tue Jun  1 15:21:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:21:33 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From alanb at openjdk.java.net  Tue Jun  1 16:05:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 16:05:29 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <M0Mj0BK_4OBlu3dwDgSWnaM8KDpkL0KxAJldFL7q-eY=.31a0aa64-5a69-42df-bf80-09b4e7a3c144@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

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

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

From joehw at openjdk.java.net  Tue Jun  1 16:28:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Jun 2021 16:28:27 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <rwSPwilSFt5efKcqrbureXYq8SmLxHMgrE_psXV-S9A=.87124c9e-112f-4a4e-80de-26bfa32fa995@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

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

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

From serb at openjdk.java.net  Wed Jun  2 01:56:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 2 Jun 2021 01:56:36 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the JPasswordField
Message-ID: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>

...placeholder...

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

Commit messages:
 - Update JPasswordField.java
 - Update JPasswordField.java

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

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

From trebari at openjdk.java.net  Wed Jun  2 07:34:30 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 2 Jun 2021 07:34:30 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <HgXu62t1SB1AX7hSrVZXZtQM-1UK5efKQq9LMTouHWU=.54c973d3-5bff-4985-a603-4b804105ae31@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

Marked as reviewed by trebari (Committer).

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

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

From weijun at openjdk.java.net  Wed Jun  2 12:01:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:30 GMT
Subject: <Swing Dev> RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v9]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <HOkSwSOf7m0eP71_pjxacSX3FnXw8CbONP_DbY0mCno=.969b9543-c6d1-4001-afac-d8cb337fd60f@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Wed Jun  2 12:01:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:33 GMT
Subject: <Swing Dev> Integrated: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <PsbFcEhvCahb4zpsvIhOlxvAbJK7DTE3-umT3Nsn5dY=.fe038b5f-dc17-4d4f-a19b-ed8c238c7d58@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

This pull request has now been integrated.

Changeset: 6765f902
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats:     2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

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

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

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:38 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:38 GMT
Subject: <Swing Dev> RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <PSyJvVFJ9ZdvF7KLSUwpd2ZUNj_zgTnlnfb894o0s2M=.3d72b382-7e1c-45b4-b704-541e57dfab0e@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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

From azvegint at openjdk.java.net  Wed Jun  2 13:11:31 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 2 Jun 2021 13:11:31 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <VmtDePIGuf1k40nGrL6JsJLA3uD3JvPDtTtp6PQFAOo=.b9f4f998-c2d6-494c-98c9-0bafcb36710d@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

Marked as reviewed by azvegint (Reviewer).

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

> 66:  * handling confidential information such as the password text, refer to the
> 67:  * relevant section at
> 68:  * <a href="https://www.oracle.com/java/technologies/javase/seccodeguide.html">

We might want to use the link with an anchor to the specific section, e.g.:
https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-2

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

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

From weijun at openjdk.java.net  Wed Jun  2 15:40:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:40:55 GMT
Subject: <Swing Dev> RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v4]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <iWLNwxV2CvTVXj57-NbeWHor64Ab3P7461jOk1XxoJ0=.91556668-25eb-40b4-afae-730f9c1d621f@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

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

  8267521: Post JEP 411 refactoring: maximum covering > 50K

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

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

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

From weijun at openjdk.java.net  Wed Jun  2 15:51:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:33 GMT
Subject: <Swing Dev> Integrated: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <zkd_bofYu1MISkzzGFuI8utKnvp_M7M4icu-ws3be7k=.d7621e87-5890-492f-a64a-187e1f9eb9ed@github.com>

On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 508cec75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats:     245 lines in 18 files changed: 140 ins; 39 del; 66 mod

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

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

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

From serb at openjdk.java.net  Wed Jun  2 23:52:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 2 Jun 2021 23:52:36 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <J0dP0uvkSKmwwWbAYVDBko_Rb0qi5WNLlCwGpAJa6EY=.d7a12c89-bf8c-42ce-9e7b-82b717fc504d@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

The CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8268149
Please take a look.

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

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

From prr at openjdk.java.net  Thu Jun  3 00:19:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 00:19:36 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

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

> 62:  * <p>
> 63:  * <strong>Warning:</strong> The text entered in {@code JPasswordField} displays
> 64:  * something that was typed and does not show the original characters. This

"something that was typed" ? That reads to me as if it displays the characters you typed which isn't what you mean

the whole sentence is weird

Let's change this to
Although the text displayed in {@code JPasswordField} does not show the actual password characters typed,  this does not prevent ...

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

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

From serb at openjdk.java.net  Thu Jun  3 00:34:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 00:34:36 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
Message-ID: <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>

On Thu, 3 Jun 2021 00:16:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some useful documentation was added to the JPasswordField.
>
> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 64:
> 
>> 62:  * <p>
>> 63:  * <strong>Warning:</strong> The text entered in {@code JPasswordField} displays
>> 64:  * something that was typed and does not show the original characters. This
> 
> "something that was typed" ? That reads to me as if it displays the characters you typed which isn't what you mean
> 
> the whole sentence is weird
> 
> Let's change this to
> Although the text displayed in {@code JPasswordField} does not show the actual password characters typed,  this does not prevent ...

The "something was typed" text is used already in the description of the JPasswordField, in the first sentence.

Not sure that the word "text" in the "Although the text displayed" is the correct one. It is not necessary a "text" but "something"

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

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

From prr at openjdk.java.net  Thu Jun  3 00:48:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 00:48:37 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
Message-ID: <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>

On Thu, 3 Jun 2021 00:31:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 64:
>> 
>>> 62:  * <p>
>>> 63:  * <strong>Warning:</strong> The text entered in {@code JPasswordField} displays
>>> 64:  * something that was typed and does not show the original characters. This
>> 
>> "something that was typed" ? That reads to me as if it displays the characters you typed which isn't what you mean
>> 
>> the whole sentence is weird
>> 
>> Let's change this to
>> Although the text displayed in {@code JPasswordField} does not show the actual password characters typed,  this does not prevent ...
>
> The "something was typed" text is used already in the description of the JPasswordField, in the first sentence.
> 
> Not sure that the word "text" in the "Although the text displayed" is the correct one. It is not necessary a "text" but "something"

The previous text you refer to is presumably
"where the view indicates  something was typed,"

that is fine. Your text is trying to say something else AND you added the word that which means you are referring to the specific thing .. 

So you can't just copy and edit that.

And "text" in my version is fine.

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

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

From prr at openjdk.java.net  Thu Jun  3 00:48:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 00:48:37 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
Message-ID: <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>

On Thu, 3 Jun 2021 00:45:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> The "something was typed" text is used already in the description of the JPasswordField, in the first sentence.
>> 
>> Not sure that the word "text" in the "Although the text displayed" is the correct one. It is not necessary a "text" but "something"
>
> The previous text you refer to is presumably
> "where the view indicates  something was typed,"
> 
> that is fine. Your text is trying to say something else AND you added the word that which means you are referring to the specific thing .. 
> 
> So you can't just copy and edit that.
> 
> And "text" in my version is fine.

So in case that wasn't clear, please change it to ny version

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

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

From prr at openjdk.java.net  Thu Jun  3 00:59:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 00:59:37 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
 <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
Message-ID: <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>

On Thu, 3 Jun 2021 00:46:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> The previous text you refer to is presumably
>> "where the view indicates  something was typed,"
>> 
>> that is fine. Your text is trying to say something else AND you added the word that which means you are referring to the specific thing .. 
>> 
>> So you can't just copy and edit that.
>> 
>> And "text" in my version is fine.
>
> So in case that wasn't clear, please change it to ny version

Another way of phrasing it would be 

The text displayed in {@code JPasswordField} shows you that something was typed but does not show the original characters.

Note "that something" not "something that" and the rest of the rephrasing matters too.

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

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

From serb at openjdk.java.net  Thu Jun  3 01:05:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 01:05:38 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
 <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
 <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>
Message-ID: <NK_-GMuUhsrOICOAMok9eyrcRiY29PeAXTcR7QcCzQI=.5bc93e3f-7a6f-4456-b20e-4d336a8b4543@github.com>

On Thu, 3 Jun 2021 00:57:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> So in case that wasn't clear, please change it to ny version
>
> Another way of phrasing it would be 
> 
> The text displayed in {@code JPasswordField} shows you that something was typed but does not show the original characters.
> 
> Note "that something" not "something that" and the rest of the rephrasing matters too.

I do not like the phrase "Although the text displayed in", the "text" is not displayed in the JPasswordField per se, please suggest something else.

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

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

From serb at openjdk.java.net  Thu Jun  3 01:26:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 01:26:35 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <NK_-GMuUhsrOICOAMok9eyrcRiY29PeAXTcR7QcCzQI=.5bc93e3f-7a6f-4456-b20e-4d336a8b4543@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
 <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
 <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>
 <NK_-GMuUhsrOICOAMok9eyrcRiY29PeAXTcR7QcCzQI=.5bc93e3f-7a6f-4456-b20e-4d336a8b4543@github.com>
Message-ID: <LVWHe9jpWVCmJB4GCdmxTu9yZHffOYKNZ_Pam-fMCxQ=.df29ce7d-2f73-4406-aeee-1a558312d322@github.com>

On Thu, 3 Jun 2021 01:02:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Another way of phrasing it would be 
>> 
>> The text displayed in {@code JPasswordField} shows you that something was typed but does not show the original characters.
>> 
>> Note "that something" not "something that" and the rest of the rephrasing matters too.
>
> I do not like the phrase "Although the text displayed in", the "text" is not displayed in the JPasswordField per se, please suggest something else.

"The text entered in {@code JPasswordField} displays that something was typed and does not show the original characters"
?

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

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

From prr at openjdk.java.net  Thu Jun  3 01:33:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 01:33:42 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <LVWHe9jpWVCmJB4GCdmxTu9yZHffOYKNZ_Pam-fMCxQ=.df29ce7d-2f73-4406-aeee-1a558312d322@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
 <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
 <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>
 <NK_-GMuUhsrOICOAMok9eyrcRiY29PeAXTcR7QcCzQI=.5bc93e3f-7a6f-4456-b20e-4d336a8b4543@github.com>
 <LVWHe9jpWVCmJB4GCdmxTu9yZHffOYKNZ_Pam-fMCxQ=.df29ce7d-2f73-4406-aeee-1a558312d322@github.com>
Message-ID: <SetpcWjwGKYOuSlAWZx1LutP0m1Mm5oz-o_O4SXjFTI=.f6ae268b-0316-437f-a036-da71f09a1810@github.com>

On Thu, 3 Jun 2021 01:23:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I do not like the phrase "Although the text displayed in", the "text" is not displayed in the JPasswordField per se, please suggest something else.
>
> "The text entered in {@code JPasswordField} displays that something was typed and does not show the original characters"
> ?

change "and" to "but" and that will be good enough

"The text entered in {@code JPasswordField} displays that something was typed but does not show the original characters"

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

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

From javalists at cbfiddle.com  Thu Jun  3 01:45:56 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 2 Jun 2021 18:45:56 -0700
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <SetpcWjwGKYOuSlAWZx1LutP0m1Mm5oz-o_O4SXjFTI=.f6ae268b-0316-437f-a036-da71f09a1810@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <ZC-ArXxzGuWiRsS2DnwUJ39Ugq-KMYI5v76aVftLsGo=.779eb549-56f0-4ffa-aa02-7c0ad2fa23c6@github.com>
 <IrMyax45HgVtx3eUG5xdm-kbnsNgrY_x0OhtyAbspss=.edceb381-c714-424f-87f1-1b35031aae11@github.com>
 <eiliLpcmgCCXTzyGA0M7OiffXWH1OzllZm_7xXCQi6c=.2aba89cc-09e1-43c7-a4b7-6cfa095fab7a@github.com>
 <f5N52ACsCUQrj_rFbauFu4UhMJw09EDzqTq9CzIeQ0A=.ceb78fdf-581c-435d-9883-1e1bc9945e10@github.com>
 <o3a_B-5O1At7PW8Snx4YKtWZ4u2HPk_y3gKXtoxdokY=.0e71dc54-d882-4305-b4c2-83b35f5f6aca@github.com>
 <NK_-GMuUhsrOICOAMok9eyrcRiY29PeAXTcR7QcCzQI=.5bc93e3f-7a6f-4456-b20e-4d336a8b4543@github.com>
 <LVWHe9jpWVCmJB4GCdmxTu9yZHffOYKNZ_Pam-fMCxQ=.df29ce7d-2f73-4406-aeee-1a558312d322@github.com>
 <SetpcWjwGKYOuSlAWZx1LutP0m1Mm5oz-o_O4SXjFTI=.f6ae268b-0316-437f-a036-da71f09a1810@github.com>
Message-ID: <7B8B74D2-896B-418B-816B-AA4C9BE1ED99@cbfiddle.com>

I think this statement is over-constraining the UI behavior.

What the password field displays does not have to be text in the ordinary sense of the word. It could be a series of large dots. It is really up to the UI.

Also, the sentence is turned around. It should not start with the ?text entered?, which is irrelevant.

Also, a UI may allow the user to request that the entered text be displayed. That should not be ruled out.

How about:

For security reasons, JPasswordField does not display the entered text. (Some UIs may allow the user to request the display of the entered text.)



> On Jun 2, 2021, at 6:33 PM, Phil Race <prr at openjdk.java.net> wrote:
> 
> On Thu, 3 Jun 2021 01:23:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
> 
>>> I do not like the phrase "Although the text displayed in", the "text" is not displayed in the JPasswordField per se, please suggest something else.
>> 
>> "The text entered in {@code JPasswordField} displays that something was typed and does not show the original characters"
>> ?
> 
> change "and" to "but" and that will be good enough
> 
> "The text entered in {@code JPasswordField} displays that something was typed but does not show the original characters"
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4296
> 


From prr at openjdk.java.net  Thu Jun  3 06:00:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 06:00:38 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <V1zwMvUxWrMUwaa2OEgSbGB72dNuNp2691AGMjtfCeY=.c40a37a5-9051-490b-885e-a81a2185d93f@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [swing-dev](mailto:swing-dev at mail.openjdk.java.net):_
> 
> I think this statement is over-constraining the UI behavior.
> 
> What the password field displays does not have to be text in the ordinary sense of the word. It could be a series of large dots. It is really up to the UI.
> 

It is a text field. It displays unicode text. Nothing else. It can't display a graphic such as a dot unless it is a unicode
assigned code point. So if we want to re-define text across the platform to exclude some subset of unicode it will be
a questionable and difficult job and this informational comment isn't the place to start.

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

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

From serb at openjdk.java.net  Thu Jun  3 08:13:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 08:13:33 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <qU4P8lwbI59NfljPveCwiL89UyqxpFD-FYx-YS8JOyM=.78d15552-223f-4c8a-abe6-72aac8da4daf@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [swing-dev](mailto:swing-dev at mail.openjdk.java.net):_
> How about:
> For security reasons, JPasswordField does not display the entered text. (Some UIs may allow the user to request the display of the entered text.)

Your text is already described in the JPasswordField, this is for what this component was created. The current update is just a note that even if the entered text is not displayed to the user it is still in the heap and can be accessed. The security guide will provide some useful information about such cases.

> It is a text field. It displays unicode text. Nothing else. It can't display a graphic such as a dot unless it is a unicode
> assigned code point. So if we want to re-define text across the platform to exclude some subset of unicode it will be
> a questionable and difficult job and this informational comment isn't the place to start.

In fact, the JPasswordField is not a text component, and UI "can use whatever graphic techniques it desires to represent the field". This is the reason why the initial text in this fix contained "The text entered in {@code JPasswordField} displays something that was typed". So yes it really may contain something that was typed, in opposite to "displays that something was typed".

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

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

From javalists at cbfiddle.com  Thu Jun  3 13:55:47 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 3 Jun 2021 06:55:47 -0700
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <V1zwMvUxWrMUwaa2OEgSbGB72dNuNp2691AGMjtfCeY=.c40a37a5-9051-490b-885e-a81a2185d93f@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <V1zwMvUxWrMUwaa2OEgSbGB72dNuNp2691AGMjtfCeY=.c40a37a5-9051-490b-885e-a81a2185d93f@github.com>
Message-ID: <C2AA6069-A8AF-4A7B-8633-217A6753FE49@cbfiddle.com>



> On Jun 2, 2021, at 11:00 PM, Phil Race <prr at openjdk.java.net> wrote:
> 
> It is a text field. It displays unicode text. Nothing else. It can't display a graphic such as a dot unless it is a unicode
> assigned code point. So if we want to re-define text across the platform to exclude some subset of unicode it will be
> a questionable and difficult job and this informational comment isn't the place to start.

Needless to say, I am not suggesting anything of the sort. You seem to be nitpicking my words rather than trying to understand my suggestion.

The component UI has complete control over painting. It can paint anything it wants, not just text. Normally, that would be a terrible idea, but in the case of a password field, the goal is to not display the entered text, but give very limited feedback when the user types a character.

  Alan

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

From javalists at cbfiddle.com  Thu Jun  3 14:06:02 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 3 Jun 2021 07:06:02 -0700
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <qU4P8lwbI59NfljPveCwiL89UyqxpFD-FYx-YS8JOyM=.78d15552-223f-4c8a-abe6-72aac8da4daf@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <qU4P8lwbI59NfljPveCwiL89UyqxpFD-FYx-YS8JOyM=.78d15552-223f-4c8a-abe6-72aac8da4daf@github.com>
Message-ID: <E8443E50-B191-4BB5-B6CA-7A93F4D039F0@cbfiddle.com>



> On Jun 3, 2021, at 1:13 AM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> This is the reason why the initial text in this fix contained "The text entered in {@code JPasswordField} displays something that was typed". So yes it really may contain something that was typed, in opposite to "displays that something was typed?.

I think we are in agreement on the intent.

However, that sentence makes no sense to me.

The text does not display something. The component displays something.

The phrase ?something that was typed? means nothing to me.

The similar phrase ?what was typed? makes sense, but the component does not display "what was typed", that is the whole point.

The original ?the view indicates something was typed? is appropriate, although it would read better as ?the view indicates that something was typed?.

If you need to say more, perhaps it should be identified as an implementation note.

  Alan

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

From prr at openjdk.java.net  Thu Jun  3 14:41:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 3 Jun 2021 14:41:40 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <VmtDePIGuf1k40nGrL6JsJLA3uD3JvPDtTtp6PQFAOo=.b9f4f998-c2d6-494c-98c9-0bafcb36710d@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <VmtDePIGuf1k40nGrL6JsJLA3uD3JvPDtTtp6PQFAOo=.b9f4f998-c2d6-494c-98c9-0bafcb36710d@github.com>
Message-ID: <NTS-U_dhOJI8pgdXQP3IP1o3WIJnl7JSNxulOaTjQTc=.c27e395a-ca30-425f-920c-f4a4cead14e1@github.com>

On Wed, 2 Jun 2021 13:08:08 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Some useful documentation was added to the JPasswordField.
>
> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 68:
> 
>> 66:  * handling confidential information such as the password text, refer to the
>> 67:  * relevant section at
>> 68:  * <a href="https://www.oracle.com/java/technologies/javase/seccodeguide.html">
> 
> We might want to use the link with an anchor to the specific section, e.g.:
> https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-2

If we want to allow that the representation of what was typed is anything the UI decides then let's start from scratch,

The {@code JPasswordField} will not show the original characters that were typed, instead displaying alternative text or graphics.
However this doesn't prevent... [and then the rest is as originally proposed]

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

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

From javalists at cbfiddle.com  Thu Jun  3 18:50:11 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 3 Jun 2021 11:50:11 -0700
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <NTS-U_dhOJI8pgdXQP3IP1o3WIJnl7JSNxulOaTjQTc=.c27e395a-ca30-425f-920c-f4a4cead14e1@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <VmtDePIGuf1k40nGrL6JsJLA3uD3JvPDtTtp6PQFAOo=.b9f4f998-c2d6-494c-98c9-0bafcb36710d@github.com>
 <NTS-U_dhOJI8pgdXQP3IP1o3WIJnl7JSNxulOaTjQTc=.c27e395a-ca30-425f-920c-f4a4cead14e1@github.com>
Message-ID: <147906F0-3384-4F29-AB5C-ED4B8D809355@cbfiddle.com>

LGTM

> On Jun 3, 2021, at 7:41 AM, Phil Race <prr at openjdk.java.net> wrote:
> 
> On Wed, 2 Jun 2021 13:08:08 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:
> 
>>> Some useful documentation was added to the JPasswordField.
>> 
>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 68:
>> 
>>> 66:  * handling confidential information such as the password text, refer to the
>>> 67:  * relevant section at
>>> 68:  * <a href="https://www.oracle.com/java/technologies/javase/seccodeguide.html">
>> 
>> We might want to use the link with an anchor to the specific section, e.g.:
>> https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-2
> 
> If we want to allow that the representation of what was typed is anything the UI decides then let's start from scratch,
> 
> The {@code JPasswordField} will not show the original characters that were typed, instead displaying alternative text or graphics.
> However this doesn't prevent... [and then the rest is as originally proposed]
> 


From serb at openjdk.java.net  Thu Jun  3 21:31:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 21:31:20 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField [v2]
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <5x8vZmc2MT1DBFCBk5U0f3xcVcNHIXELJa9y7ld-yWY=.cc849896-254c-4d9e-bab4-bd9255b5a2fe@github.com>

> Some useful documentation was added to the JPasswordField.

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

  Update JPasswordField.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4296/files
  - new: https://git.openjdk.java.net/jdk/pull/4296/files/ff208b78..c0b4ef3d

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

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

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

From serb at openjdk.java.net  Thu Jun  3 21:34:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 3 Jun 2021 21:34:57 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField [v2]
In-Reply-To: <5x8vZmc2MT1DBFCBk5U0f3xcVcNHIXELJa9y7ld-yWY=.cc849896-254c-4d9e-bab4-bd9255b5a2fe@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <5x8vZmc2MT1DBFCBk5U0f3xcVcNHIXELJa9y7ld-yWY=.cc849896-254c-4d9e-bab4-bd9255b5a2fe@github.com>
Message-ID: <HVZoo4yp2gBysV3NKV7l04zRBb9RFwW5mBOo1zohu1E=.2804b7cc-7c54-4c87-bb1c-1b1efaa54a24@github.com>

On Thu, 3 Jun 2021 21:31:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Some useful documentation was added to the JPasswordField.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update JPasswordField.java

The patch and CSR are updated.

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

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

From prr at openjdk.java.net  Fri Jun  4 15:12:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Jun 2021 15:12:02 GMT
Subject: <Swing Dev> RFR: 8268087: Update documentation of the
 JPasswordField [v2]
In-Reply-To: <5x8vZmc2MT1DBFCBk5U0f3xcVcNHIXELJa9y7ld-yWY=.cc849896-254c-4d9e-bab4-bd9255b5a2fe@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
 <5x8vZmc2MT1DBFCBk5U0f3xcVcNHIXELJa9y7ld-yWY=.cc849896-254c-4d9e-bab4-bd9255b5a2fe@github.com>
Message-ID: <BF2ufE-ZHwz7kohx98WwHJRU8yw7ONUz3eUD0ghQOZ0=.a4a9ecb0-e558-4583-87f4-2a04b85333f7@github.com>

On Thu, 3 Jun 2021 21:31:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Some useful documentation was added to the JPasswordField.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update JPasswordField.java

Marked as reviewed by prr (Reviewer).

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

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

From serb at openjdk.java.net  Sat Jun  5 15:44:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 5 Jun 2021 15:44:03 GMT
Subject: <Swing Dev> Integrated: 8268087: Update documentation of the
 JPasswordField
In-Reply-To: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
References: <zwzaCoUQY6q3rATf-9gNCN9SuwndlDn9ATCPTI4gsLc=.0253c52e-35e1-4abe-b5c3-65bf24a0f46b@github.com>
Message-ID: <4NMnIqNV8h6Hc0ad-_oqlGprhr-9SB5h9jmt64UTVqA=.472498df-b33d-40e6-bfbc-c0d695b68d54@github.com>

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some useful documentation was added to the JPasswordField.

This pull request has now been integrated.

Changeset: b2e9eb9e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2e9eb9e47beb5148e3b9f86f25fad352ed4a236
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8268087: Update documentation of the JPasswordField

Reviewed-by: trebari, azvegint, prr

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

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

From kizune at openjdk.java.net  Wed Jun 23 17:26:38 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 23 Jun 2021 17:26:38 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted to
 String in AccessibleJPasswordField
Message-ID: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>

8268775: Password is being converted to String in AccessibleJPasswordField

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

Commit messages:
 - 8268775: Password is being converted to String in AccessibleJPasswordField

Changes: https://git.openjdk.java.net/jdk17/pull/127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268775
  Stats: 12 lines in 1 file changed: 2 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/127/head:pull/127

PR: https://git.openjdk.java.net/jdk17/pull/127

From vdyakov at openjdk.java.net  Wed Jun 23 17:38:29 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 23 Jun 2021 17:38:29 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <BQQoI2vArZwrC-NXvIMIMQUchrkVUz8miH-Q_UTIBQc=.8f4eab8f-e08a-4d2a-bbcd-3c9212e96c4f@github.com>

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268775: Password is being converted to String in AccessibleJPasswordField

@prrace @azvegint @prsadhuk  please review

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From prr at openjdk.java.net  Wed Jun 23 17:56:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Jun 2021 17:56:36 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268775: Password is being converted to String in AccessibleJPasswordField

There's code but not a  single word of description of the fix. 
What is the problem, what are the changes here, why do they fix it, and what are the risks / consequences and why is there no test ? 
It is not very kind to reviewers to offer no explanation.

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

> 512:         public String getAtIndex(int part, int index) {
> 513:             if (part == AccessibleText.CHARACTER) {
> 514:                 return getEchoString(super.getAtIndex(part, index));

I don't see how removing the local variable changes anything. Explanation ??

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

> 544:         public String getAfterIndex(int part, int index) {
> 545:             if (part == AccessibleText.CHARACTER) {
> 546:                 return getEchoString(super.getAfterIndex(part, index));

I don't see how removing the local variable changes anything. Explanation ??

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Wed Jun 23 19:34:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 23 Jun 2021 19:34:29 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <0wbalZ8x5PNzmPSe99kQPisQv3G14_65SfWgbbaKWBk=.35953ab5-289a-42be-beee-590c9d0668bb@github.com>

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268775: Password is being converted to String in AccessibleJPasswordField

The problem here is that if someone uses the accessibility methods on JPasswordField it will lead to unencrypted password being stored in the local String variable and that in turn can lead to it being recorded in, say, crash tump file where it can be found amongst the string literals. This is highly improbable scenario but it can be done so we better to not do it. And there are only two places where it happens - because in other methods we only serving the AccessibleText.CHARACTER retrieval which means that we are getting one password character at a time in a separate String variable which is Ok. These two places are at methods getAtIndex and getTextSequenceAt where we requesting something other than AccessibleText.CHARACTER. There we were converting password from the array of chars to the String only to pass this string to the method that generates string of echo characters of the same length. Instead i am doing conversion myself filling in the returned array with echo characters a
 nd returning constructed string. The rest of the changes is just a slight code cleanup - getting rid of the local variable that is used only to store some value before passing it to another method.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Wed Jun 23 19:34:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 23 Jun 2021 19:34:30 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
Message-ID: <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>

On Wed, 23 Jun 2021 17:50:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8268775: Password is being converted to String in AccessibleJPasswordField
>
> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 514:
> 
>> 512:         public String getAtIndex(int part, int index) {
>> 513:             if (part == AccessibleText.CHARACTER) {
>> 514:                 return getEchoString(super.getAtIndex(part, index));
> 
> I don't see how removing the local variable changes anything. Explanation ??

Here it is just a slight code cleanup. We do not need additional variable for passing value from one method to another. It serves no other purpose at all. It was used before on the second leg of the if but the usage was removed so it became useless.

> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 546:
> 
>> 544:         public String getAfterIndex(int part, int index) {
>> 545:             if (part == AccessibleText.CHARACTER) {
>> 546:                 return getEchoString(super.getAfterIndex(part, index));
> 
> I don't see how removing the local variable changes anything. Explanation ??

Here it is just a slight code cleanup. We do not need additional variable for passing value from one method to another. It serves no other purpose at all.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From prr at openjdk.java.net  Wed Jun 23 20:40:30 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Jun 2021 20:40:30 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
 <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
Message-ID: <rQOYY5uDjsr-iqgj3Y_jCqvOMWjCYFka6LzztcljyEE=.67067214-543f-469b-bfca-36ad522b3553@github.com>

On Wed, 23 Jun 2021 19:31:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 546:
>> 
>>> 544:         public String getAfterIndex(int part, int index) {
>>> 545:             if (part == AccessibleText.CHARACTER) {
>>> 546:                 return getEchoString(super.getAfterIndex(part, index));
>> 
>> I don't see how removing the local variable changes anything. Explanation ??
>
> Here it is just a slight code cleanup. We do not need additional variable for passing value from one method to another. It serves no other purpose at all.

Let me ask it this way.
Does super.getAfterIndex(part, index) return a String with any of the password in clear text ? 
It seems to me like it might.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From prr at openjdk.java.net  Wed Jun 23 20:40:30 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 23 Jun 2021 20:40:30 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <_n1Ax8kkMDN7PT2ZGrC4zIQEHVho4kR_Ljcscrz-754=.e642e2af-24c3-4a2b-bb27-dc1f28f25c45@github.com>

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268775: Password is being converted to String in AccessibleJPasswordField

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

> 632:                 Arrays.fill(password, getEchoChar());
> 633:                 String text = new String(password);
> 634:                 return new AccessibleTextSequence(0, password.length - 1, text);

So the accessible text is just the right number of "echo" chars.
And you are still calling getPassword() just so you can find out the length.
Then it is over-written. There's a really tiny window after getPassword() and before Arrays.fill() when the clear password is still there. 
The number of "char"s isn't the same as the number of "characters" if there's a non-BMP code point in there .. perhaps these are not allowed by this class .. but it makes me wonder how much if having the exact number of echo chars as the actual password is important.  I wonder how many text-to-speech readers can say "bullet" for a unicode bullet character ? 

If it weren't for all of this (the class and the getPassword() method being non-final I'd suggest you look into a way to pull just the length rather than the actual chars.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Thu Jun 24 02:36:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 24 Jun 2021 02:36:30 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <rQOYY5uDjsr-iqgj3Y_jCqvOMWjCYFka6LzztcljyEE=.67067214-543f-469b-bfca-36ad522b3553@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
 <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
 <rQOYY5uDjsr-iqgj3Y_jCqvOMWjCYFka6LzztcljyEE=.67067214-543f-469b-bfca-36ad522b3553@github.com>
Message-ID: <CTB3eqxfwKZPVQeoMC-x0-t4Wht4IRgG5B33cLNguD0=.07b6f526-95f2-48d1-b02f-5553cb73f110@github.com>

On Wed, 23 Jun 2021 20:37:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Here it is just a slight code cleanup. We do not need additional variable for passing value from one method to another. It serves no other purpose at all.
>
> Let me ask it this way.
> Does super.getAfterIndex(part, index) return a String with any of the password in clear text ? 
> It seems to me like it might.

For CHARACTER it will return String with a single character in the corresponding position. There is a possibility that someone will iterate the entirety of the password text and get all the characters in the password as a separate strings but digging it from the memory dump is much more difficult than the singular string with the whole password.
For anything but character we do not use this method - we get password as an array of characters and - after the fix - immediately overriding them with the same number of echo characters.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Thu Jun 24 04:42:27 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 24 Jun 2021 04:42:27 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <_n1Ax8kkMDN7PT2ZGrC4zIQEHVho4kR_Ljcscrz-754=.e642e2af-24c3-4a2b-bb27-dc1f28f25c45@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_n1Ax8kkMDN7PT2ZGrC4zIQEHVho4kR_Ljcscrz-754=.e642e2af-24c3-4a2b-bb27-dc1f28f25c45@github.com>
Message-ID: <i9GpZSY2U1fObyFMakgcLdBcIu9s5peyJ87r999RwXo=.28d65393-1686-4d3f-b84f-8e5a3c120e79@github.com>

On Wed, 23 Jun 2021 20:33:57 GMT, Phil Race <prr at openjdk.org> wrote:

> So the accessible text is just the right number of "echo" chars.
Yes.
> And you are still calling getPassword() just so you can find out the length.
> Then it is over-written. There's a really tiny window after getPassword() and before Arrays.fill() when the clear password is still there.

Yes. But not as a string - and the window of opportunity to get the characters before they are overwritten by the echo characters is minimal.

> The number of "char"s isn't the same as the number of "characters" if there's a non-BMP code point in there .. 

Since in order to enter non-BPM characters you have to have an input methods helper which should be disabled on password fields for obvious reason - it would pretty much disclose the typed password in the IM helper window

> perhaps these are not allowed by this class .. but it makes me wonder how much if having the exact number of echo chars as the actual password is important. I wonder how many text-to-speech readers can say "bullet" for a unicode bullet character ?
Well, accessibility is not only about text to speech - it is also about easier navigation so having exact number of the bullets is preferable. There are limitations - like some non-BPM text can be pasted into the password field and then navigating within it might be broken but since there will be no IM engaged fixing it would be equally problematic.

> If it weren't for all of this (the class and the getPassword() method being non-final I'd suggest you look into a way to pull just the length rather than the actual chars.

That would be preferable but under the current circumstances i would say that my fix makes things better without adding incompatible changes.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From github.com+1671049+vest at openjdk.java.net  Thu Jun 24 07:36:33 2021
From: github.com+1671049+vest at openjdk.java.net (Vest)
Date: Thu, 24 Jun 2021 07:36:33 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
 <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
Message-ID: <G-JwSYsFUtEg-wIrLFRIg2er_zUsZbNA02t9fb-PyPY=.827e642c-ba05-4cbf-a610-fa59133d495a@github.com>

On Wed, 23 Jun 2021 19:32:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 514:
>> 
>>> 512:         public String getAtIndex(int part, int index) {
>>> 513:             if (part == AccessibleText.CHARACTER) {
>>> 514:                 return getEchoString(super.getAtIndex(part, index));
>> 
>> I don't see how removing the local variable changes anything. Explanation ??
>
> Here it is just a slight code cleanup. We do not need additional variable for passing value from one method to another. It serves no other purpose at all. It was used before on the second leg of the if but the usage was removed so it became useless.

If this is about security, I don?t see how it might help. There is a chance that the heap dump might capture the content of the local variable. If you submit your heap dump to someone, whom you do not trust, I have bad news for you. 

The probability of the heap dump to capture a local variable is more than zero. True, but less than probable.

I don?t know if calling same methods in a single line makes this control more secure (if we take the situation that the heap dump pauses an execution of the thread exactly at our ?moment of time?). I am not a member of the project JDK, but I doubt that this PR solves something. 

To me, an additional local variable adds better supportability (debugging) to this code. Otherwise everything should be put into a single fat method.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From dcubed at openjdk.java.net  Thu Jun 24 19:27:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:27:40 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
Message-ID: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>

A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

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

Commit messages:
 - 8269315: ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64

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

PR: https://git.openjdk.java.net/jdk17/pull/139

From dcubed at openjdk.java.net  Thu Jun 24 20:24:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:24:28 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
 <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>
Message-ID: <W5EvOJFCf4mHRdkusE9KKuCVuOpWdPANCbXsu4QaEls=.74ea91df-c41b-43e7-90d3-cba0cd7ab921@github.com>

On Thu, 24 Jun 2021 20:21:18 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.
>
> Looks good and trivial.

@calvinccheung - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk17/pull/139

From ccheung at openjdk.java.net  Thu Jun 24 20:24:28 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 20:24:28 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
Message-ID: <4G8c0mE6TNqDWh-9_UCe2hR9b2EJzpF33HLJQSBk9RA=.67e4b0d9-9827-4bc7-9cb7-b591d1248a61@github.com>

On Thu, 24 Jun 2021 19:20:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

Looks good and trivial.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/139

From dcubed at openjdk.java.net  Thu Jun 24 20:30:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:30:02 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8269315: ProblemList
 javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64
In-Reply-To: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
References: <jgaLqYQtbNibxtfmAgLrJ8vhdMuLiqVZ9U-8uIBNNwg=.4da8c6c3-d61f-44f8-a8e6-326527990e87@github.com>
Message-ID: <PxmHf5TQ86qlbj-7FQhcZnpNhcTmzTg_7CUjjdXeRt4=.a6cf81da-abec-4dbf-8b81-b18180632295@github.com>

On Thu, 24 Jun 2021 19:20:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64.

This pull request has now been integrated.

Changeset: 22d86750
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/22d867508514d57faaaa5c515ed5bfc635eb63f6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8269315: ProblemList javax/swing/JFileChooser/FileSystemView/SystemIconTest.java on Win-X64

Reviewed-by: ccheung

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

PR: https://git.openjdk.java.net/jdk17/pull/139

From kizune at openjdk.java.net  Sat Jun 26 01:21:58 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 26 Jun 2021 01:21:58 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <G-JwSYsFUtEg-wIrLFRIg2er_zUsZbNA02t9fb-PyPY=.827e642c-ba05-4cbf-a610-fa59133d495a@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_v8ATkKTvodHQDGLM-0V-bBdS28-CelrUqBmWzYuXX4=.40f410a9-117f-48b5-b372-cdb04de5cf8b@github.com>
 <gc5h_CVIVGLWlt0LB9cqa5eBGosj4Ozf22UqY5u33p0=.522a278a-f636-4668-a953-1213563e33a2@github.com>
 <G-JwSYsFUtEg-wIrLFRIg2er_zUsZbNA02t9fb-PyPY=.827e642c-ba05-4cbf-a610-fa59133d495a@github.com>
Message-ID: <GJ5t3H93dlWuN9DfQNNyp2FpzLYYfWrEhEYOLPCFi6M=.24825e57-7dfc-4ee0-94fa-9fca7c0fbe77@github.com>

On Wed, 23 Jun 2021 21:30:15 GMT, Vest <github.com+1671049+Vest at openjdk.org> wrote:

> I don?t know if calling same methods in a single line makes this control more secure

As i said above this exact change is not about making code more secure - it is just to eliminate additional variable that has no purpose after the second half of the method is changed. I would say that it would add to the supportability if we do anything with this information - but we don't.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From clanger at openjdk.java.net  Mon Jun 28 15:36:17 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 28 Jun 2021 15:36:17 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build
Message-ID: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>

Exclude test on Windows if VM is from a debug build.

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

Commit messages:
 - JDK-8269529

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From clanger at openjdk.java.net  Mon Jun 28 15:43:35 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 28 Jun 2021 15:43:35 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v2]
In-Reply-To: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
Message-ID: <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>

> Exclude test on Windows if VM is from a debug build.

Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  JDK-8269529

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/160/files
  - new: https://git.openjdk.java.net/jdk17/pull/160/files/d716e682..9f507403

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

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From serb at openjdk.java.net  Mon Jun 28 22:40:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Jun 2021 22:40:04 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v2]
In-Reply-To: <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>
Message-ID: <SwwZzcV6-vEc0VbkZ8mRXeElZzrs-aybkgv7sdu-Ay8=.20276439-4849-4326-a238-5a4904482a58@github.com>

On Mon, 28 Jun 2021 15:43:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From psadhukhan at openjdk.java.net  Tue Jun 29 08:22:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Jun 2021 08:22:07 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v2]
In-Reply-To: <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>
Message-ID: <MHq0wqi6nLq3CLwEYZCh1BphhBj0VLAMD4eOAxR9lj0=.fd55fcb4-6f0a-44e4-a579-37dfd8d32f95@github.com>

On Mon, 28 Jun 2021 15:43:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

looks ok. It will be good to update the copyright date too...

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From clanger at openjdk.java.net  Tue Jun 29 08:29:29 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 29 Jun 2021 08:29:29 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v3]
In-Reply-To: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
Message-ID: <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>

> Exclude test on Windows if VM is from a debug build.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Update Copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/160/files
  - new: https://git.openjdk.java.net/jdk17/pull/160/files/9f507403..a25f925a

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

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From clanger at openjdk.java.net  Tue Jun 29 08:29:30 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 29 Jun 2021 08:29:30 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v2]
In-Reply-To: <MHq0wqi6nLq3CLwEYZCh1BphhBj0VLAMD4eOAxR9lj0=.fd55fcb4-6f0a-44e4-a579-37dfd8d32f95@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <pVCbY30cAYfc5pT8fGclb4DW9OMhZBngU6zhkVbZyiQ=.4c440313-0507-4f43-a928-c1bc219e446e@github.com>
 <MHq0wqi6nLq3CLwEYZCh1BphhBj0VLAMD4eOAxR9lj0=.fd55fcb4-6f0a-44e4-a579-37dfd8d32f95@github.com>
Message-ID: <tMsGp6sUSWsF-pAipFs_X0Ti6plGhO2HtNIzA9-2cDo=.62124ffa-6b3a-443d-a299-39e88b663efb@github.com>

On Tue, 29 Jun 2021 08:18:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> looks ok. It will be good to update the copyright date too...

You're right, thanks for the hint... updated.

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From pbansal at openjdk.java.net  Tue Jun 29 08:43:09 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 29 Jun 2021 08:43:09 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v3]
In-Reply-To: <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
Message-ID: <Eph-JVL_S8owJmXP4QKpCP2ch6n0bu9ONB4WR0lPJRA=.aacef470-5e8b-47bd-9284-d733fa737a0b@github.com>

On Tue, 29 Jun 2021 08:29:29 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Marked as reviewed by pbansal (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From psadhukhan at openjdk.java.net  Tue Jun 29 08:50:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 29 Jun 2021 08:50:07 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v3]
In-Reply-To: <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
Message-ID: <K_5iQpjOWgeDjEZSe2qoQaxM-Vte-R7R6DNCq81TWu4=.1270bada-3e40-47bd-a870-6fefdf6faecc@github.com>

On Tue, 29 Jun 2021 08:29:29 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From kizune at openjdk.java.net  Tue Jun 29 19:17:21 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Jun 2021 19:17:21 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest fails
 with ClassCastException
Message-ID: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>

8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

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

Commit messages:
 - 8269269: [macos11] SystemIconTest fails with ClassCastException

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

PR: https://git.openjdk.java.net/jdk17/pull/176

From kizune at openjdk.java.net  Tue Jun 29 19:57:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Jun 2021 19:57:03 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
References: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
Message-ID: <BzdH6a4hQnkjK4nrci2cBeo6QaQxiPGLkOAHSw_8yac=.407a1297-5c63-46d9-9aed-dba30c74d37e@github.com>

On Tue, 29 Jun 2021 19:11:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:

> 73:     static void testSystemIcon(File file, boolean implComplete) {
> 74:         int[] sizes = new int[] {16, 32, 48, 64, 128};
> 75:         if (!file.exists() || !file.canRead()) {

The main reason for the Windows failure is that for some reason the default windir was not accessible - this check will avoid the situation where we are testing the icon for non-accessible folder - because in this case we will return the default UIManager icon for a file or a folder and this icon is not multi-resolution. On Mac it leads to the IconUIResource being returned and this Icon representation can not be casted to ImageIcon hence test fails.

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

PR: https://git.openjdk.java.net/jdk17/pull/176

From clanger at openjdk.java.net  Tue Jun 29 21:06:09 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 29 Jun 2021 21:06:09 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build [v3]
In-Reply-To: <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
 <IEpx8skzHrnVQYghmTxf9xPUJNvFixghx3GZpYG1NW0=.70047f53-4971-4148-891e-c82c280a78f7@github.com>
Message-ID: <ZsWPe4lFrj-gCJYntQKKq32a1yTcUc97UzA8b3rZ2SM=.34dbe58d-974e-4e1b-b1c1-5e543db70d5c@github.com>

On Tue, 29 Jun 2021 08:29:29 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From clanger at openjdk.java.net  Tue Jun 29 21:06:10 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 29 Jun 2021 21:06:10 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8269529:
 javax/swing/reliability/HangDuringStaticInitialization.java fails in
 Windows debug build
In-Reply-To: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
References: <OsOKEs8j1PbZZNTGZH9CiU3Eg31jdQKPzzm2xdtU_lI=.3b6eef5e-d0d0-47fc-a129-54a4c3fc3645@github.com>
Message-ID: <6w8vM1BvSH45zM9Y6WtILboDsVSUDC2Dokefl5m0HaA=.4a3eec70-9fbc-477d-bb15-e9e911369610@github.com>

On Mon, 28 Jun 2021 15:29:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Exclude test on Windows if VM is from a debug build.

This pull request has now been integrated.

Changeset: d0420295
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/d042029509a8cbdb723f78e2cfee4e2885775814
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build

Reviewed-by: serb, psadhukhan, pbansal

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

PR: https://git.openjdk.java.net/jdk17/pull/160

From kizune at openjdk.java.net  Tue Jun 29 22:06:37 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Jun 2021 22:06:37 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException [v2]
In-Reply-To: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
References: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
Message-ID: <W5ED4dVJv-TZOUdM8oX8BOu4_pMgzSfLPXmVGJaiWB4=.69a42309-c631-486b-b8f7-cb6d530e3ea0@github.com>

> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

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

 - Merge branch 'JDK-8269269' of https://github.com/azuev-java/jdk17 into JDK-8269269
 - 8269269: [macos11] SystemIconTest fails with ClassCastException
   8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows
   
   Added additional checks that will protect from false negative due to the
   file being inaccessible or system environment variable overwritten
 - Removed test from problem list
 - 8269269: [macos11] SystemIconTest fails with ClassCastException
   8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows
   
   Added additional checks that will protect from false negative due to the
   file being inaccessible or system environment variable overwritten

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/176/files
  - new: https://git.openjdk.java.net/jdk17/pull/176/files/5aeb8f8a..8619b7e2

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

  Stats: 2573 lines in 113 files changed: 1861 ins; 421 del; 291 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/176.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/176/head:pull/176

PR: https://git.openjdk.java.net/jdk17/pull/176

From kizune at openjdk.java.net  Tue Jun 29 22:06:38 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Jun 2021 22:06:38 GMT
Subject: <Swing Dev> [jdk17] Withdrawn: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
References: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
Message-ID: <qWbhrolo9dfqRDnnHWIZRjtgW6ss8X-_ceZzvtVbUgY=.b6a9648c-d36d-455e-8135-ba13b4aecaa5@github.com>

On Tue, 29 Jun 2021 19:11:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk17/pull/176

From kizune at openjdk.java.net  Tue Jun 29 22:19:16 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 29 Jun 2021 22:19:16 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest fails
 with ClassCastException
Message-ID: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>

Added check for the icon class type
Added check if file or folder we are testing against exists and
accessible
Removed test from problem list

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

Commit messages:
 - 8269269: [macos11] SystemIconTest fails with ClassCastException

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From vdyakov at openjdk.java.net  Tue Jun 29 23:01:06 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 29 Jun 2021 23:01:06 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException [v2]
In-Reply-To: <W5ED4dVJv-TZOUdM8oX8BOu4_pMgzSfLPXmVGJaiWB4=.69a42309-c631-486b-b8f7-cb6d530e3ea0@github.com>
References: <qTI2uFuBZRS1xWXHXAx8gei9sU6lfoFppVMPqosiAUA=.087eea95-c50c-4ac5-8222-1d4dbd51981c@github.com>
 <W5ED4dVJv-TZOUdM8oX8BOu4_pMgzSfLPXmVGJaiWB4=.69a42309-c631-486b-b8f7-cb6d530e3ea0@github.com>
Message-ID: <YqabIHdXGx5pWPEYhQOBGREAJ8XF1bz1YvX5VqwQ_qM=.b2b10bfd-6322-413c-9221-be5c0e0f8589@github.com>

On Tue, 29 Jun 2021 22:06:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows
>
> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'JDK-8269269' of https://github.com/azuev-java/jdk17 into JDK-8269269
>  - 8269269: [macos11] SystemIconTest fails with ClassCastException
>    8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows
>    
>    Added additional checks that will protect from false negative due to the
>    file being inaccessible or system environment variable overwritten
>  - Removed test from problem list
>  - 8269269: [macos11] SystemIconTest fails with ClassCastException
>    8268280: javax/swing/JFileChooser/FileSystemView/SystemIconTest.java fails on windows
>    
>    Added additional checks that will protect from false negative due to the
>    file being inaccessible or system environment variable overwritten

@prsadhuk @azvegint  please review

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

PR: https://git.openjdk.java.net/jdk17/pull/176

From vdyakov at openjdk.java.net  Tue Jun 29 23:01:01 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 29 Jun 2021 23:01:01 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
Message-ID: <nQ05CL5LQHlp84zvzFjNDINZCY_-i9HS3QS4kXr9bgk=.93109d2e-9cbc-4886-9fb7-403b91196963@github.com>

On Tue, 29 Jun 2021 22:10:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list

@prsadhuk  @azvegint  please review

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From serb at openjdk.java.net  Tue Jun 29 23:56:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Jun 2021 23:56:59 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
Message-ID: <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>

On Tue, 29 Jun 2021 22:10:46 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:

> 73:     static void testSystemIcon(File file, boolean implComplete) {
> 74:         int[] sizes = new int[] {16, 32, 48, 64, 128};
> 75:         if (!file.exists() || !file.canRead()) {

If this file is not accessible the "getSystemIcon" should return "null" you can check it here.

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 76:

> 74:         int[] sizes = new int[] {16, 32, 48, 64, 128};
> 75:         for (int size : sizes) {
> 76:             ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);

Probably we can wrap the  "UIManager.getIcon" in the "ImageIcon"?

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 88:

> 86:             }
> 87: 
> 88:             ImageIcon icon = (ImageIcon) i;

One more time would like to highlight that to get the data of the requested image the user need to do one "if" and two "instanceof". Still hope that we can improve this.

    Icon icon = fsv.getSystemIcon(file, width, height);
    if (icon.getIconWidth() != width && icon.getIconHeight() != height) {
        return scaleTheIconInTheSameWayAsBeforeTheFix(icon, width, height);
    } else if (icon instanceof ImageIcon) {
        ImageIcon imageIcon = (ImageIcon) icon;
        if (icon.getImage() instanceof MultiResolutionImage) {
            MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
            return  mri.getResolutionVariant(width, height);
        } else {
            return imageIcon;
        }
    } else {
        return icon;
    }

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From jwilhelm at openjdk.java.net  Wed Jun 30 00:39:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 00:39:07 GMT
Subject: <Swing Dev> RFR: Merge jdk17
Message-ID: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269034: AccessControlException for SunPKCS11 daemon threads
 - 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build
 - 8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak
 - 8268884: C2: Compile::remove_speculative_types must iterate top-down
 - 8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}
 - 8268699: Shenandoah: Add test for JDK-8268127
 - 8269517: compiler/loopopts/TestPartialPeelingSinkNodes.java crashes with -XX:+VerifyGraphEdges
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
  Stats: 127 lines in 11 files changed: 70 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

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

From kizune at openjdk.java.net  Wed Jun 30 01:16:01 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 01:16:01 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
Message-ID: <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>

On Tue, 29 Jun 2021 23:44:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If this file is not accessible the "getSystemIcon" should return "null" you can check it here.

If file is not accessible we still return default icon for file or folder - if we, for example, looking at the folder in file explorer  with file not readable then we should display some icon for it. It will not be icon from the file itself - because we can not read it - but it will not be null.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 01:20:01 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 01:20:01 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
Message-ID: <sm5gjYEOBubkN-es3I4TL74ix-adqYmYE_I_-csPWb0=.2d0c9f87-86d0-4cf8-aa2f-afa2b1f53aba@github.com>

On Tue, 29 Jun 2021 23:51:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> One more time would like to highlight that to get the data of the requested image the user need to do one "if" and two "instanceof". Still hope that we can improve this.

We might when the implementation will be complete on all the relevant platforms, then we can be sure that we can provide specific type of an icon like ImageIcon or even MultiResolutionImage - but until then i would tend to use common denominator like simple Icon.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:33 GMT
Subject: <Swing Dev> Integrated: Merge jdk17
In-Reply-To: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
References: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
Message-ID: <pM8dWNQGAKaoJTyKNVhtt_9RBXhC2zM70ozT1b9xdOc=.d3381bc7-bb08-4a8e-9002-0a1c78211a27@github.com>

On Wed, 30 Jun 2021 00:31:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: ee526a2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee526a2ea840aedb97b23538f9d624acbccebc97
Stats:     127 lines in 11 files changed: 70 ins; 17 del; 40 mod

Merge

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

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

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:32 GMT
Subject: <Swing Dev> RFR: Merge jdk17 [v2]
In-Reply-To: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
References: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
Message-ID: <8_fkYpZLlCG8Nj5dx5WhuZsWDbFnUHu4OWWY735hdr0=.625da0e5-831e-4c10-afbc-aa5364fba16b@github.com>

> Forwardport JDK 17 -> JDK 18

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

 - Merge
 - 8269615: Fix for 8263640 broke Windows build
   
   Reviewed-by: iklam, dcubed
 - 8269268: JDWP: Properly fix thread lookup assert in findThread()
   
   Reviewed-by: kevinw, amenkov, sspitsyn
 - 8260540: serviceability/jdwp/AllModulesCommandTest.java failed with "Debuggee error: 'ERROR: transport error 202: bind failed: Address already in use'"
   
   Reviewed-by: sspitsyn, kevinw
 - 8263640: hs_err improvement: handle class path longer than O_BUFLEN
   
   Reviewed-by: iklam, minqi, dholmes
 - 8269417: Minor clarification on NonblockingQueue utility
   
   Reviewed-by: kbarrett, iwalulya
 - 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
   
   Reviewed-by: dholmes, coleenp
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC
   
   Reviewed-by: iwalulya, kbarrett
 - 8261579: AArch64: Support for weaker memory ordering in Atomic
   
   Reviewed-by: adinn, shade
 - 8268821: Split systemDictionaryShared.cpp
   
   Reviewed-by: erikj, ccheung, iklam
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/0d745ae8...be964f2e

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

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4630&range=01
  Stats: 30219 lines in 619 files changed: 17676 ins; 10608 del; 1935 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

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

From serb at openjdk.java.net  Wed Jun 30 03:04:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 03:04:07 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
Message-ID: <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>

On Wed, 30 Jun 2021 01:13:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 75:
>> 
>>> 73:     static void testSystemIcon(File file, boolean implComplete) {
>>> 74:         int[] sizes = new int[] {16, 32, 48, 64, 128};
>>> 75:         if (!file.exists() || !file.canRead()) {
>> 
>> If this file is not accessible the "getSystemIcon" should return "null" you can check it here.
>
>> If this file is not accessible the "getSystemIcon" should return "null" you can check it here.
> 
> If file is not accessible we still return default icon for file or folder - if we, for example, looking at the folder in file explorer  with file not readable then we should display some icon for it. It will not be icon from the file itself - because we can not read it - but it will not be null.

1. If the file does not exist then the getSystemIcon() will always return null, but what happens if the file cannot be read? We will call the "sf = ShellFolder.getShellFolder" and then we call "sf.getIcon()" and it returns what? As far as I understand it always return MultiResolutionIconImage, no?

2. If we return some icon when the file cannot be read then you can check it here as well.

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 88:
>> 
>>> 86:             }
>>> 87: 
>>> 88:             ImageIcon icon = (ImageIcon) i;
>> 
>> One more time would like to highlight that to get the data of the requested image the user need to do one "if" and two "instanceof". Still hope that we can improve this.
>> 
>>     Icon icon = fsv.getSystemIcon(file, width, height);
>>     if (icon.getIconWidth() != width && icon.getIconHeight() != height) {
>>         return scaleTheIconInTheSameWayAsBeforeTheFix(icon, width, height);
>>     } else if (icon instanceof ImageIcon) {
>>         ImageIcon imageIcon = (ImageIcon) icon;
>>         if (icon.getImage() instanceof MultiResolutionImage) {
>>             MultiResolutionImage mri = (MultiResolutionImage) icon.getImage();
>>             return  mri.getResolutionVariant(width, height);
>>         } else {
>>             return imageIcon;
>>         }
>>     } else {
>>         return icon;
>>     }
>
>> One more time would like to highlight that to get the data of the requested image the user need to do one "if" and two "instanceof". Still hope that we can improve this.
> 
> We might when the implementation will be complete on all the relevant platforms, then we can be sure that we can provide specific type of an icon like ImageIcon or even MultiResolutionImage - but until then i would tend to use common denominator like simple Icon.

But you cannot change the return type later, so all these instanceof+casts will be there forever.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From vdyakov at openjdk.java.net  Wed Jun 30 03:46:03 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 30 Jun 2021 03:46:03 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <GX2c2YbAqn86uQvXSGvKL0mMg5yKu0hmi_ySYbZU1pU=.6cde1fc1-883b-4657-976d-10d0e6b0faef@github.com>

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8268775: Password is being converted to String in AccessibleJPasswordField

@mrserb  please review

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Wed Jun 30 04:20:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 04:20:02 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
Message-ID: <Y3iEU3-N5bktHkcOGf8hsz6hCv1BUZ1Fp3G4URf7DVE=.9306acc9-ffd3-4039-bbd7-bd41d1b40eab@github.com>

On Wed, 30 Jun 2021 02:54:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> But you cannot change the return type later, so all these instanceof+casts will be there forever.

Well, if there is a reason the API can be amended in the future version of Java. It is not cast in stone. Yes, it will require some justification, but if justification is provided then API can be changed.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 04:27:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 04:27:04 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
Message-ID: <YQyBqJrQNyP3ROk3LeO9N4fdZ_ysLMK-D76yPlE5jLw=.bb264a73-80e2-48f1-bd99-2bab4da941ef@github.com>

On Tue, 29 Jun 2021 23:47:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we can wrap the "UIManager.getIcon" in the "ImageIcon"?

Why? In some LaFs that might be a procedural image that generates it content every time paint() is called on it - i do not think wrapping it in the ImageIcon will solve anything.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 04:27:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 04:27:03 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
Message-ID: <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>

On Wed, 30 Jun 2021 03:01:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> * but what happens if the file cannot be read? We will call the "sf = ShellFolder.getShellFolder" and then we call "sf.getIcon()" and it returns what? As far as I understand it always return MultiResolutionIconImage, no?
> *

No, the native code will fail to load the icon but since file does exist and we only return null for nonexistent file we will fall back to UIManager.getIcon which returns icon from the installed LAF resource bundle. This is correct behavior since otherwise we might end in file manager with file that has no icon at all. Right now that will be a single resolution icon for all the LAFs. Again, in the future that can be changed but right now it is a single resolution icon.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From serb at openjdk.java.net  Wed Jun 30 04:44:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 04:44:05 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField
In-Reply-To: <i9GpZSY2U1fObyFMakgcLdBcIu9s5peyJ87r999RwXo=.28d65393-1686-4d3f-b84f-8e5a3c120e79@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_n1Ax8kkMDN7PT2ZGrC4zIQEHVho4kR_Ljcscrz-754=.e642e2af-24c3-4a2b-bb27-dc1f28f25c45@github.com>
 <i9GpZSY2U1fObyFMakgcLdBcIu9s5peyJ87r999RwXo=.28d65393-1686-4d3f-b84f-8e5a3c120e79@github.com>
Message-ID: <dJkS9637ya6cHqa7_9nzTblKAQisjhmbf44jbVNuojY=.fdfa1400-df34-44c1-9bb0-557da6825aa2@github.com>

On Thu, 24 Jun 2021 04:39:12 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 634:
>> 
>>> 632:                 Arrays.fill(password, getEchoChar());
>>> 633:                 String text = new String(password);
>>> 634:                 return new AccessibleTextSequence(0, password.length - 1, text);
>> 
>> So the accessible text is just the right number of "echo" chars.
>> And you are still calling getPassword() just so you can find out the length.
>> Then it is over-written. There's a really tiny window after getPassword() and before Arrays.fill() when the clear password is still there. 
>> The number of "char"s isn't the same as the number of "characters" if there's a non-BMP code point in there .. perhaps these are not allowed by this class .. but it makes me wonder how much if having the exact number of echo chars as the actual password is important.  I wonder how many text-to-speech readers can say "bullet" for a unicode bullet character ? 
>> 
>> If it weren't for all of this (the class and the getPassword() method being non-final I'd suggest you look into a way to pull just the length rather than the actual chars.
>
>> So the accessible text is just the right number of "echo" chars.
> Yes.
>> And you are still calling getPassword() just so you can find out the length.
>> Then it is over-written. There's a really tiny window after getPassword() and before Arrays.fill() when the clear password is still there.
> 
> Yes. But not as a string - and the window of opportunity to get the characters before they are overwritten by the echo characters is minimal.
> 
>> The number of "char"s isn't the same as the number of "characters" if there's a non-BMP code point in there .. 
> 
> Since in order to enter non-BPM characters you have to have an input methods helper which should be disabled on password fields for obvious reason - it would pretty much disclose the typed password in the IM helper window - the only way to enter such symbols would b copy/paste and in this case i do not expect it to be edited within password field.
> 
>> perhaps these are not allowed by this class .. but it makes me wonder how much if having the exact number of echo chars as the actual password is important. I wonder how many text-to-speech readers can say "bullet" for a unicode bullet character ?
> 
> Well, accessibility is not only about text to speech - it is also about easier navigation so having exact number of the bullets is preferable. There are limitations - like some non-BPM text can be pasted into the password field and then navigating within it might be broken but since there will be no IM engaged fixing it would be equally problematic.
> 
>> If it weren't for all of this (the class and the getPassword() method being non-final I'd suggest you look into a way to pull just the length rather than the actual chars.
> 
> That would be preferable but under the current circumstances i would say that my fix makes things better without adding incompatible changes.

Why not use the "getDocument().getLength()"?

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From serb at openjdk.java.net  Wed Jun 30 04:54:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 04:54:06 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
 <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
Message-ID: <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>

On Wed, 30 Jun 2021 04:22:37 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> No, the native code will fail to load the icon
So what call will fail? Is the "sf.getIcon()" return null? in what line of code?

>> But you cannot change the return type later, so all these instanceof+casts will be there forever.
>
>> But you cannot change the return type later, so all these instanceof+casts will be there forever.
> 
> Well, if there is a reason the API can be amended in the future version of Java. It is not cast in stone. Yes, it will require some justification, but if justification is provided then API can be changed.

Not in this case, you cannot change the public signature.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From serb at openjdk.java.net  Wed Jun 30 04:54:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 04:54:07 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <YQyBqJrQNyP3ROk3LeO9N4fdZ_ysLMK-D76yPlE5jLw=.bb264a73-80e2-48f1-bd99-2bab4da941ef@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <YQyBqJrQNyP3ROk3LeO9N4fdZ_ysLMK-D76yPlE5jLw=.bb264a73-80e2-48f1-bd99-2bab4da941ef@github.com>
Message-ID: <lR_IePkfbywmzQ1YpaZEKXZn4aKi3VrJXWIwwgDIdS8=.a8d1390a-cef4-44a0-9f19-1728a089f4e7@github.com>

On Wed, 30 Jun 2021 04:23:45 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 76:
>> 
>>> 74:         int[] sizes = new int[] {16, 32, 48, 64, 128};
>>> 75:         for (int size : sizes) {
>>> 76:             ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);
>> 
>> Probably we can wrap the  "UIManager.getIcon" in the "ImageIcon"?
>
>> Probably we can wrap the "UIManager.getIcon" in the "ImageIcon"?
> 
> Why? In some LaFs that might be a procedural image that generates it content every time paint() is called on it - i do not think wrapping it in the ImageIcon will solve anything.

If it is generated every time, then it will be wrapped every time as well. The difference is that it will not be needed to check the type of the icon. Even now, on Windows it is necessary to check is the returned object ImageIcon or not.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 14:58:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 14:58:28 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField [v2]
In-Reply-To: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
Message-ID: <gs0fsciT_qYidXOXuC6ftQQfla_M1xTZ_bjZq3ew-Gg=.5cac7acf-fdbc-4efd-9173-18bf510d5b3f@github.com>

> 8268775: Password is being converted to String in AccessibleJPasswordField

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

  Use getDocumnt().getLength() instead of requesting password as an array of chars and counting its length

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/127/files
  - new: https://git.openjdk.java.net/jdk17/pull/127/files/372202b4..6c57265c

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

  Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/127/head:pull/127

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Wed Jun 30 14:58:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 14:58:29 GMT
Subject: <Swing Dev> [jdk17] RFR: 8268775: Password is being converted
 to String in AccessibleJPasswordField [v2]
In-Reply-To: <dJkS9637ya6cHqa7_9nzTblKAQisjhmbf44jbVNuojY=.fdfa1400-df34-44c1-9bb0-557da6825aa2@github.com>
References: <VjdYawHKAXio6TI1NlC6beavJx6fPrQOtxxCyneT0eU=.6c236ef0-2766-4964-94e0-0b192bded370@github.com>
 <_n1Ax8kkMDN7PT2ZGrC4zIQEHVho4kR_Ljcscrz-754=.e642e2af-24c3-4a2b-bb27-dc1f28f25c45@github.com>
 <i9GpZSY2U1fObyFMakgcLdBcIu9s5peyJ87r999RwXo=.28d65393-1686-4d3f-b84f-8e5a3c120e79@github.com>
 <dJkS9637ya6cHqa7_9nzTblKAQisjhmbf44jbVNuojY=.fdfa1400-df34-44c1-9bb0-557da6825aa2@github.com>
Message-ID: <VDTOaJSMCMpQHQ54VRsvycysAptdKNq_cGdG8XaiUXE=.802845db-2869-4941-88cf-b41ff10bdeba@github.com>

On Wed, 30 Jun 2021 04:40:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why not use the "getDocument().getLength()"?

We can surely do that. Fixed.

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

PR: https://git.openjdk.java.net/jdk17/pull/127

From kizune at openjdk.java.net  Wed Jun 30 18:37:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 18:37:02 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <lR_IePkfbywmzQ1YpaZEKXZn4aKi3VrJXWIwwgDIdS8=.a8d1390a-cef4-44a0-9f19-1728a089f4e7@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <YQyBqJrQNyP3ROk3LeO9N4fdZ_ysLMK-D76yPlE5jLw=.bb264a73-80e2-48f1-bd99-2bab4da941ef@github.com>
 <lR_IePkfbywmzQ1YpaZEKXZn4aKi3VrJXWIwwgDIdS8=.a8d1390a-cef4-44a0-9f19-1728a089f4e7@github.com>
Message-ID: <EM6h_Dz5bVhLQz3AI6Q1UjecTO38y0Nks0MWNMn6zvY=.b3fca461-94e7-4aed-8a3f-ef5186d0b463@github.com>

On Wed, 30 Jun 2021 04:45:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Even now, on Windows it is necessary to check is the returned object ImageIcon or not.

Yes but since API states that returned type is an Icon it should be done anyways - because we might wrap up Icon in ImageIcon locally but we can't force any 3rd party Java implementation to do the same so there will be requirement to check the returned type - unless we change the API to always return ImageIcon or MultiResolutionImageIcon or something even more complicated.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 18:37:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 18:37:03 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
 <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
 <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
Message-ID: <9sP3jjqR5onv_ZQYNsGUtZsgiMkLxal4hvNDa1YCb_I=.748b6a55-ea0c-476a-a9ed-fd408c32dc80@github.com>

On Wed, 30 Jun 2021 04:43:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Not in this case, you cannot change the public signature.

Well, it is a change in API and should be done within the same process as any API change. But it definitely can be done in the future major release.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 19:22:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 19:22:07 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
 <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
 <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
Message-ID: <gGtDmYPDeEvZjBb5UJFkMTOJmQBf2rK7rNziIx8j-jk=.5676f435-e723-4bc1-9413-28017cf92926@github.com>

On Wed, 30 Jun 2021 04:51:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> * but what happens if the file cannot be read? We will call the "sf = ShellFolder.getShellFolder" and then we call "sf.getIcon()" and it returns what? As far as I understand it always return MultiResolutionIconImage, no?
>>> *
>> 
>> No, the native code will fail to load the icon but since file does exist and we only return null for nonexistent file we will fall back to UIManager.getIcon which returns icon from the installed LAF resource bundle. This is correct behavior since otherwise we might end in file manager with file that has no icon at all. Right now that will be a single resolution icon for all the LAFs. Again, in the future that can be changed but right now it is a single resolution icon.
>
>> No, the native code will fail to load the icon
> So what call will fail? Is the "sf.getIcon()" return null? in what line of code?

Yes, from my remote debugging it happens in sf.getIcon() but the circumstances are quite rare - file has to be inaccessible and the user's GUI session should not be initialized - that's why this failure only happens on headless testing. Another solution would be to mark this test as headful - that would solve issue as well.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From prr at openjdk.java.net  Wed Jun 30 19:30:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Jun 2021 19:30:02 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <gGtDmYPDeEvZjBb5UJFkMTOJmQBf2rK7rNziIx8j-jk=.5676f435-e723-4bc1-9413-28017cf92926@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
 <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
 <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
 <gGtDmYPDeEvZjBb5UJFkMTOJmQBf2rK7rNziIx8j-jk=.5676f435-e723-4bc1-9413-28017cf92926@github.com>
Message-ID: <6NOvyjGvKSF1mMx4i3rJx50voUD26_zDrNCbErnSvX4=.dfc6de40-30af-4283-86f8-dad2fe908c1a@github.com>

On Wed, 30 Jun 2021 19:19:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> No, the native code will fail to load the icon
>> So what call will fail? Is the "sf.getIcon()" return null? in what line of code?
>
> Yes, from my remote debugging it happens in sf.getIcon() but the circumstances are quite rare - file has to be inaccessible and the user's GUI session should not be initialized - that's why this failure only happens on headless testing. Another solution would be to mark this test as headful - that would solve issue as well.

I am a bit surprised the tests for this are not already headful. I can imagine all sorts of platform reasons why making them headless is not testing the "real" use case making the tests less than useful.
Ever seen a hidpi  headless system ??

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 20:15:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 20:15:03 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException
In-Reply-To: <6NOvyjGvKSF1mMx4i3rJx50voUD26_zDrNCbErnSvX4=.dfc6de40-30af-4283-86f8-dad2fe908c1a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
 <ATH_ZQ3cRvNlmikY6aS9aUozYh8L4m3yzCBGA1uHOGk=.4fdafd54-fe6a-410d-9e55-8f45f9c8fc8a@github.com>
 <B5vuDcgYfDYJBhYLEQ6UVpdS5IqOK7ipwDfMr6LsIWc=.bb647df9-7281-4c3a-b3fe-2c994d57617c@github.com>
 <5Kj7pE9BqSZ-7HeAMi2LOypGqQYVLw7MAdYetgWkLkE=.c398912c-ccd7-4f38-8a5d-ba7a80f7566b@github.com>
 <W5MrRqoBL0OwYGrnqyzgryC6uF6dFK7yaQL9HJ5AVbI=.6bd6ebbd-5554-474c-a2b8-980a345b80f2@github.com>
 <j_vuA-tc2uN5L3eQab_t1inr6Buorc90su6aNKoUQA4=.771278c4-562d-432d-9654-e06f485925b3@github.com>
 <gGtDmYPDeEvZjBb5UJFkMTOJmQBf2rK7rNziIx8j-jk=.5676f435-e723-4bc1-9413-28017cf92926@github.com>
 <6NOvyjGvKSF1mMx4i3rJx50voUD26_zDrNCbErnSvX4=.dfc6de40-30af-4283-86f8-dad2fe908c1a@github.com>
Message-ID: <I7DGoer_OL_mBvPYf6Oni-nfhJtr7Z7zDqaQuwewzYk=.a3f25455-d12a-42f8-b6d0-3dc17ffb4a60@github.com>

On Wed, 30 Jun 2021 19:27:25 GMT, Phil Race <prr at openjdk.org> wrote:

> I am a bit surprised the tests for this are not already headful

Fixed.

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

PR: https://git.openjdk.java.net/jdk17/pull/178

From kizune at openjdk.java.net  Wed Jun 30 20:31:45 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 30 Jun 2021 20:31:45 GMT
Subject: <Swing Dev> [jdk17] RFR: 8269269: [macos11] SystemIconTest
 fails with ClassCastException [v2]
In-Reply-To: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
References: <0Y9eKhCMrR3no6CZinY4yHGTYaLbzlHRdI1oCNgSryw=.a700fdcb-6b58-4ce2-aff7-2ef053250b2a@github.com>
Message-ID: <oc4-pv4yuPGS8KMBoBhiTHhALmc4MuW2Tvq-tANL3tE=.dafe0508-46a9-484b-815e-38f96a3b950e@github.com>

> Added check for the icon class type
> Added check if file or folder we are testing against exists and
> accessible
> Removed test from problem list

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

  Mark test as headful

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/178/files
  - new: https://git.openjdk.java.net/jdk17/pull/178/files/e91d6500..28f2d43a

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

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

PR: https://git.openjdk.java.net/jdk17/pull/178