Community
Participate
Working Groups
I20050118-1015 The bindings for "Numbers" after "enum" and for "Numbers" before getSquare() are not identical nor isEqualTo(..) each other, but their getKey()s are the same. IMO, the bindings should be identical. class Generic<E> { enum Numbers { ONE { Numbers getSquare() { return ONE; } }; abstract Numbers getSquare(); } }
I will investigate.
The second Numbers is seen as a ParameterizedTypeBinding that contains a MemberTypeBinding that is the right one. I will investigate why we get a parameterized type binding.
Philippe, could you please tell me why the second Numbers name is a ParameterizedTypeBinding? Thanks.
I agree it is cumbersome. Currently, the reference to Numbers within Numbers is the source type binding (i.e. MemberTypeBinding with SourceTypeBinding: Generic<E> as its enclosing type). When accessed from the outside of Numbers definition, it is seen differently. Though it does not quite make sense IMO, since it isn't generic.
To my mind, this bug also shows up in the following case (two java-classes) ***TakeEnumPar.java (first class): public interface TakeEnumPar<E extends Enum<E>> { } ***TestTakeEnum.java (second class): public class TestTakeEnum<A> { public enum MyEnum { A, B, C }; private final static TakeEnumPar<MyEnum> x = new TakeEnumPar<MyEnum>() { }; } **** Try to compile the two files with eclipse and with JDK. With ecplise an error will be shown in the second class when declaring the static variable x. MyEnum is said to be no substitution for the generic Enum-type parameter. If you remove the generic type variable from the second class, however, everything works fine. To my mind it seems, that static elements like the enum are qualified by the generic type variable of the second class, although they are static. ciao Volker
*** This bug has been marked as a duplicate of 83064 ***
Bug 83064 is fixed, but the regression test for this one is still failing.
