Bug ID: JDK-5002251 potential bug with annotations and class file evolution

Versions (Unresolved/Resolved/Fixed)

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	JDK 6
5.0u8Fixed	6 b81Fixed

currently any annotations for a method defined in a class are stored in the array that hangs off the instanceKlass.  This works fine normally since these parallel arrays are one to one.  However if class evolution allows the replacement of a methodOop then we have to handle this correctly.  There can only be one annotation but there are potentially 2 methodOops live.  I suspect this isn't that likely to show up in practice but I think someone who understands the interaction of this needs to think about what needs to be done.  It may be suffient to simply update the annotation when you update the method table.  I talked somewhat with Ken about this and promised to file a bug.

WORK AROUND See attached 5002251-webrev-cr0 for the proposed fix.
04-04-2006
EVALUATION Currently there is code in the RedefineClasses() implementation to copy annotations from the scratch class to the_class. This is all well and good except that it doesn't interact properly with constant pool merging. If you have an annotation, e.g., "Patrick", and you change that annotation to "This is the new version of Patrick", then the constant pool entry that holds the annotation will contain "Patrick" in one version of the class file and will contain "This is the new version of Patrick" in the new version of the class file. In all likelyhood, the constant pool index for both annotations will be the same, but the values will be different. When the constant pools for the two versions of the class are merged, a new entry containing "This is the new version of Patrick" will be appended to the end of the merged constant pool. The existing constant pool entry that contains "Patrick" is left in place. A mapping entry is created to record the original location of "This is the new version of Patrick" and the new location. The merging process then updates all known uses of the original location to refer to the new location. This merging process allows both old and new versions to co-exist safely. The key phrase is "all known uses". Embedded in the annotation data are constant pool indices that need to be updated. I didn't know that when I wrote the constant pool merging code so those indices are not updated.
23-03-2006
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
14-06-2004
EVALUATION I don't think this is a showstopper for 1.5.0 and am committing it to 1.5.1. ###@###.### 2004-04-12
12-04-2004

Relates :	JDK-6393258 - crash: redefine classes method order change incomplete
Relates :	JDK-6412391 - fix for annotation cache and RedefineClasses() conflict needs HotSpot changes
Relates :	JDK-6422536 - (ann) {Constructor,Field,Method}.getAnnotation() cache conflicts with RedefineClasses()
Relates :	JDK-6407335 - (ann) java.lang.Class.getAnnotation() cache conflicts with RedefineClasses()
Relates :	JDK-5088035 - hotswap fires assert(0 <= i && i < length(),"index out of bounds")
Relates :	JDK-6422541 - fix for {Constructor,Field,Method} annotation cache and RedefineClasses() conflict needs HS changes