On Tue, 6 Feb 2024 13:52:09 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JDK
> Avoid expensive `Class.forName` call when constructing Providers such as
> `SecureRandom` which take constructor parameters. This can easily be cached
> in EngineDescription (this cache already existed before, it was removed in
> [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as un
On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JDK
On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JDK
On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JDK
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
> Avoid expensive `Class.forName` call when constructing Providers such as
> `SecureRandom` which take constructor parameters. This can easily be cached
> in EngineDescription (this cache already existed before, it was removed in
> [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as un
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 31 Jan 2024 17:23:42 GMT, Weijun Wang wrote:
> How about just using class literals? There is no need to call
> `Class.forName`, at least not now since they are all inside `java.base`.
Thanks :). That seems sensible if writing from scratch, but that part I'm just
reviving from [JDK-8280
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie wrote:
>> Avoid expensive `Class.forName` call when constructing Providers such as
>> `SecureRandom` which take constructor parameters. This can easily be cached
>> in EngineDescription (this cache already existed before, it was removed in
>> [JD
On Wed, 24 Jan 2024 20:09:12 GMT, Roger Riggs wrote:
>> I don't disagree in principle but it was like this before the revert, and is
>> still like this in 17.
>
> Is volatile really needed? And there is some performance penalty and in
> practice the value will be the same even if recomputed.
S
On Wed, 24 Jan 2024 17:57:38 GMT, Oli Gillespie wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1560:
>>
>>> 1558: final boolean supportsParameter;
>>> 1559: final String constructorParameterClassName;
>>> 1560: private volatile Class constructorPar
On Wed, 24 Jan 2024 17:57:46 GMT, Oli Gillespie wrote:
> Aside: The classes saved here are limited to the 31 explicitly added in
> Provider.. I'm not sure if that helps limit the leak potential
> significantly?
True. Might not even be an issue in practice.
I think the argument for keeping the
> Avoid expensive `Class.forName` call when constructing Providers such as
> `SecureRandom` which take constructor parameters. This can easily be cached
> in EngineDescription (this cache already existed before, it was removed in
> [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as un
On Wed, 24 Jan 2024 17:45:06 GMT, Aleksey Shipilev wrote:
>> Oli Gillespie has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Rename newSecureRandom -> create
>> - Add copyright header to new file
>
> src/java.base/share/classes/java/sec
On Wed, 24 Jan 2024 15:25:28 GMT, Oli Gillespie wrote:
> Avoid expensive `Class.forName` call when constructing Providers such as
> `SecureRandom` which take constructor parameters. This can easily be cached
> in EngineDescription (this cache already existed before, it was removed in
> [JDK-82
20 matches
Mail list logo
