Maintenance Notice

The bugs.java.com site will be undergoing maintenance on 15th Dec 2017 21:00 PST to 16th Dec 2017 1:00 AM PST.
JDK-6324107 : ClassFormatError should be thrown for <clinit> without a code attribute in an interface
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-14
  • Updated: 2017-05-16
  • Resolved: 2006-01-31
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6
6 b70Fixed
Description
Sun's JDK raises VerifyError when an interface contains <clinit> without a code attribute.

JVMS, 2nd Edition, Chapter 4.6 Methods states:
    ...
    Class and interface initialization methods (3.9) are called implicitly by
    the Java virtual machine; the value of their access_flags item is ignored
    except for the settings of the ACC_STRICT flag.
    ...

Thus, ClassFormatError should be thrown in such case, because:
  - the value of ACC_ABSTRACT is among the ignored flag (as others but except ACC_STRICT)
  - ACC_ABSTRACT cannot be used to suggest that VM should not check for a Code attribute
  - the unstated implicit assumption is that if <clinit> exists, it must have a Code Attribute
  - the check for the existence of a Code Attribute should result to ClassFormatError,
    not a VerifyError.

It is fine for other methods that ACC_ABSTRACT implies no code attribute,
but <clinit> is specifically excepted by the above paragraph.

Note that Sun's JDK raises VerifyError in such cases at least since JDK 1.2. 

Please see comments for 6300312 for more details.

Comments
EVALUATION class file parser should check for this
2006-01-10