JDK-8006627 did the JavaLangAccess hack to improve UUID.toString() performance:

    public String toString() {
        char[] chars = new char[36];
        jla.formatUnsignedLong(mostSigBits >> 32, 4, chars, 0, 8);
        chars[8] = '-';
        jla.formatUnsignedLong(mostSigBits >> 16, 4, chars, 9, 4);
        chars[13] = '-';
        jla.formatUnsignedLong(mostSigBits, 4, chars, 14, 4);
        chars[18] = '-';
        jla.formatUnsignedLong(leastSigBits >> 48, 4, chars, 19, 4);
        chars[23] = '-';
        jla.formatUnsignedLong(leastSigBits, 4, chars, 24, 12);
        return jla.newStringUnsafe(chars);
    }

This is a good performance improvement, but it clashes with Compact Strings which now have to re-compress the resulting char[] array into byte[]. And we know that UUID would always produce Latin1 String.

If we follow the same route, and drill more holes in JavaLangAccess to accept Strings with a preset coder, we will also have to take care of the case when Compact Strings are turned off. It might turn beneficial to wait for JDK-8148604 to land, and revert toString() back to plain Java concatenation, letting advanced concat strategies to take care of optimal concat, even in the presence of unsigned long conversions.