Re: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3]

2022-05-12 Thread Weijun Wang
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with >> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when >> called with vararg of size 0, 1, 2. >> >> In general replacement of

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v5]

2022-05-02 Thread Weijun Wang
On Fri, 29 Apr 2022 15:51:12 GMT, Weijun Wang wrote: >> test/lib/jdk/test/lib/util/FileUtils.java line 389: >> >>> 387: * @throws IOException >>> 388: */ >>> 389: public static void patch(Path path, int fromLine, int toLine, >>

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v9]

2022-05-02 Thread Weijun Wang
On Mon, 2 May 2022 13:01:40 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > 8285452: Tests updated Marked as reviewed

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v7]

2022-04-29 Thread Weijun Wang
On Fri, 29 Apr 2022 14:19:40 GMT, Daniel Fuchs wrote: >> The comparison is intentionally made lax so the caller does not need to >> provide the exact indentation or even new line characters. We think along >> with `fromLine` and `toLine` this is enough to make sure we are not >> modifying the

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v5]

2022-04-29 Thread Weijun Wang
On Fri, 29 Apr 2022 12:02:59 GMT, Jaikiran Pai wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one >> additional commit since the last revision: >> >> updated to add space character in begining of multiline string > > test/lib/jdk/test/lib/util/FileUtils.java line

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v7]

2022-04-29 Thread Weijun Wang
On Fri, 29 Apr 2022 12:44:26 GMT, Daniel Fuchs wrote: >> test/lib/jdk/test/lib/util/FileUtils.java line 394: >> >>> 392: var removed = ""; >>> 393: for (int i = fromLine; i <= toLine; i++) { >>> 394: removed += lines.remove(fromLine - 1).trim(); >> >>

Re: RFR: 8285452: Add a new test library API to replace a file content using FileUtils.java [v4]

2022-04-29 Thread Weijun Wang
On Fri, 29 Apr 2022 10:36:50 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > 8285452: Add a new test library API to

Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]

2022-04-27 Thread Weijun Wang
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java I've updated the

Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]

2022-04-27 Thread Weijun Wang
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java Currently it's just

Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]

2022-04-27 Thread Weijun Wang
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java Or we can provide

Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]

2022-04-26 Thread Weijun Wang
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java We have a test that

Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]

2022-04-22 Thread Weijun Wang
On Fri, 22 Apr 2022 16:06:22 GMT, Daniel Fuchs wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update FileUtils.java > > test/lib/jdk/test/lib/util/FileUtils.java line 402: > >> 400: if

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]

2022-03-22 Thread Weijun Wang
On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-16 Thread Weijun Wang
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

2022-03-15 Thread Weijun Wang
On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java >> line 122: >> >>> 120: default -> { >>> 121: throw new ProviderException >>> 122: ("Unrecognized

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

2022-03-14 Thread Weijun Wang
On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-11 Thread Weijun Wang
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata The security related changes look

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]

2022-03-09 Thread Weijun Wang
On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]

2022-03-09 Thread Weijun Wang
On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

2022-02-24 Thread Weijun Wang
On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote: >> Please review this PR that enables >> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) >> compiler flag, which makes assigning a string

RFR: 8281175: Add a -providerPath option to jarsigner

2022-02-03 Thread Weijun Wang
Add the `-providerPath` option to jarsigner to be consistent with keytool. - Commit messages: - 8281175: Add a -providerPath option to jarsigner Changes: https://git.openjdk.java.net/jdk/pull/7338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7338=00 Issue:

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10]

2022-01-26 Thread Weijun Wang
On Wed, 26 Jan 2022 16:25:24 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > >> 118: >> 119: boolean

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10]

2022-01-26 Thread Weijun Wang
On Wed, 26 Jan 2022 16:27:29 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > >> 199: return

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 22:11:51 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 15:54:01 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line >> 100: >> >>> (failed to retrieve contents of file, check the PR for context) >> I think this method should stay here. Suppose one day the CBT type is >>

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 13:54:12 GMT, Daniel Fuchs wrote: >> Michael McMahon 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 eight additional >>

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4]

2022-01-24 Thread Weijun Wang
On Fri, 21 Jan 2022 15:40:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> more tidy-up > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > >> 142:

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5]

2022-01-21 Thread Weijun Wang
On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5]

2022-01-21 Thread Weijun Wang
On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2]

2022-01-19 Thread Weijun Wang
On Wed, 19 Jan 2022 22:20:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 10:18:50 GMT, Daniel Fuchs wrote: >> This is what was intended (equivalent) >> >> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` > > Argh - you're right I missed the fact that the 3 expressions where included > in parenthesis. I read it as > > !

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 18:40:41 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: >> >>> 150: * If enabled (for a particular destination) then SPNEGO >>> authentication requests will include >>> 151: * a channel binding token for the

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 18:42:08 GMT, Michael McMahon wrote: >> src/java.security.jgss/share/classes/module-info.java line 36: >> >>> 34: module java.security.jgss { >>> 35: requires java.naming; >>> 36: requires java.security.sasl; >> >> Someone from security-dev should probably review

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest >> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly >> returning null indicating that the jar entry has no signers. >> >> This fixes the

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 19:54:44 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java >> line 211: >> >>> 209: } >>> 210: >>> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >> >> What if we return here if `entrySigners ==

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs

2022-01-13 Thread Weijun Wang
On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest > algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly > returning null indicating that the jar entry has no signers. > > This fixes the issue

RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa

2021-12-01 Thread Weijun Wang
Update Public Suffix List data to the latest version at https://github.com/publicsuffix/list. - Commit messages: - 8255266: 2021-11-27 public suffix list update v 3c213aa Changes: https://git.openjdk.java.net/jdk/pull/6643/files Webrev:

Integrated: 8270380: Change the default value of the java.security.manager system property to disallow

2021-10-21 Thread Weijun Wang
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.s

Integrated: 8275512: Upgrade required version of jtreg to 6.1

2021-10-19 Thread Weijun Wang
On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. > jtreg 6.1 does not set its own security manager if JDK version is >= 18. This pull request has now been integrated. Changeset: c24fb852 Author: We

Re: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2]

2021-10-19 Thread Weijun Wang
> As a follow up of JEP 411, we will soon disallow security manager by default. > jtreg 6.1 does not set its own security manager if JDK version is >= 18. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: upgrade the versi

RFR: 8275512: Upgrade required version of jtreg to 6.1

2021-10-19 Thread Weijun Wang
As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. - Commit messages: - 8275512: Upgrade required version of jtreg to 6.1 Changes: https://git.openjdk.java.net/jdk/pull/6012/files

Re: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base

2021-10-08 Thread Weijun Wang
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check > if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to

Re: RFR: 8274333: Redundant null comparison after Pattern.split

2021-10-04 Thread Weijun Wang
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote: > In couple of classes, result part of arrays of Pattern.split is compared with > `null`. Pattern.split (and hence String.split) never returns `null` in array > elements. Such comparisons are redundant. Marked as reviewed by weijun

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-09-28 Thread Weijun Wang
On Tue, 31 Aug 2021 02:05:06 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system >> property from "allow" to "disallow". This means unless it's explicitly set >> to "allow", any call to

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

2021-09-21 Thread Weijun Wang
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. Looks fine. Thanks. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5551

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-30 Thread Weijun Wang
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.s

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2]

2021-08-30 Thread Weijun Wang
urityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where > a security manager [will not be > set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). Weijun Wang has updated the pull request incrementally with one additional co

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-23 Thread Weijun Wang
On Mon, 23 Aug 2021 03:22:18 GMT, Jaikiran Pai wrote: > Would this then allow the security manager to be used? In other words, can > the value of `java.security.manager` be changed dynamically at runtime or is > it restricted to be set only at launch time (via command line arugment >

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-23 Thread Weijun Wang
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.s

Re: RFR: 8272805: Avoid looking up standard charsets

2021-08-22 Thread Weijun Wang
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-21 Thread Weijun Wang
On Sat, 21 Aug 2021 16:59:39 GMT, Alan Bateman wrote: >> This is the same as the existing words for "disallow". > > I think I agree with Lance that "Throws UOE" would be clearer in this table. Suggestion accepted. - PR: https://git.openjdk.java.net/jdk/pull/5204

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-21 Thread Weijun Wang
On Fri, 20 Aug 2021 23:01:27 GMT, Lance Andersen wrote: >> This change modifies the default value of the `java.security.manager` system >> property from "allow" to "disallow". This means unless it's explicitly set >> to "allow", any call to `System.setSecurityManager()` would throw an UOE. >>

RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-20 Thread Weijun Wang
This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. The `AllowSecurityManager.java` and `SecurityManagerWarnings.java`

Integrated: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result

2021-08-03 Thread Weijun Wang
On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's > even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local > variable

RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result

2021-08-03 Thread Weijun Wang
oddPart contains a lot of info on the modInverse output, sometimes it's even the same. Clearing it in case the result is sensitive. No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. - Commit

Re: RFR: 8266054: VectorAPI rotate operation optimization [v13]

2021-07-27 Thread Weijun Wang
On Tue, 20 Jul 2021 09:57:07 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and >> rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res =

[jdk17] Integrated: 8269543: The warning for System::setSecurityManager should only appear once for each caller

2021-07-02 Thread Weijun Wang
On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang wrote: > Add a cache to record which sources have called `System::setSecurityManager` > and only print out warning lines once for each. This pull request has now been integrated. Changeset: c4ea13ed Author:Weijun Wang URL:

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

2021-06-30 Thread Weijun Wang
On Wed, 30 Jun 2021 06:32:04 GMT, Alan Bateman wrote: >> I hope this is uncommon but if that class is loaded by a `ClassLoader` again >> and again then it will be different each time. I'll investigate more. > > WeakHashMap, Boolean>, where the key is the caller, should be okay > (assume

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

2021-06-30 Thread Weijun Wang
> Add a cache to record which sources have called `System::setSecurityManager` > and only print out warning lines once for each. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update cache key from String to

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

2021-06-29 Thread Weijun Wang
On Tue, 29 Jun 2021 19:57:24 GMT, Roger Riggs wrote: >> If I switch to a "non-weak" set or map, then it seems I can safely use the >> source string as the key. Will using the Class object as a key prevent them >> from unloading? > > Using a synchronized WeakHashMap with the class as the key

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

2021-06-29 Thread Weijun Wang
On Tue, 29 Jun 2021 19:23:26 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/System.java line 337: >> >>> 335: = Collections.synchronizedMap(new WeakHashMap<>()); >>> 336: } >>> 337: >> >> I wonder about the use of a WeakHashMap here. That may work well when

[jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

2021-06-29 Thread Weijun Wang
Add a cache to record which source has called `System::setSecurityManager` and only print out warning lines once for each. - Commit messages: - renaming variables, two callers in test - one warning for each caller Changes: https://git.openjdk.java.net/jdk17/pull/166/files

Integrated: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang wrote: > More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. > > Note: this is copied from https://github.com/

RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
More refactoring to limit the scope of `@SuppressWarnings` annotations. Sometimes I introduce new methods. Please feel free to suggest method names you like to use. Note: this is copied from https://github.com/openjdk/jdk17/pull/152. - Commit messages: - copy all code change from

[jdk17] Withdrawn: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-28 Thread Weijun Wang
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote: > More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. This pull request has been closed without bein

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-28 Thread Weijun Wang
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote: >> More refactoring to limit the scope of `@SuppressWarnings` annotations. >> >> Sometimes I introduce new methods. Please feel free to suggest method names >> you like to use. > > Weijun Wang has updated

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-28 Thread Weijun Wang
On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs wrote: >> This cast is only to tell the compiler which overloaded method to call, and >> I don't think there will be a real cast at runtime. It might look a little >> ugly but extracting it into a variable declaration/definition plus a new >>

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v3]

2021-06-28 Thread Weijun Wang
> More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-26 Thread Weijun Wang
On Sat, 26 Jun 2021 16:53:30 GMT, Alan Bateman wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> one more > > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java lin

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

2021-06-25 Thread Weijun Wang
> More refactoring to limit the scope of `@SuppressWarnings` annotations. > > Sometimes I introduce new methods. Please feel free to suggest method names > you like to use. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

[jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

2021-06-25 Thread Weijun Wang
More refactoring to limit the scope of `@SuppressWarnings` annotations. Sometimes I introduce new methods. Please feel free to suggest method names you like to use. - Commit messages: - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K Changes:

Withdrawn: 8268349: Provide more detail in JEP 411 warning messages

2021-06-10 Thread Weijun Wang
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jd

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 17:15:29 GMT, Alan Bateman wrote: >> I thought about that but not sure of performance impact. Is the worst >> problem that more than one warnings will be printed for a single caller? >> It's not really harmless. >> >> As for the frame, if the warning message only contain

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 06:11:17 GMT, Alan Bateman wrote: >> More loudly and precise warning messages when a security manager is either >> enabled at startup or installed at runtime. > > src/java.base/share/classes/java/lang/System.java line 331: > >> 329: >> 330: // Remember original

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-08 Thread Weijun Wang
On Tue, 8 Jun 2021 06:41:11 GMT, Alan Bateman wrote: > > You might want to make your "WARNING" consistent with the VM's "Warning" so > > that OutputAnalyzer's logic to ignore warnings will automatically ignore > > these too. > > The uppercase "WARNING" is intentional here, it was the same

RFR: 8268349: Provide more detail in JEP 411 warning messages

2021-06-07 Thread Weijun Wang
More loudly and precise warning messages when either a security manager is enabled at startup or installed at runtime. - Commit messages: - 8268349: Provide more detail in JEP 411 warning messages Changes: https://git.openjdk.java.net/jdk/pull/4400/files Webrev:

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

2021-06-02 Thread Weijun Wang
On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang 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 usag

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v4]

2021-06-02 Thread Weijun Wang
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

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

2021-06-02 Thread Weijun Wang
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang 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.c

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v9]

2021-06-02 Thread Weijun Wang
ions 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 conta

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Weijun Wang
ions 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 contain

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7]

2021-06-01 Thread Weijun Wang
ions 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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

2021-05-31 Thread Weijun Wang
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang 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. >

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

2021-05-31 Thread Weijun Wang
ions 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:

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-27 Thread Weijun Wang
On Fri, 28 May 2021 03:12:35 GMT, Phil Race wrote: >> There *is* a tiny refactoring here: a new variable `s2` is introduced so the >> 2nd `doPrivileged` call on line 636 is now also in a declaration statement >> (for `s2`) and therefore annotatable. Without this I cannot add the >> annotation

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-27 Thread Weijun Wang
On Thu, 27 May 2021 17:42:56 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update FtpClient.java > > src/java.desktop/share/classes/java/awt/Component.java line 63

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5]

2021-05-27 Thread Weijun Wang
On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang 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. >

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5]

2021-05-27 Thread Weijun Wang
ions 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 c

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-24 Thread Weijun Wang
On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs wrote: > Thanks for taking in my suggestions for FtpClient. I have also reviewed the > changes to java.util.logging and JMX. I wish there was a way to handle > doPrivileged returning void more nicely. Maybe component maintainers will be > able to

Integrated: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

2021-05-24 Thread Weijun Wang
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityM

Re: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v4]

2021-05-24 Thread Weijun Wang
ts}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => > permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request with

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4]

2021-05-24 Thread Weijun Wang
On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 104: >> >>> 102: * method will throw an {@code UnsupportedOperationException}). If the >>> 103: * {@systemProperty java.security.manager} system property is set to >>> the

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4]

2021-05-24 Thread Weijun Wang
ions 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:

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote: > I haven't seen any response to this comment I made a couple of days ago and I > suspect it got missed > > > Weijun Wang has updated the pull request incrementally with one additional > > commit since the last rev

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-21 Thread Weijun Wang
ated method call to a new local > variable and add annotation on the declaration, and then assign that value to > the original l-value. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. Weijun Wang has updated the pull request i

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpC

Re: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v3]

2021-05-21 Thread Weijun Wang
ts}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => > permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request i

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adjust order of VM options > > test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile

  1   2   3   4   5   6   >