RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
Daniel Fuchs
dfuchs at openjdk.org
Tue Jun 27 14:06:16 UTC 2023
On Tue, 27 Jun 2023 13:38:11 GMT, Chen Liang <liach at openjdk.org> wrote:
>>> It's a bit smelly to have a public static field of type array. Static analysers are likely to flag this. It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.
>>
>> I don't think this is a problem. If users can access JDK internal packages, they can do many things. For example, through `JavaLangAccess::getEnumConstantsShared`, an array shared within JDK can be obtained.
>>
>> Now that we trust the permission control of JPMS, such a requirement seems somewhat rigid.
>
> This array takes some time to prepare. We don't want each class to copy a large array when we can just prepare it once and use it everywhere within the JDK implementation. This array is, under no circumstances, leaked to users so it's safe.
What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243804755
More information about the core-libs-dev
mailing list