Community
Participate
Working Groups
See comments in test code snippet: public class Gen<T> { static class StaticInnerNoParam { // Compiler error on the following line -- // "Cannot make a static reference to non-static type T" // This is expected T x; } // Warning reported on the following line -- // "The type parameter T is hiding the type T" // Perhaps this is technically true? (I'm not quite sure what // the Java spec says about this.) But the outer T cannot // be used in this scope anyway, so it seems that the // warning is not really beneficial. I use the same names // for corresponding type parameters between the outer // class and static inner classes, so this generates // unnecessary warnings for me. static class StaticInnerParam<T> { } }
I agree we shouldn't complain about hiding here, as outer T isn't accessible in context.
Added GenericTypeTest#test774.
Tuned hiding check on TypeParameter, also ensured check is performed for generic method type parameters. Fixed
Verified in 3.2 M1 with build I20050808-2000.
Verified using M20050923-1430 for 3.1.1
I have the same warning when implementing List as follows: public class ReadOnlyListProxy<T> extends AbstractProxy<List<T>> implements List<T> { ... public <T> T[] toArray(T[] a) {// The warning comes on this line return getData().toArray(a); } } getData is defined in AbstractProxy<T> as: protected T getData() { return theReference.get(); } All the other methods of List are fine. The signature of the offending method is identical to the one in List.
Right, but this one is a case where one definition of T (on method) is hiding the one from the enclosing type. So you cannot use the enclosing type parameter T within the method. It is the intent of this warning to report such a case. What do you see being wrong here ?
I guess I expect the signature of my implemenation of List<E> to be the same as the interface. In fact any changes I made to it just gave an error that I was not implementing the method. This signature is just what I got when I asked Eclipse to implement the method. Also the method works fine. How could the declaration be changed to remove the warning?
Simply rename the type parameter on the method to not collide: public <U> U[] toArray(U[] a) {// The warning comes on this line return getData().toArray(a); } note that interface List<E> defines <T> toArray (observe non conflicting type parameter names).
Now you have a point. The tooling shouldn't generate a method signature which exposes this warning (it should perform substitution for you).
David/Martin: whose bug is this ?
That's probably ours. Please file a new bug request.
We have a bug in JDT/Core because we compute a bad signature and a bad completion string in our proposal. But i believe that JDT/Text don't use our completion string. So i suspect a bug on both side.
I opened a new CodeAssist bug in JDT/Core for this problem (bug 128169). I close this one because the original problem of this bug is fixed.
(In reply to comment #10) > Now you have a point. The tooling shouldn't generate a method signature which > exposes this warning (it should perform substitution for you). Thanks for your help. Now I would like to get disconnected from this bug, but I can's see how.
