Bytecode regression caused by JDK-8148854
Alvarez, David
alvdavi at amazon.com
Wed Oct 7 16:57:16 UTC 2020
Hi,
During our testing of 8u272 we have detected a regression caused by
JDK-8148854 [1]. This backport has changed how the Bytecode verifier
works when loading a class. After this backport is applied, a class
containing a method with '<' or '>' on its name will fail to load with
a ClassFormatError. This is correct according to the JVM spec for
JavaSE 8, section 4.2.2 [2].
What we have found out is that classfiles with older major versions (on
our test 49) will be subjected to the same requirements. I haven't find
a reference in the JVM spec for JavaSE6 [3] that contains the same
constrains as section 4.2.2 has for 8 regarding method names and the
usage of < and >.
We found this issue with groovy code. Old versions of groovy generate
classfiles with major versions 49 when compiled with groovyc. For this
scenario, we can use a groovy class like:
public class Repro {
def "bad<_>method"() {
}
void test() {
println "Passed"
}
public static void main(String[] args) {
Repro r = new Repro()
r.test()
}
}
This class can be compiled with groovyc 1.8.9. The resulting .class
file can be executed with 8u265, but fails with 8u272. We found this
failure when trying to run some Spock Framework [4] based tests written
in groovy. Newer versions of groovy will still generate the .class
file, however, the major version would be 52 (tested with groovy
3.0.6). In that instance, groovyc would be the one to blame. Attempting
to run the .groovy file directly did not work in any scenario.
Finally, jdk11 will also throw the ClassFormatError
David
---
[1] https://bugs.openjdk.java.net/browse/JDK-8148854
[2]
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.2.2
[3]
https://docs.oracle.com/javase/specs/jvms/se6/html/VMSpecTOC.doc.html
[4] http://spockframework.org/spock/docs/1.3/index.html
More information about the jdk8u-dev
mailing list