Re: RFR: 8315974: Make fields final in 'com.sun.crypto.provider' package [v3]

2023-10-18 Thread Andrey Turbanov
On Wed, 18 Oct 2023 06:28:01 GMT, Andrey Turbanov wrote: >> A few classes in `com.sun.crypto.provider` package have non-final fields >> which could easily be marked `final`. > > Andrey Turbanov has updated the pull request with a new target base due to a > merge or a rebase. The pull request no

Re: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v8]

2023-10-18 Thread Tobias Hartmann
On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using >> AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:Use

Integrated: 8315974: Make fields final in 'com.sun.crypto.provider' package

2023-10-18 Thread Andrey Turbanov
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote: > A few classes in `com.sun.crypto.provider` package have non-final fields > which could easily be marked `final`. This pull request has now been integrated. Changeset: 4e77b3c3 Author:Andrey Turbanov URL: https://git.openjdk

Re: [External] : Re: PEM KeyStore Implementation

2023-10-18 Thread Karl Scheibelhofer
Hi Sean, Yes, I can help with this new PEM API. Let me know, when there is something to review. Best regards, Karl On Tue, Oct 17, 2023, 19:12 Sean Mullan wrote: > Hi Karl, > > I discussed your proposal with some other colleagues. > > We generally feel a PEM KeyStore would be a useful addit

Re: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions [v8]

2023-10-18 Thread Sandhya Viswanathan
On Wed, 11 Oct 2023 22:05:08 GMT, Smita Kamath wrote: >> Hi All, >> I would like to submit AES-GCM optimization for x86_64 architectures using >> AVX2 instructions. This optimization interleaves AES and GHASH operations. >> >> Below are the performance numbers on my desktop system with -XX:Use

Re: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5]

2023-10-18 Thread Roger Riggs
On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to >> use try...catch to handle CharacterCodingException and throw >> IllegalArgumentException instead of CharacterCodingException to make the >> calling code cleane

Re: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5]

2023-10-18 Thread Alan Bateman
On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs wrote: > The new usages that are driving this change would be better served by a > method dedicated to creating latin1 strings from a caller provided byte > array. The JavaLangAccess shared secret interface is already overused, but it > is cleaner,

Re: RFR: 8316964: Security tools should not call System.exit [v3]

2023-10-18 Thread Valerie Peng
On Mon, 16 Oct 2023 14:37:03 GMT, Weijun Wang wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line >> 155: >> >>> 153: private static void exit(int exitCode) { >>> 154: throw new ExitException(exitCode); >>> 155: } >> >> I don't see much benefit o

Re: RFR: 8316964: Security tools should not call System.exit [v5]

2023-10-18 Thread Andrey Turbanov
On Mon, 16 Oct 2023 16:23:13 GMT, Weijun Wang wrote: >> Remove most `System.exit()` calls in various security tools and only leave >> one in the `main` method. This paves the way to convert them to JSR 199 >> tools. >> >> Note: before this change, the behavior of a successful `main()` method

Re: RFR: 8316964: Security tools should not call System.exit [v3]

2023-10-18 Thread Valerie Peng
On Mon, 16 Oct 2023 14:32:33 GMT, Weijun Wang wrote: >> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java >> line 82: >> >>> 80: } >>> 81: >>> 82: private static class ExitException extends RuntimeException { >> >> If we want to use ExitException as int

Re: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5]

2023-10-18 Thread Roger Riggs
On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman wrote: > We have to be very careful with proposals like this as it means code outside > of java.lang having access to the underlying bytes. I think other > alternatives needs to be explored to avoid this and related concerns. Yes, adding another m

Re: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5]

2023-10-18 Thread Glavo
On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to >> use try...catch to handle CharacterCodingException and throw >> IllegalArgumentException instead of CharacterCodingException to make the >> calling code cleane

Re: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v7]

2023-10-18 Thread Glavo
> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, > creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, > `newStringLat

Re: RFR: 8318096: Add getParams method in PublicKey and PrivateKey [v2]

2023-10-18 Thread Weijun Wang
On Wed, 18 Oct 2023 04:44:07 GMT, David M. Lloyd wrote: > Would `getParameterSpec` be a better/more descriptive name, given that the > thing it returns is an `AlgorithmParameterSpec`? > > (Disclosure: Our security library (WildFly Elytron) has a `getParameterSpec` > on every one of its key imp

Re: RFR: 8318096: Add getParams method in PublicKey and PrivateKey [v2]

2023-10-18 Thread David M . Lloyd
On Wed, 18 Oct 2023 18:23:31 GMT, Weijun Wang wrote: > > Would `getParameterSpec` be a better/more descriptive name, given that the > > thing it returns is an `AlgorithmParameterSpec`? > > > > > > (Disclosure: Our security library (WildFly Elytron) has a > > `getParameterSpec` on every one o