RFR: 8367585: Move Utf8Entry length validation earlier

[Adam Sotona]

On Mon, 15 Sep 2025 05:43:43 GMT, Chen Liang <liach at openjdk.org> 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'm not a fan of this kind of early validation. 
Signature, ClassSignature, and MethodSignature do not seem to have specified length limits and so we have nothing to refer to.
Pulling the physical storage limit tests up to the chain into the symbols seems to me obsolete.
There are several related issues:
- The checks become very complex for the weak advantage of failing just a bit earlier in the process.
- The explanation to users is very complicated and requires to explain relations between multiple specifications.
- The direction where it goes is dangerous. What if we start to check every single String argument across the whole Class-File API for its potential of overflow somewhere down the chain?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27281#issuecomment-3355443898