Re: RFR: 8358319: Pem.decode should cache the Pattern

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev wrote: > SonarCloud complains we are using the String.replaceAll() method that creates > Pattern internally every time. This looks a minor inefficiency in preview > feature, but we can fix it from the day 1. Also fixed the variable name style >

Re: RFR: 8358171: Additional code coverage for PEM API

On Mon, 2 Jun 2025 12:14:13 GMT, Fernando Guallini wrote: > The tests included in this PR add code coverage mainly to the following > classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, > EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are > includ

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v3]

On Mon, 2 Jun 2025 19:50:10 GMT, Volkan Yazici wrote: >> Passes the `Charset` read from the `stdin.encoding` system property while >> creating `InputStreamReader` or `Scanner` instances for `System.in`. >> >> `stdin.encoding` is a recently added property for Java 25 in >> [JDK-8350703](https:/

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v3]

On Mon, 2 Jun 2025 19:27:14 GMT, Chris Plummer wrote: >> Volkan Yazici has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Clean-up `MultiBreakpointsTarg` > > test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141: > >> 139: Thread con

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v3]

> Passes the `Charset` read from the `stdin.encoding` system property while > creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in > [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it > throug

Re: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v3]

On Fri, 30 May 2025 14:43:32 GMT, Sean Coffey wrote: >> Removal of the `+thread` and `+timestamp` options that were used to control >> the logging behavior of output from the `java.security.debug` system >> property. >> >> >> To enhance the security debug logs, the thread and timestamp data s

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v2]

On Mon, 2 Jun 2025 19:27:08 GMT, Volkan Yazici wrote: >> Passes the `Charset` read from the `stdin.encoding` system property while >> creating `InputStreamReader` or `Scanner` instances for `System.in`. >> >> `stdin.encoding` is a recently added property for Java 25 in >> [JDK-8350703](https:/

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v2]

On Fri, 30 May 2025 14:23:24 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Provide fallback for `stdin.encoding` >> - Revert changes to `Application` and `JavaChild` >> >>There stdin

Re: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] [v2]

> Passes the `Charset` read from the `stdin.encoding` system property while > creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in > [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it > throug

Re: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev wrote: > Found by static analysis, see more details in the bug. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_security` Tests pass - PR Comment: https://git.openjdk.org/jdk/pull/25581#issuecomment-2931860336

Re: RFR: 8358319: Pem.decode should cache the Pattern

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev wrote: > SonarCloud complains we are using the String.replaceAll() method that creates > Pattern internally every time. This looks a minor inefficiency in preview > feature, but we can fix it from the day 1. Also fixed the variable name style >

Re: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev wrote: > Found by static analysis, see more details in the bug. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_security` Thanks! I'll integrate once my day starts tomorrow. - PR Comment: https://git.openjdk.or

Re: RFR: 8358319: Pem.decode should cache the Pattern

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev wrote: > SonarCloud complains we are using the String.replaceAll() method that creates > Pattern internally every time. This looks a minor inefficiency in preview > feature, but we can fix it from the day 1. Also fixed the variable name style >

Re: RFR: 8358159: Empty mode/padding in cipher transformations

On Fri, 30 May 2025 12:40:51 GMT, Sean Mullan wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing do

Re: RFR: 8358319: Pem.decode should cache the Pattern

On Mon, 2 Jun 2025 16:53:54 GMT, Anthony Scarpino wrote: > looks good Thanks! A bit blurry on review rules in this area: do you want me to wait for someone else to review? More tests to run? - PR Comment: https://git.openjdk.org/jdk/pull/25583#issuecomment-2931591245

Re: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev wrote: > Found by static analysis, see more details in the bug. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_security` I'm. sure this is fine, but let me run the regression tests before integration - PR Comm

Re: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev wrote: > Found by static analysis, see more details in the bug. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `jdk_security` looks good - Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk

Re: Quantum Resistant hybrid key exchange

Hi Azeem, For TLS, we are currently working on an implementation of "Hybrid Key Exchange for TLS 1.3" [1]. We also expect to implement one or more of the hybrid mechanisms that are being specified [2]. Expect to see a JEP with more details on this effort in the near future. As for other hybr

RFR: 8358171: Additional code coverage for PEM API

The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property

RFR: 8358319: Pem.decode should cache the Pattern

SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern. Additional testing: - [x] Linux x86_

Re: RFR: 8358159: Empty mode/padding in cipher transformations

On Fri, 30 May 2025 12:40:51 GMT, Sean Mullan wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing do

RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

Found by static analysis, see more details in the bug. Additional testing: - [x] Linux x86_64 server fastdebug, `jdk_security` - Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25581/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25581&range=00 Issue: