Please stop incrementing the classfile version number when there are no format changes (original) (raw)
Alex Buckley alex.buckley at oracle.com
Fri Oct 11 23:40:14 UTC 2019
- Previous message: Please stop incrementing the classfile version number when there are no format changes
- Next message: Please stop incrementing the classfile version number when there are no format changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 10/11/2019 4:12 PM, Maurizio Cimadamore wrote:
what exactly does it mean to pass a class that contains newly condy-compiled lambdas on a tool that doesn't understand them? Let's say the tool in question is a code coverage tool, or some static checker of sort; would it be really considered an acceptable to have this tool skip over most of the lambda expressions in the user code? I mean, yes, the tool would run w/o crashing, but that's pretty much all you can say about it. > In other words, yes, classfile N+1 might be a superset of classfile N, but as the features in N+1 are used pervasively in N+1 classfiles, there's not much that N-compatible tools might realistically do with N+1 classfiles. Of course there will be cases where you might have more luck, but in the general case I don't see this flying.
Exactly, this is what I meant by:
"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."
Here's another example of the class file version REALLY MATTERING. Thanks to Java 8's introduction of default methods in the Java language, something that was absurd in a 51.0 class file -- a method of an interface being non-ACC_ABSTRACT -- suddenly became legal in 52.0!
"Methods of interfaces may have any of the flags in Table 4.6-A set except ACC_PROTECTED, ACC_FINAL, ACC_SYNCHRONIZED, and ACC_NATIVE (JLS ยง9.4). In a class file whose version number is less than 52.0, each method of an interface must have its ACC_PUBLIC and ACC_ABSTRACT flags set; in a class file whose version number is 52.0 or above, each method of an interface must have exactly one of its ACC_PUBLIC and ACC_PRIVATE flags set."
(https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6-200-A.3)
Alex
- Previous message: Please stop incrementing the classfile version number when there are no format changes
- Next message: Please stop incrementing the classfile version number when there are no format changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]