There is one form of array builder already in the JDK - Stream.builder(). This doesn't cover off all of the use-cases, but covers some of them (notably not the byte array case).
-Johannes On Fri, Apr 11, 2025 at 11:47 AM Archie Cobbs <archie.co...@gmail.com> wrote: > To try to loop back on my original point... > > The "underlying problem" that I think should be addressed by some new > internal class (or suite of classes) is the "array builder" problem. This > is where you're doing "append, append, append, ..., use read-only > thereafter". > > Currently people use ArrayList for that, or for primitive arrays, homebrew > it with System.arraycopy() - or maybe I'm missing something like this that > already exists? > > I would like to see JDK standard "array builders" for primitive types and > reference types that use fixed sized (power-of-two) segments internally. > These can be internal classes for now. > > Then the faster ByteArrayOutputStream becomes just a wrapper around > "ByteArrayBuilder" or whatever we call it. > > This is all just my opinion, I'm curious if others perceive the same gap > that I do? > > -Archie > > > On Fri, Apr 11, 2025 at 10:15 AM Archie Cobbs <archie.co...@gmail.com> > wrote: > >> On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John <jeng...@amazon.com> >> wrote: >> >>> It seems like a good general-purpose list but I wouldn’t recommend it as >>> a direct replacement for either ArrayList or LinkedList; in the former case >>> the risk is slower random accesses, and in the latter the risk is to head >>> modifications. >>> >> >> Interesting results. However I don't think comparing this to both >> ArrayList and LinkedList is really fair. Developers choose an >> implementation based on how they know they are going to use it: If they are >> just adding stuff, they choose ArrayList. If they know they need to >> insert/remove in the middle, they choose LinkedList. If they need to >> add/remove from both ends, they choose ArrayDeque. Etc. >> >> So the optimal design changes depending on which "flavor" of list usage >> the developer is implying when they choose some implementation class. >> >> E.g., if you wanted to target the "ArrayList flavor', then you'd use >> fixed size, power-of-two segments. Then get() remains constant time, and >> insert and remove remain as painfully slow as ever, but the common "list >> builder" usage pattern of "append, append, append, ..., use read-only >> thereafter" gets a lot faster. >> >> OTOH variable-sized chunks makes lots of sense for the "LinkedList" >> flavor. In fact you could have a LinkedList<T> that just uses an >> ArrayList<ArrayDeque<T>> internally :) >> >> -Archie >> >> -- >> Archie L. Cobbs >> > > > -- > Archie L. Cobbs >
