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
|
Java