Oracle’s latest release of Java, 8 update 11 (and 7 update 65), has caused problems for some third-party tools. One of the affected tools is ZeroTurnaround’s JRebel, with the Groovy programming language also reporting incompatibilities. Other affected tools include Javassist, a Java bytecode manipulation library, with some users also reporting problems with tools such as Google’s Guice (in some circumstances – notably those using AOP) and the Jacoco code coverage tool. Oracle confirmed the bug via a test case from Jochen Theodorou, from the Groovy project team.
The problems seem to stem from a change in the JVM’s bytecode verification subsystem in 8u11. The Java language requires any call to a superclass constructor to be the first action undertaken by a constructor, but it seems that this was not enforced by the bytecode verifier in earlier versions of the platform. Oracle’s decision to begin firmer enforcement of this language feature may be closing a language specification bug, but it seems to have impacted a number of tools within the ecosystem.
So far there is no indication that any Java code that doesn’t use bytecode reweaving or AOP techniques is affected by this bug. Release 8u11 is understood to be fully compatible with all bytecode created directly by javac that is not subject to reweaving techniques, although the widespread nature of these techniques in modern frameworks may make this of limited comfort to developers.
Oracle have yet to announce a release date for a fix and so far the only comprehensive workarounds are to use the -noverify switch or to refrain from upgrading until a fix can be released. However, individual tools are coming up with workarounds on their own, for example Anton Arhipov (Zero Turnaround) confirms that the latest release of JRebel (5.6.1) includes a workaround for this issue.