* John Rose:
In https://bugs.openjdk.java.net/browse/JDK-8161256 I discuss this nascent API under the name "ByteSequence", which is analogous to CharSequence, but doesn't mention the types 'char' or 'String'.
Very interesting. What's the specification for toString() and hashCode()? One problem of retrofitting a custom ByteString into a CharSequence is that CharSequence reuses toString() in a fairly central fashion, and it's hard to reconcile this with byte-based length() and charAt() methods unless ISO-8859-1 encoding is used. If this feature is supposed to land before JEP 218? If not, how does ByteSequence differ from List<byte>?
If the ByteSequence views are value instances, they can be created at a very high rate with little or no GC impact. Generic algorithms would still operate on them
I'm not up-to-date with those upcoming changes. Would the nature as value instances be expressed as part of the ByteSequence interface type?
If the API is properly defined it can be inserted directly into existing types like ByteBuffer. Doing this will probably require us to polish ByteBuffer a little, adding immutability as an option and lifting the 32-bit limits. It should be possible to "freeze" a ByteBuffer or array and use it as a backing store that is reliably immutable, so it can be handed to zero-copy algorithms that work with ByteSequences.
Such freezing is incompatible with mapped byte buffers, right? Even if the implementation prevents changes at the VM/process level, changes on the file system could well become visible. Do you expect to make freezing an optional operation (probably not a good idea), or copy the contents of the mapping to the heap (which is probably not too bad, considering that a shared byte[] could also result in arbitrarily large copies).
Independently, I want to eventually add frozen arrays, including frozen byte[] arrays, to the JVM, but that doesn't cover zero-copy use cases; it has to be an interface like CharSequence.
Well, there is already the VarHandle approach for that. But it's not a particularly rich interface and very far away from strings.
So the option I prefer is not on your list; it would be:
(h) ByteSequence interface with retrofits to ByteBuffer, byte[], etc.
This is more flexible than (f) the concrete ByteString class. I think the ByteString you are thinking of would appear as a non-public class created by a ByteSequence factory, analogous to List::of.
Yes, this seems reasonable. It's a bit of a drawback that the immutable nature of a value cannot be expressed in the type system (so that you have to remember to use ByteSequence::of to get a view to an immutable object), but at least it's consistent with collections.