[Netty 5] Is AsciiString still useful ?

JDK 9+ includes JEP 254 Compact String which can use a byte[] instead of a char[] as the backing storage for String in some situations. The primary reason for introducing AsciiString was to reduce memory for storage of headers. We should investigate if String can now be used instead. We would likely have to wrap String to be able to override the hashCode algorithm to be case insensitive. If we do decide to keep AsciiString the constant memory overhead for smaller string is quite high because we maintain array/offset to avoid copying in some situations. We should investigate if this is beneficial/necessary as it can also lead to longer retention of larger byte[] objects.

[Bennett-Lynch]

As part of this, can we also re-evaluate API’s that return a CharSequence rather than a String?

I think CharSequence should be the preferred input type, but String should be the only return type.

String is the de facto string representation used throughout most of Java, and I sometimes have to write cumbersome logic like this:

CharSequence cs = NettyUtilMethod.get();
return (cs == null) ? null : cs.toString();

[idelpivnitskiy]

@normanmaurer In ServiceTalk, we have a similar class AsciiBuffer, that implements CharSequence interface. But in ServiceTalk motivation is different: we do that to avoid copying of the header names and values (we can do that because we do not use pooled memory) and to optimize the writes (avoid serialization of String) side. According to our benchmarks it gives advantages on JDK11. So, “reduce memory for storage of headers” is not the primary motivation in our use-case.