JDK-8352891 Performance improvements to ByteArrayOutputStream

Engebretson, John jengebr at amazon.com
Mon Apr 14 12:59:04 UTC 2025


I thought about this over the weekend, and I think the byte[] variant and the Object[] variant target separate problems: byte[] targets I/O patterns and Object[]
targets Collections.

So my current mental model is:

public class java.io.VariableLengthByteArray {
  // whatever views we want to support
  public ByteArrayOutputStream asOutputStream();
  public InputStream asInputStream();
  public SeekableByteChannel asByteChannel;

  // provides long-indexed methods
  public byte get(long index);
  public long get(long index, byte[] buf);
  public byte set(long index, byte b); // return old value
  public long size(); // note the long

  // optional: inserts/removes by long index

  // add to tail
  public void add(byte b);
  public void add(byte[] b, int off, int len);
  public void add(VariableLengthByteArray other);
  public void add(ByteBuffer buf);

  // size-limited methods
  public int sizeAsInt(); // requires int range
  public byte[] toArray(); // requires int range
  public String toString(); // requires int range

  // miscellaneous
  public void clear();
}

public class java.util.HugeCollections {
  // views are capable and efficient with size > Integer.MAX_VALUE
  public static <T> List<T> getList(); // this structure
  public static <T> Set<T> getSet(); // segmented hash table
  public static <T> Map<T> getMap(); // segmented hash table

  // how do we retrieve the long size?
}

Unfortunately, I don't see a way to avoid two public types while retaining the capabilities.
Archie, thank you for all of the questions/suggestions last week, they really sparked some ideas.
  John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250414/40dec65f/attachment.htm>


More information about the core-libs-dev mailing list