JDK-4768967 : spurious InnerClass attribute entry
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2002-10-25
  • Updated: 2003-08-01
  • Resolved: 2003-08-01
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.
Other
5.0 tigerFixed
Related Reports
Relates :  
JDK-4749904 - Class.getDeclaringClass() throws unexpected exception
Relates :  
JDK-4909550 - 1.5 beta-b15 java compiler throws NPE
Description
In 1.4.2 build B03, the class file

	java/awt/LightweightDispatcher.class

from rt.jar is missing an inner class attribute for

	sun/awt/dnd/SunDropTargetContextPeer$EventDispatcher

###@###.### 2002-10-28

On second thought, the problem is that there was an EXTRA one in B02.
There is no reason for this InnerClasses attribute entry.

###@###.### 2002-10-28
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b14
14-06-2004
PUBLIC COMMENTS ...
10-06-2004
EVALUATION Investigating. I suspect pack/unpack might be the culprit. ###@###.### 2002-10-25 Yes, it is. The class file in the intermediate builds has the appropriate inner class attributes, while the one in the promoted build does not. The only difference, as far as I know, is that the promoted build has had the class files run through pack/unpack. ###@###.### 2002-10-25 The missing class is not used in the classfile except by the InnerClasses attribute itself. Such classes are not required to be included. The spec. for InnerClasses (last time I checked) requires only enclosing classes of the current class, child classes of the current class, and classes actually used in the constant pool. The class being complained about above is in none of these categories. Its absence from the constant pool is not missed by any bytecode or attribute, and is therefore harmless. In this case, the name of the dropped class appears only in method signatures. It was the javac compiler's arbitrary action to include an InnerClasses record for this class. If for some reason this record is actually necessary, the spec for the InnerClasses attribute must be updated, so that tools like the packer can follow it. In the absence of such an updated spec., tools must be left free to perform such harmless transformations on class files. ###@###.### 2002-10-28 From JVMS 4.7.5: If the constant pool of a class or interface refers to any class or interface that is not a member of a package, its ClassFilestructure must have exactly one InnerClassesattribute in its attributestable. The reference in this case appears in the signature of a method. Perhaps we need a spec clarification? ###@###.### 2002-10-28 Gilad agrees with you, that javac should not have generated this entry in the first place. Although the quoted passage mandates an InnerClasses attribute, it does not mandate its contents. The description of its contents later in that section makes it clar that it is needed only when a CONSTANT_Class_info entry in the pool references an inner class. That is not the case here, so pack/unpack is not incorrect to remove that entry. I am recategorizing this as a javac bug, as javac should be modified to not generate the spurious InnerClasses attribute table entry in the first place. ###@###.### 2002-10-28
28-10-2002