On Tue, 14 Apr 2026 00:35:28 GMT, Xueming Shen <[email protected]> wrote:
> Separately, did you consider keeping ZipCoder abstract and providing two > concrete implementations, one for UTF-8 and one for arbitrary charsets? I’m > not suggesting that would necessarily be better, but I was curious whether > that alternative was explored and whether it would preserve the same > performance benefits while reading a bit more naturally. Thanks, I think I like this idea. Neither the current or suggested hierarchy feel 100% right to me. They both seem to fail the "is a" test. A CharsetZipCoder "is not" a UTF8 ZipCoder and a UTF8ZipCoder "is not" a CharsetZipCoder (it does not have / use the Charset). So extracting the contract into an abstract base class with two concrete sibling implementations seems like a cleaner design. We loose the benefit of loading a single class in the common case, but that's a minor win. I'll run some benchmarks to assess the performance impacts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30640#issuecomment-4242988974
