On Sat, 29 Jan 2022 05:31:08 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:
>>
>>> 761:
>>> 762: String[] tempSchemes = signatureSchemes.clone();
>>> 763: for (String scheme : tempSchemes) {
>>
>> In addition to this loop we could also parse/decompose the strings. This
>> would do the work only once (if the parameter is reused)
>
> If we want to reuse the result, we may have to cache something. It is not
> good to me. The parsing of the signature scheme names actually depends on
> the provider. So at this point, in the Java SE API specification, it is not
> easy to know how to parse the strings to me.
Yes you are right, it would require a setter where the provider can register
the resolved array into the parameter instance (if we need to support multiple
providers). But it would be a good optimization assuming clients keep the
parameters around in a frequent Connection scenario.
>> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:
>>
>>> 260: } // otherwise, use the default values
>>> 261:
>>> 262: String[] ss = params.getSignatureSchemes();
>>
>> If we don’t use the cloning getter here (and use the pre-parsed list) it
>> would be more efficient.
>
> Yes. Array copy is a concern of mine, too. Hopefully, the frozen array
> feature could help address the array copy issues in the future.
Hmm.. I guess the different packages make it really hard to have an internal
optimized getter. What about a single concatenated string, it would be
immutable „sig1,sig2“..
>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:
>>
>>> 437: (config.signatureSchemes == null ||
>>> 438: config.signatureSchemes.length == 0 ||
>>> 439: Arrays.asList(config.signatureSchemes)
>>
>> Is that a allocation per handshake*availablesize?
>
> Yes, it does. Do you like to use a for-loop, without new object allocation?
Yes, static helper
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
