On Fri, 28 Jan 2022 00:58:37 GMT, Bernd <d...@openjdk.java.net> wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyright correction
>
> 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.
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66:
>
>> 64: // The configured signature schemes for "signature_algorithms" and
>> 65: // "signature_algorithms_cert" extensions
>> 66: String[] signatureSchemes;
>
> I would keep the typed list (get it from the parameters or system property
> cache).
I see your point. There is a tricky question that it would be nice to return
(SSLParameters.getXXX()) to what it has been set (SSLParameters.setXXX()). If
the typed list get kept, it means that unknown names would filtered out, and
the get method cannot return the property values.
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
