The store for byte strings

[Florian Weimer]

* 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.