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

2022-06-01 Thread Roger Riggs
On Wed, 1 Jun 2022 07:50:58 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: 8282662: Use List.of() factory method to reduce memory consumption [v8]

2022-05-31 Thread Roger Riggs
On Tue, 31 May 2022 19:30:07 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: 8282662: Use List.of() factory method to reduce memory consumption [v8]

2022-05-31 Thread Roger Riggs
On Tue, 31 May 2022 19:30:07 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: 8282662: Use List.of() factory method to reduce memory consumption [v7]

2022-05-31 Thread Roger Riggs
On Tue, 31 May 2022 07:40:56 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: 8286045: Use ForceGC for cleaner test cases

2022-05-25 Thread Roger Riggs
On Wed, 25 May 2022 15:20:45 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the test case update reviewed? > > This patch is trying to use ForceGC for cleaner test cases. As would make > the test more stable and easier to maintain. > > Thanks, > Xuelei The usage looks fine. (But

Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2]

2022-05-23 Thread Roger Riggs
On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments

Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults

2022-05-23 Thread Roger Riggs
On Tue, 10 May 2022 19:24:24 GMT, Mark Powers wrote: >> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: >> >>> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { >>> 776: printStackWhenAccessFails = GetBooleanAction. >>> 777:

Integrated: 8286393: Address possibly lossy conversions in java.rmi

2022-05-13 Thread Roger Riggs
On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about > lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conve

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

2022-05-13 Thread Roger Riggs
On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman wrote: >> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: >> >>> 126: // timed poll interrupted so need to adjust timeout >>> 127: long adjust = System.nanoTime() - startTime; >>> 128:

RFR: 8286393: Address possibly lossy conversions in java.rmi

2022-05-12 Thread Roger Riggs
Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. Explicit casts are inserted where implicit casts occur. 8286393: Address possibly lossy conversions in java.rmi 8286388: Address possibly lossy conversions in java.smartcardio

Integrated: 8286378: Address possibly lossy conversions in java.base

2022-05-12 Thread Roger Riggs
On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy > conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not > assignment compatible with the type

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

2022-05-11 Thread Roger Riggs
nd suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Updated copyrights Fixed cast style to add a space after cast, (where consistent with file style) Improved code per

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

2022-05-10 Thread Roger Riggs
nd suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: remove stray file - Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://g

RFR: 8286378: Address possibly lossy conversions in java.base

2022-05-10 Thread Roger Riggs
PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >From the CSR: "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While

Re: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released

2022-04-28 Thread Roger Riggs
On Thu, 28 Apr 2022 12:19:35 GMT, Sean Mullan wrote: >> Hi, >> >> May I have this test update reviewed? >> >> The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java >> test case failed on one of the test setups. The test runs gc in a loop and >> expects the GC to have

Re: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released

2022-04-28 Thread Roger Riggs
On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test > case failed on one of the test setups. The test runs gc in a loop and > expects the GC to have

Re: RFR: 8284910: Buffer clean in PasswordCallback [v8]

2022-04-27 Thread Roger Riggs
On Wed, 27 Apr 2022 16:02:05 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback >> implementation. This is one of the effort to clean up the buffered >> passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not

Re: RFR: 8284910: Buffer clean in PasswordCallback [v2]

2022-04-20 Thread Roger Riggs
On Wed, 20 Apr 2022 19:59:16 GMT, Sean Mullan wrote: >>> Won't there be a small performance hit (perhaps negligible) for code that >>> already calls clearPassword? >> >> The impact should be minimal. If clearPassword() has been called, the >> cleanup (Cleanerable.clean()) won't happen again

Re: RFR: 8284910: Buffer clean in PasswordCallback [v2]

2022-04-18 Thread Roger Riggs
On Mon, 18 Apr 2022 18:15:25 GMT, Sean Mullan wrote: >> setPassword can/should always clear the previous password. It is an >> internal copy that no one else has a reference to and is being replaced. >> It will need to either explicitly call cleanable.clean() or fill/erase the >> array

Re: RFR: 8284910: Buffer clean in PasswordCallback [v2]

2022-04-18 Thread Roger Riggs
On Mon, 18 Apr 2022 17:27:04 GMT, Sean Mullan wrote: >> src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java >> line 123: >> >>> 121: cleanable = CleanerFactory.cleaner().register( >>> 122: this, cleanerFor(inputPassword)); >>> 123:

Re: RFR: 8284910: Buffer clean in PasswordCallback

2022-04-18 Thread Roger Riggs
On Sat, 16 Apr 2022 15:45:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this password cleanup enhancement in the PasswordCallback > implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not

Re: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v4]

2022-04-15 Thread Roger Riggs
On Fri, 15 Apr 2022 15:04:20 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for >> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which >> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, >> there is a

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-07 Thread Roger Riggs
On Thu, 7 Apr 2022 19:21:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8284490: Remove finalizer method in java.security.jgss

2022-04-07 Thread Roger Riggs
On Thu, 7 Apr 2022 10:51:13 GMT, Daniel Fuchs wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > >

Re: RFR: 8282819: Deprecate Locale class constructors

2022-03-25 Thread Roger Riggs
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create

Re: RFR: 8282819: Deprecate Locale class constructors

2022-03-25 Thread Roger Riggs
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create

Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2]

2022-03-08 Thread Roger Riggs
On Tue, 8 Mar 2022 05:51:21 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204: >> >>> 202: } catch (GeneralSecurityException | java.io.IOException e) >>> { >>> 203: throw new SSLHandshakeException( >>> 204:

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-04 Thread Roger Riggs
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7268

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

2022-03-04 Thread Roger Riggs
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client

Re: RFR: 8282279: Interpret case-insensitive string locale independently

2022-02-23 Thread Roger Riggs
On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan wrote: > The String.toUpperCase() or String.toLowerCase() method is locale sensitive, > and may produce unexpected results if used for strings that are intended to > be interpreted locale independently. The use of the two methods had been

Re: RFR: 8272777: Clean up remaining AccessController warnings in test library

2022-02-02 Thread Roger Riggs
On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") > annotation (which has already been widely applied). Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7328

Re: RFR: JDK-8281082: Improve javadoc references to JOSS

2022-02-01 Thread Roger Riggs
On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not > done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Marked as reviewed by rriggs (Reviewer).

Re: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed [v2]

2022-01-27 Thread Roger Riggs
On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: >> jstatd fails to start because SecurityManager is

Re: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed

2022-01-07 Thread Roger Riggs
On Wed, 22 Dec 2021 21:41:13 GMT, Mandy Chung wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: >> jstatd fails to start because SecurityManager is

Re: RFR: 8277932: Subject:callAs() not throwing NPE when action is null

2021-12-06 Thread Roger Riggs
On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote: > Add null check. I must have thought the NPE will be thrown anyway but the > `catch Exception` block swallows it. > > I added a noreg-trivial label. If you think differently can add one. Yes, the stack trace will be more useful with the

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

2021-11-19 Thread Roger Riggs
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API

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

2021-11-18 Thread Roger Riggs
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 rriggs

Re: RFR: 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath [v2]

2021-11-15 Thread Roger Riggs
On Mon, 15 Nov 2021 21:53:56 GMT, Sean Mullan wrote: >> Please review this 20+ year old bug (!), which marks the non-serializable >> fields of Certificate and CertPath with the transient modifier. These >> classes use an alternate serialization mechanism by overriding the >> writeReplace

Re: RFR: 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath

2021-11-15 Thread Roger Riggs
On Mon, 15 Nov 2021 19:05:27 GMT, Sean Mullan wrote: > > The serialized form doc for both classes should say something about what is > > serialized. Since it is using writeReplace, it can indicate that > > CertificateRep/CertPathRep is used instead (and the arguments). likely > > you'll need

Re: RFR: 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath

2021-11-15 Thread Roger Riggs
On Mon, 15 Nov 2021 17:03:51 GMT, Sean Mullan wrote: > Please review this 20+ year old bug (!), which marks the non-serializable > fields of Certificate and CertPath with the transient modifier. These classes > use an alternate serialization mechanism by overriding the writeReplace > method.

Re: RFR: 8276348: Use blessed modifier order in java.base

2021-11-02 Thread Roger Riggs
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it at > mass? > > As far as I remember, the first mass-canonicalization of modifiers took place

Re: RFR: 8276348: Use blessed modifier order in java.base

2021-11-02 Thread Roger Riggs
On Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard wrote: >> Here's a bit of archaeology. I found the original JDK-8136583 patch, which >> has moved from where it was in the RFR to >> https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. >> That patch doesn't change

Re: RFR: 8276348: Use blessed modifier order in java.base

2021-11-02 Thread Roger Riggs
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it at > mass? > > As far as I remember, the first mass-canonicalization of modifiers took place

Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

2021-09-02 Thread Roger Riggs
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read

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

2021-08-31 Thread Roger Riggs
On Tue, 31 Aug 2021 02:08:48 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.setSecurityManager()` would throw an UOE. >> >>

Re: RFR: 8272626: Avoid C-style array declarations in java.*

2021-08-18 Thread Roger Riggs
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch > cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) 34 Minutes from proposed to integrated! Its

[jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example

2021-07-29 Thread Roger Riggs
On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread > example. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk17/pull/292

[jdk17] RFR: 8271489: (doc) Clarify Filter Factory example

2021-07-29 Thread Roger Riggs
Improve the clarity of comments in the ObjectInputFilter FilterInThread example. - Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int -

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} for java.base [v11]

2021-07-12 Thread Roger Riggs
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has refreshed the contents of this pull

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

2021-06-29 Thread Roger Riggs
On Tue, 29 Jun 2021 19:35:40 GMT, Weijun Wang wrote: >> Using a HashSet could use the callerClass as the key and be a stable >> reference for having given the message. >> or use a ConcurrentHashMap>, boolean> and avoid any separate >> synchronization that would be needed with a HashSet or

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

2021-06-29 Thread Roger Riggs
On Tue, 29 Jun 2021 18:47:23 GMT, Daniel Fuchs wrote: >> Add a cache to record which sources have called `System::setSecurityManager` >> and only print out warning lines once for each. > > src/java.base/share/classes/java/lang/System.java line 337: > >> 335: =

Re: RFR: 8267123: Remove RMI Activation

2021-05-26 Thread Roger Riggs
On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to

Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v5]

2021-05-07 Thread Roger Riggs
On Thu, 6 May 2021 14:42:20 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the >> `java.security` package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull

Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v3]

2021-05-06 Thread Roger Riggs
On Thu, 6 May 2021 11:52:15 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the >> `java.security` package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull

Re: RFR: 8265426: Update java.security to use instanceof pattern variable

2021-04-26 Thread Roger Riggs
On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the > `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Marked as reviewed by rriggs (Reviewer).

Re: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64

2021-04-24 Thread Roger Riggs
On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. Marked as reviewed by rriggs (Reviewer).

Re: RFR: 8264208: Console charset API [v12]

2021-04-22 Thread Roger Riggs
On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been

Re: RFR: 8264208: Console charset API [v11]

2021-04-22 Thread Roger Riggs
On Thu, 22 Apr 2021 16:11:16 GMT, Naoto Sato wrote: >> Not always, for example, if stderr was redirected to a terminal but not >> stdin and stdout. >> The istty check is only true if both stdin and stdout are ttys. > > Then `charset()` in the shared secret would return `null`. Would that

Re: RFR: 8264208: Console charset API [v11]

2021-04-22 Thread Roger Riggs
On Thu, 22 Apr 2021 15:42:02 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 597: >> >>> 595: return null; >>> 596: } >>> 597: }); >> >> Please keep the charset() method and return CHARSET. >> >> I'm looking at a use case

Re: RFR: 8264208: Console charset API [v11]

2021-04-22 Thread Roger Riggs
On Tue, 20 Apr 2021 22:35:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been

Re: RFR: 8264208: Console charset API [v9]

2021-04-16 Thread Roger Riggs
On Thu, 15 Apr 2021 18:29:17 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been

Re: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3]

2021-04-15 Thread Roger Riggs
On Wed, 14 Apr 2021 22:57:55 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > do not call internal method Marked as reviewed

Re: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib

2021-04-14 Thread Roger Riggs
On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. I think is fine to move it first and refactor it separately; that's a bigger job. If its fit for the purpose, the overlap is fine between tools. - PR:

Re: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib

2021-04-14 Thread Roger Riggs
On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. Good idea. Is there a more evocative class name than Proc? It looks similar to jdk.test.lib.process.ProcessTools. Would it fit in the jdk.test.lib.process package? It

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]

2021-04-12 Thread Roger Riggs
On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, >> the details of which can be seen in >> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number >> JNDI methods under

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

2021-04-09 Thread Roger Riggs
On Fri, 9 Apr 2021 15:47:35 GMT, Conor Cleary wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line >> 413: >> >>> 411: return AccessController.doPrivileged( >>> 412: (PrivilegedAction) () -> Long.getLong(propName, >>> defVal).longValue()

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

2021-04-09 Thread Roger Riggs
On Fri, 9 Apr 2021 13:51:30 GMT, Conor Cleary wrote: >> An alternative here would be to use >> sun.security.action.privilegedGetProperty(prop, default). >> The package is already exported from java.base to java.desktop, etc. > > That is a very neat alternative yes. Approaching the problem like

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

2021-04-09 Thread Roger Riggs
On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, > the details of which can be seen in > [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number > JNDI methods under

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

2021-04-09 Thread Roger Riggs
On Fri, 9 Apr 2021 13:30:27 GMT, Alan Bateman wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, >> the details of which can be seen in >> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number >> JNDI methods under

Re: Integrated: 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64

2021-04-02 Thread Roger Riggs
On Fri, 2 Apr 2021 18:04:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on linux-x64 Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3328

Re: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

2021-03-30 Thread Roger Riggs
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining I agree that the public field in WriteAbortedException could be remediated. But it is also mostly harmless.

Integrated: 8263754: HexFormat 'fromHex' methods should be static

2021-03-29 Thread Roger Riggs
On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs wrote: > A number of HexFormat methods converting from strings to numbers do not use > delimiter, prefix, suffix, and uppercase parameters and would be more > convenient if the methods were static. > > These APIs were added

Re: RFR: 8263754: HexFormat 'fromHex' methods should be static [v2]

2021-03-26 Thread Roger Riggs
equence, int, int); >public long fromHexDigitsToLong(java.lang.CharSequence); >public long fromHexDigitsToLong(java.lang.CharSequence, int, int); Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unused HexFormat instanc

Re: RFR: 8263754: HexFormat 'fromHex' methods should be static

2021-03-25 Thread Roger Riggs
On Thu, 25 Mar 2021 21:05:47 GMT, Claes Redestad wrote: >> A number of HexFormat methods converting from strings to numbers do not use >> delimiter, prefix, suffix, and uppercase parameters and would be more >> convenient if the methods were static. >> >> These APIs were added early in JDK

RFR: 8263754: HexFormat 'fromHex' methods should be static

2021-03-25 Thread Roger Riggs
A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static. These APIs were added early in JDK 17 and are being updated before GA. This PR updates existing uses in the

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-17 Thread Roger Riggs
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the > order listed in the JLS; specifically, that isntead of using `final static` > the `static final` should be preferred. > > This fixes the issues in the

Re: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module

2021-03-11 Thread Roger Riggs
On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Please assign a new bug and title to ignore/suppress the warnings. The original issue 8252833 should be left open. Thanks - Changes requested by rriggs

Re: RFR: 8263105: security-libs doclint cleanup [v2]

2021-03-10 Thread Roger Riggs
On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the >> security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running >> tier1/tier2 tests. Minor spot checks on generated

Re: RFR: 8263105: security-libs doclint cleanup [v3]

2021-03-10 Thread Roger Riggs
On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the >> security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running >> tier1/tier2 tests. Minor spot checks on generated

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Roger Riggs
On Mon, 1 Mar 2021 13:23:48 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 232: >> >>> 230: Provider provider = fm.get(name); >>> 231: if (!isSubclass(category, provider)) { >>> 232: throw new

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

2021-02-26 Thread Roger Riggs
On Wed, 25 Nov 2020 16:22:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 106: >> >>> 104: * Map of provider classes. >>> 105: */ >>> 106: private static volatile Map>> RandomGenerator>> factoryMap; >> >> should be

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-02-26 Thread Roger Riggs
On Tue, 23 Feb 2021 16:47:59 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8261160: Add a deserialization JFR event [v5]

2021-02-12 Thread Roger Riggs
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >>

Re: RFR: 8261160: Add a deserialization JFR event [v4]

2021-02-11 Thread Roger Riggs
On Thu, 11 Feb 2021 15:53:06 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >>

Re: RFR: 8261160: Add a deserialization JFR event

2021-02-11 Thread Roger Riggs
On Wed, 10 Feb 2021 20:30:02 GMT, Roger Riggs wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the

Re: RFR: 8261160: Add a deserialization JFR event

2021-02-10 Thread Roger Riggs
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial > filter,

Re: RFR: 8217633: Configurable extensions with system properties

2021-01-22 Thread Roger Riggs
On Fri, 11 Dec 2020 23:20:34 GMT, Xue-Lei Andrew Fan wrote: > The TLS protocols are designed to tolerant unknown TLS extensions. However, > although it is not common, there are a few TLS implementations that cannot > handle unknown extensions properly. As results in unexpected interoperability

Integrated: 8258796: [test] Apply HexFormat to tests for java.security

2021-01-08 Thread Roger Riggs
On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1

Re: RFR: 8258796: [test] Apply HexFormat to tests for java.security [v2]

2021-01-08 Thread Roger Riggs
> Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1 and the test utility > HexPrinter with the ASNFormatter i

Re: RFR: 8258796: [test] Apply HexFormat to tests for java.security

2021-01-08 Thread Roger Riggs
On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1

RFR: 8258796: [test] Apply HexFormat to tests for java.security

2021-01-08 Thread Roger Riggs
Followup to the addition of java.util.HexFormat. Uses of adhoc hexadecimal conversions are replaced with HexFormat. Redundant utility methods are modified or removed. In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. -

Re: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2]

2021-01-04 Thread Roger Riggs
On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one

Integrated: 8252055: Use java.util.HexFormat in java.security

2020-12-18 Thread Roger Riggs
On Thu, 17 Dec 2020 20:45:57 GMT, Roger Riggs wrote: > The java.util.HexFormat methods for formatting and parsing replace a number > of adhoc hex parsing and formatting methods in sun.security implementation > classes. This pull request has now been integrated. Changeset: 68f2ac

Re: RFR: 8252055: Use java.util.HexFormat in java.security [v2]

2020-12-17 Thread Roger Riggs
> The java.util.HexFormat methods for formatting and parsing replace a number > of adhoc hex parsing and formatting methods in sun.security implementation > classes. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Update c

RFR: 8250255: Use java.util.HexFormat in java.security

2020-12-17 Thread Roger Riggs
The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes. - Commit messages: - 8250255: Use java.util.HexFormat in java.security Changes:

RFR: 8251989: Hex formatting and parsing utility

2020-10-02 Thread Roger Riggs
java.util.HexFormat utility: - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase - Static factories and builder methods to create HexFormat copies with modified parameters. - Consistent naming of methods for conversion of byte arrays to

Integrated: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter

2020-09-30 Thread Roger Riggs
On Sun, 20 Sep 2020 13:54:02 GMT, Roger Riggs wrote: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

2020-09-29 Thread Roger Riggs
On Tue, 29 Sep 2020 19:35:42 GMT, Jamil Nimeh wrote: > Regarding the end-of-content identifier, that looks good. Thanks for fixing > the indentation for the right-side ASN.1 > interpretation of the bytes. My only remaining question is whether the > corresponding hex dumps on the left should

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

2020-09-29 Thread Roger Riggs
On Tue, 29 Sep 2020 15:20:13 GMT, Jamil Nimeh wrote: > Also in that last example, it seems to suggest that the second octet string > is nested within the first one since it > sits at a second indent layer. They are both primitives completely covered by > their two byte values so shouldn't they

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5]

2020-09-29 Thread Roger Riggs
30 0d ; SEQUENCE > [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d:03 82 01 ; BIT STR

  1   2   >