On Tue, 27 Jun 2023 14:23:53 GMT, Chen Liang <li...@openjdk.org> wrote:
>>> 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?
>>
>> I really wish we have frozen arrays, which are safely sharable like records.
>> The closest we have right now is a final array with `@Stable`, which
>> indicates array elements are lazy (any non-default value read can be treated
>> as a constant by JIT); since this array is explicitly `@Stable final`, we
>> can share it within the JDK like any other immutable objects.
>
> On second thought, we should be able to create a getter like
>
> @ForceInline
> static short hex256(int byteValue) {
> return HEX256[byteValue];
> }
>
> and switch usages to that getter instead. This is a better approach than
> cloning the array and makes the array safe from modification by modules that
> get jdk.internal.util exports.
> Sadly, jdk.internal.util is exported to other modules so it does need to be
> looked at from an integrity perspective.
This is indeed a problem to consider.
Maybe we can move this array back into `HexDigits`. Then we create a new
package `jdk.internal.digits` and move `Digits`, `DecimalDigits`, `HexDigits`,
`OctalDigits` all into it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243854585
