RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]

[Chen Liang]

On Tue, 27 Jun 2023 13:33:09 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:
>> 
>>> 36: 
>>> 37:     @Stable
>>> 38:     public static final short[] DIGITS;
>> 
>> 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.
>
>> 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, it 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243758911