-
Bug
-
Resolution: Won't Fix
-
P4
-
23
Recent LC_ALL update https://bugs.openjdk.org/browse/JDK-8321373 to use C.UTF-8 if available enhances build determinism due to the variability of just "C" on different machines/OS's. However, C.UTF-8 is not available on all OS's, eg.Centos7.
In comparing jdk-23 builds that default to LC_ALL=C due to lack of C.UTF-8, I have noticed from CDS classlist construction that StandardCharsets$Aliases and $Cache get loaded, ie.if you run a basic java program like HelloClasslist at JVM startup it loads these large tables which is a marginal startup hit which is normally averted for the UTF-8 charsets here: https://github.com/openjdk/jdk/blob/2b4a4b7bd84806f997adc107abbd4351425e8d1d/src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template#L130
To provide better support for all types of build machine that may not have C.UTF-8, should we also support en_US.UTF-8 which is more generally available?
In comparing jdk-23 builds that default to LC_ALL=C due to lack of C.UTF-8, I have noticed from CDS classlist construction that StandardCharsets$Aliases and $Cache get loaded, ie.if you run a basic java program like HelloClasslist at JVM startup it loads these large tables which is a marginal startup hit which is normally averted for the UTF-8 charsets here: https://github.com/openjdk/jdk/blob/2b4a4b7bd84806f997adc107abbd4351425e8d1d/src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template#L130
To provide better support for all types of build machine that may not have C.UTF-8, should we also support en_US.UTF-8 which is more generally available?