Bytecode regression caused by JDK-8148854

[Andrew Hughes]

On 16:57 Wed 07 Oct     , Alvarez, David wrote:
> 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

I'm tending towards this mostly being an issue with Groovy creating bad
class files. It sounds like it still does and they already fail with
OpenJDK 11.

However, I see that this is an 8u281 backport for Oracle, but, for some
reason, it was approved earlier for OpenJDK 8, in 8u272. I thus think
there's a case for rolling it back in 8u272 *only*, so the change at
least appears in both JDKs at the same time.

Thoughts?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222