On Tue, 13 Jan 2026 15:12:23 GMT, Alan Bateman <[email protected]> wrote:
> Is your real concern with buf.length getting close to Integer.MAX_VALUE? No, the main concern is to be able to hook into the standard buffer growth logic. Right now users are given one chance to explicitly request growth to a minimum size (via the constructor), and thereafter can only implicitly do so as part of write operations. > BAOS is more of an implementation class By this do you mean that subclassing BAOS is not encouraged? In my experience this is relatively common, and the class design seems to encourage it (the class is not final, instance variables are protected). > Aside from writeLong, could you list out the methods that you've since in > BAOS subclasses. I'm wondering if BAOS should implement some of the methods > defined by DataOutput to avoid needing to subclass I have seen e.g. `writeInt16` and `writeInt32` methods added, especially when the focus is on writing binary file or wire formats. It's an interesting idea, but I would think that the risk of adding a public `writeLong` method is higher than the risk of adding this protected method. The inclination will then be to add methods for more (all?) primitive types, further increasing the risk. Allowing users to request buffer growth via `ensureCapacity` seems to me both more flexible / general (addressing a broader set of user needs) and less risky. Having said that -- I think the main risk of this change (this was raised by @RogerRiggs in the CSR in JBS) are conflicts with subclasses which already tried to work around this limitation by adding an `ensureCapacity` method, but made that subclass method private or package-private (public or protected would be fine). This risk is non-negligible because `ensureCapacity` is a well-established method name both in `ByteArrayOutputStream` and in other core classes like `ArrayList` and `StringBuilder`. Thus, it is more likely that subclasses will have used this name for this type of functionality (my own `LongStream2` workaround example above would fail to compile). Changing the protected method name (to e.g. `ensureSpace` or `growToAtLeast`) would reduce risk, but would be slightly inconsistent with established nomenclature... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3759722722
