Community
Participate
Working Groups
This bug report is closely conntected with bug 137203. 3.2RC2 and 3.2RC3 now resolves the unresolved binary reference mentioned in bug 137203 correctly, but when extracting the concerned method definition to a third file, the change from the method's (unnecessary) parameterized argument type to the non-parameterized argument type as well as any change to the classes ExtendedOuter and Worker results in a compile time error that only disappears when the enclosing project is rebuilt. Guess the following scenario > Outer.java >>> public class Outer<O> { public class Inner {} } < Outer.java <<< > ExtendedOuter.java >>> public class ExtendedOuter<E> extends Outer<E> { public class ExtendedInner extends Inner { public void method() { Worker.method(this); } } } < ExtendedOuter.java <<< > Worker.java >>> public class Worker { public static void method(Outer.Inner i) {} } < Worker.java <<< Every time ExtendedOuter or Worker is changed, e.g., by adding a field or method declaration, the described compile time error is introduced to ExtendedOuter. The same happens when changing the method definition in Worker to public static void method(Outer<?>.Inner i) {} and back again.
Reproduced with RC3.
When compiled from source, the parameter to Worker.method(Outer.Inner) is a RAW type [Inner#RAW enclosingType Outer#RAW] and the message send's argument is a ParameterizedType [ExtendedInner extends Inner enclosing type : ExtendedOuter<E>] But when Worker is picked up a class file, the method's parameter becomes a ParameterizedType [Inner enclosingType Outer<O>]. The problem appears to be in LookupEnvironment.convertToRawType()
+1 for 3.2RC4
Added regression test: GenericTypeTest#test0981 (disabled)
Kent suggested addressing it with following change on LookupEnvironment: ReferenceBinding getTypeFromCompoundName(char[][] compoundName, boolean isParameterized) { ReferenceBinding binding = getCachedType(compoundName); if (binding == null) { PackageBinding packageBinding = computePackageFrom(compoundName); binding = new UnresolvedReferenceBinding(compoundName, packageBinding); packageBinding.addType(binding); } else if (binding == TheNotFoundType) { problemReporter.isClassPathCorrect(compoundName, null); return null; // will not get here since the above error aborts the compilation } else if (!isParameterized) { // check raw type, only for resolved types binding = (ReferenceBinding)convertUnresolvedBinaryToRawType(binding); } return binding; }
Post 3.2, we should revisit the separation between #convertToRawType and #convertUnresolvedBinaryToRawType. Should be only one, doing the latter; and implicit member references should be dealt with differently. But this is more extensive.
Created attachment 41090 [details] Proposed patch This is the minimal patch, which is mirroring what we do in other cases in similar situations. Just missed one sender. Without the patch, we reject valid code. Dani/Martin: pls cast your vote
Also added: GenericTypeTest#test0982
Patch looks good. Approving for 3.2 RC4.
+1 for 3.2 RC4
Fix released
Verified with I20060511-2000 for 3.2RC4
