On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <[email protected]> wrote:
> John Rose suggests in > https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that > ClassFile API should validate Utf8Entry length eagerly upon construction. > Currently we validate upon writing to bytes, which avoids validation > overhead. However, given that most class file utf8 data are shorter than 1/3 > of the max length, which is always an encodable length, the performance > impact should be low. > > Preventing the creation of unrepresentable UTF8 entries can prevent passing > such invalid instances around, making such problems easier to debug than a > failure at building. > > Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of > the regularly run transformation benchmarks seems neutral, less than 5% > perturbations. > > I will update docs to reflect this change, given how widespread this is > across JDK - it seems the only exempt classes are Signature, ClassSignature, > and MethodSignature. I think you misunderstood this patch. All classfile API strings eventually go to the constant pool except ones going into the signatures. So the CP size check are absent on signature model's strings and nominal descriptor strings. What I did was I noted these strings are edge cases that we intentionally don't length check (we really can't). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3355959636
