JEP draft: Better-defined JVM class file validation
daniel.smith at oracle.com
Fri Jun 4 17:11:11 UTC 2021
> On Jun 4, 2021, at 10:41 AM, Dan Smith <daniel.smith at oracle.com> wrote:
> Posted a new JEP draft, here:
I'll draw your attention to this section, in case it raises any red flags:
Risks and Assumptions
Changing JVM validation behavior is often a risk, because it may cause legacy classfiles to fail with new errors, or, more subtly, new class files with old version numbers to be accepted, but then fail on older JVMs.
In general, the HotSpot changes proposed in this JEP are narrow in scope, often in corner cases that real world code is unlikely to probe. And many of the changes only modify the type of error being thrown or the timing of an error check. That said, the most likely areas of concern are:
• New errors caused by improper appearances of the Module, ModulePackages, ModuleMainClass, and ConstantValue attributes.
• New errors caused by pre-51 class files that declare a useless method with name <clinit> and 1 or more parameters.
• Accepting class files with malformed optional attributes, even though those class files could fail to load on an older JVM.
Besides the risk to JVM users, there is some risk that, by relaxing the constraints on optional attributes, downstream tools will be surprised by unvalidated attribute contents in class files that can be successfully loaded.
These risks need to be balanced against the cost of the extra complexity required to fully specify and maintain longstanding, often ad hoc HotSpot behavior.
More information about the valhalla-spec-observers