Community
Participate
Working Groups
20041101 In 1.5 we have now 3 'layers' of type bindings a.) For a declaration List<T> what you get is a 'generic type' type binding. binding.getMethods() would return you, amongst others, 'add(T)'. b.) For a reference List<String> you get a 'parametrized type' type binding. When asked for its methods you get methods like 'add(String)' c.) A reference 'List' returns a raw type binding, returning a method 'add(Object)' The current API of ITypeBinding doesn't make a difference between a. and b. and also doesn't have API to go from b. to a. or even from a. to b. What does exist are methods 'getErasure()' to get c. from a. and b. and isRawType() to test for c. In IMethodBinding there is the same problem - add(T) - add(List) - add(Object)
> What does exist are methods 'getErasure()' to get c. from a. and b. and > isRawType() to test for c. That's not exactly true in 200411022000. [Note: I use List<E> where Martin wrote List<T>, since List<E> is used in jdk1.5 source.] Calling getErasure() on source reference binding for 'List' (raw, c.) or 'List<String>' (parameterized, b.) yields List<E> (declaration, a.), whose getTypeParameters() is {E} and whose isParameterizedType() and isRawType() both return false. getErasure() is a link a./b./c. ==> a. Test for a.: isRawType() == false && isParameterizedType() == false [Test whether type is generic: getTypeParameters().length != 0] Test for b.: isParameterizedType() == true Test for c.: isRawType() == true Missing links are AB.) a. ==> b.: List<E>, type argument 'String' ==> List<String> AC.) a. ==> c.: List<E> ==> List Conversions b. ==> c. and c. ==> b. can be composed from getErasure() and AC. and AB.
Along the lines of making DOM AST more usable.
I think this bug is mostly solved with the latest API additions - isGenericType() marks a.) - isParameterizedType() marks b.) - isRawType() marks c.) getErasure() gives a.) from b. and c. Missing are methods for get b. or c. from a.) but that was an 'nice to have' request and along the lines of bug 40096 (please reopen that one... :-))
Martin, since this bug was entered, only isGenericType() was added. So I guess this bug should have been a request for isGenericType(), right ?
yes, isGenericType() was in fact the main request. The rest is covered by bug 40096
Thanks Martin. This is a dup of bug 78266 then. *** This bug has been marked as a duplicate of 78266 ***