The last changes to StringCoding to support CompactString leads to a regression in term of number of loaded classes which has an impact on the startup of the VM.

Classes loaded by StringCoding in Java 8:
[java.lang.StringCoding]
[java.lang.ThreadLocal$ThreadLocalMap]
[java.lang.ThreadLocal$ThreadLocalMap$Entry]
[java.lang.StringCoding$StringDecoder]
[sun.nio.cs.ArrayDecoder]
[java.nio.charset.CharsetDecoder]
[sun.nio.cs.UTF_8$Decoder]
[java.nio.charset.CodingErrorAction]

Class loaded by StringCoding in java 9:
[java.lang.StringCoding]
[java.lang.ThreadLocal$ThreadLocalMap]
[java.lang.ThreadLocal$ThreadLocalMap$Entry]
[java.nio.charset.StandardCharsets]
[sun.nio.cs.US_ASCII]
[sun.nio.cs.ISO_8859_1]
[sun.nio.cs.UTF_16BE]
[sun.nio.cs.UTF_16LE]
[sun.nio.cs.UTF_16]
[java.lang.StringCoding$StringDecoder]
[java.lang.StringDecoderUTF8]
[sun.nio.cs.ArrayDecoder]
[java.nio.charset.CharsetDecoder]
[sun.nio.cs.UTF_8$Decoder]
[java.nio.charset.CodingErrorAction]
[java.lang.StringCoding$Result]

In Java 9, the number of classes loaded is the double of the number of class loaded by Java 8.

A simple fix is to stop to make a direct reference to java.nio.charset.StandardCharsets because it triggers the loading of all default charsets and to declare the charsets UTF8, ISO_8859_1 and US_ASCII as static final in StringCoding.

A longer fix is to initialize these static fields lazily if the reference to the charset is really needed by the code (note that given that a charset is unique, the lazy loading can be done just by testing is the static field is null or not (without using any locking or volatile).