On Fri, 16 Jan 2026 16:24:44 GMT, Alan Bateman <[email protected]> wrote:
> I think it would be useful some static analysis to get a sense for how many > libraries extend BAOS and have their own ensureCapacity method. I ran [this script](https://gist.github.com/gredler/001089395b81bfe72ab3362d6f622096) on my local Gradle JAR cache of ~1.1k JARs, and it found about 50 classes with `ensureCapacity` methods, but none of them extend BAOS (they were mostly collections). So no issues detected using this approach. It would be good if others could check their own Gradle or Maven caches locally. A broader text-based [GitHub search](https://github.com/search?q=%22extends+ByteArrayOutputStream%22+%22private+void+ensureCapacity%28int%22&type=code&p=1) turns up about 30 distinct instances of BAOS subclasses with a conflicting private `ensureCapacity` method. Some of these are copies of `sun.security.ssl.OutputRecord`, which included a private `ensureCapacity` method in earlier versions of the JDK. The ones which stood out to me were: - Apache Dubbo (`org.apache.dubbo.remoting.http12.LimitedByteArrayOutputStream`) - Apache AsterixDB (`org.apache.hyracks.data.std.util.ByteArrayAccessibleOutputStream`) - Apache TsFile (`org.apache.tsfile.utils.PublicBAOS`) - MuleSoft APIKit Rest (`org.mule.module.apikit.validation.body.form.transformation.LimitedByteArrayOutputStream`) - Microsphere (`io.microsphere.io.FastByteArrayOutputStream`) - Subclipse (`org.tigris.subversion.subclipse.core.resources.ResourceStatus.StatusToBytesStream`) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3763739173
