Please stop incrementing the classfile version number when there are no format changes

Alex Buckley alex.buckley at
Fri Oct 11 21:19:49 UTC 2019

On 10/11/2019 1:25 PM, Remi Forax wrote:
>> However, this is not possible due to a problem with the design of
>> the classfile format: record lengths are not always specifically
>> encoded in the format itself, so when new record types are added to
>> the classfile format, old parsers can't continue to parse the
>> classfile as soon as the first record of an unknown type is
>> encountered. This is an issue with at least one part of the
>> classfile format specification, the constant pool.
> You mention the record, it you change the name of the component of a
> record, you have to update at least the corresponding accessor.

I'm pretty sure that Luke wasn't referring to JEP 359's record types, 
but rather to the general idea that constant pool entries are "records".

Luke's mail boils down to the fact that constant pool entries are fixed 
length but all other ClassFile structures are variable length. (Look at 
the types of the elements of the `ClassFile` structure in JVMS 4.1: 
`cp_info` is fixed length, while `field_info`, `method_info`, and 
`attribute_info` are variable length.)

The reason for the difference is obvious: a constant pool entry defines 
a single value, while the other kinds of structure define a complex 
entity with open-ended amounts of metadata. (Look at Table 4.7-C to see 
which attributes can contribute to defining, say, a field.)

It is true that new kinds of constant pool entry are rare. They are 
introduced only when the JVM gains fundamentally new skills, such as 
`invokedynamic` (motivated c.p. kind 18) and user-defined constants 
loadable via `ldc` (motivated c.p. kind 17). Constant pool entries of 
these kinds signify that "something big" is happening elsewhere in the 
class file, usually in the bytecode stream. Simply ignoring that will 
likely hurt later when (say) a verification tool visits a bytecode it 
doesn't recognize. So, it is very much a-feature-not-a-bug that the 
class file's version dominates the kinds of constant pool entry that are 
legal in the class file.


More information about the jdk-dev mailing list