JDK-8028553 : The JVM should not throw VerifyError when 'overriding' a static final method in a superclass.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-18
  • Updated: 2014-07-29
  • Resolved: 2014-01-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20Fixed 9 b03Fixed
Related Reports
Relates :  
JDK-8028549 - Ensure consistent treatment of private/static methods during verification
Description
Text from Alex:

HotSpot gives a VerifyError when overriding a static final method in a superclass, but JLS7 13.4.17 implies it should be legal to present the following classes to the JVM: (assume the same package)

class Sup { static final void m() }
class Sub extends Sup { void m() }

As Sup#m is a static method, it logically cannot be overridden. (The fact that it's final and thus "must not be overridden" is short-circuited.) Sub is therefore doing nothing wrong, and no VerifyError is due. (One can argue that this class hierarchy is a long way from legal in the Java language, and deserves a VerifyError, but it is wholly consistent for the verifier to think about final method overriding solely in terms of _instance_ methods in both superclass and subclass.)
Comments
This bug is a result of the JVM Spec changes detailed in JDK-8028549: Separately, if it is discovered that a (non-private, non-static) method overrides a final method, then the final method is really only overridden if it's non-static and non-private. If the final method is static or private, then it's not really overridden; per JLS7 13.4.17, it should be binary compatible to add 'final' to a static method. In fact, the 'final' modifier is an aberration; a static or private method cannot logically be overridden so the presence of 'final' is irrelevant. In Prolog terms: ... Finally, the "success" and "recursive" cases are similar to JLS7: finalMethodNotOverridden(Method, Superclass, SuperMethodList) :- methodName(Method, Name), methodDescriptor(Method, Descriptor), member(method(_, Name, Descriptor), SuperMethodList), isNotFinal(Method, Superclass), isNotStatic(Method, Superclass), // NEW; we covered non-final static methods above isNotPrivate(Method, Superclass). // NEW; we covered non-final private methods above
23-01-2014
JDK-8028549 contains the JVM Specification changes for this bug.
21-01-2014