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