Community
Participate
Working Groups
Head 2006/01/10 public class TestImpl implements p.Test { private String town; public String getTown() { return town; } public void setTown(String town) { this.town = town; } } Inspect the type binding retrieved from the type declaration and look at the declared fields. Observe there is a field declaration called: 1: TestImpl.has inconsistent hierarchy The field is especially problematic for APT.
Kent: did we make this field be synthetic ? We should hide it.
We added the field so we can detect the case of: class A extends Missing {} // we create a problem type of class A {} becoming: class A {} So we need this field to tell us that A has changed structurally, because its superclass did not appear to change.
Can you think of another way we can take of this case ?
It could be in the classfile, since you need it, but we should ensure the field artifact is correctly hidden from our tools (like we do hide synthetic constructor arguments for innerclasses).
We could remove the field if: We add the attribute 'AttributeNameConstants.SuperclassMissing' to any .class file with a missing superclass & then detect that this attribute does not exist on the newly created copy and report a structural change. We'll also need a new tagBit 'SuperclassMissing' to set on sourceTypeBindings in ClassScope.connectSuperclass(), so we can tell that a type should have the new attribute. Make sense?
The new attribute could be used to set the tagBits SuperclassMissing when reading the .class file. Then the structural change could be detected by checking the tagbits. It is trivial to add a new attribute. Simply let me know you want to go on this path.
We just need the new attribute, not the tagBit. We want to replace this code in ClassScope.buildFields() boolean hierarchyIsInconsistent = referenceContext.binding.isHierarchyInconsistent(); if (referenceContext.fields == null) { if (hierarchyIsInconsistent) { // 72468 referenceContext.binding.fields = new FieldBinding[1]; referenceContext.binding.fields[0] = new FieldBinding(IncompleteHierarchy, TypeBinding.INT, ClassFileConstants.AccPrivate, referenceContext.binding, null); With the attribute in the class file, then compare it in the ClassFileReader.
+1 for attribute. As per discussion with Kent, we do not need extra tagbit.
Created attachment 33672 [details] Proposed patch Kent, This patch takes care of the creation of the new attribute. The classfile reader is updated to reflect the presence of this attribute in its access flags. I cleaned the code that was using the field binding. Please double check the patch and you can release. I passed all builder tests with it.
Created attachment 33673 [details] Proposed patch Previous patch left an unused local behind. This is cleaned with this patch.
Looks good - DependencyTests still pass. Released patch to remove the field and use an attribute in the class file instead.
Verified for 3.2 M5 using build I20060214-0010
