RFR: 8269384: Determine native byte order for StringUTF16 via ByteOrder

[Andrew Dinn]

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

Hi Yi Yang,

This is more complex than it seems. The general policy is not to change boot order if at all possible and for good reason. there are many ways it can cause unexpected consequences.

Regarding this specific case, UnsafeConstants exists in order to allow class Unsafe to define a few final fields derived from runtime environment/hardware parameters provided as final static *primitive* fields of UnsafeConstants. The relevant fields in UnsafeConstants are injected by the JVM after they have been initialized to dummy values by the class's <clinit> method. So, the purpose of the class is simply to pre-cache these runtime/hardware values as Java state, avoiding the need for Unsafe to call out to the JVM using native code. Before UnsafeConstants was defined these constants used to be retrieved using native callouts.

What you are asking for is to make String use the same pre-cache as Unsafe i.e. to expand the set of classes which depend on UnsafeConstants to include String. While that might work as currently defined it is not clear that it will always continue to work in the future. That's because String is a rather special case, much like a primitive class. Instances of String are created to represent literal terms in the language. Note that these String terms are themselves *constants*.

UnsafeConstants is not meant to have any other uses except to cache the runtime-specific/hardware constants used by Unsafe. So, it ought not to depend on other classes. However, it is also important that no other classes depend on it and that includes String. Now imagine someone were to update UnsafeConstants to include an injected String constant -- say, the current setting for LC_LANG, or the processor CPU name or some other legitimate text value derived form the runtime or hardware. Your change would cause a problem because initialization of UnsafeConstants would require String already to be initialized.

Of course, neither of those examples is a likely candidate for inclusion in UnsafeConstants but it is hard to say whether other more realistic cases might arise in future.

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

PR: https://git.openjdk.java.net/jdk/pull/4596