Community
Participate
Working Groups
Define the "getName()" method invocation of "this.getClass().getName()", where "this" is any instance, to be mi. The following code finds the qualified name of the declaring class, java.lang.Class, to be "java.lang.Class<>", and not "java.lang.Class". org.eclipse.jdt.core.dom.MethodInvocation mi; ... IMethodBinding methodBinding = mi.resolveMethodBinding(); String qualifiedName = methodBinding.getDeclaringClass().getQualifiedName();
The class is a parameterized class with a capture as the type argument. Since the qualified name of a capture is an empty string, the answer is right. Martin, What would you expect in this case?
The empty string for captures isn't really helpful. I see two possibilities: a. we find a notation for captures (for example use curly braces java.lang.Class<{? extends X}>) b. we skip captures for qualified names, and define that the qualified name for a captures is its wildcard type I guess to answer that we have to define what the real usecase of 'getQualifiedType' is. Some people use it to render a binding, some to get a canonical name for a binding, some to debug. To render, it is better to use some own code as you need more options if qualified names should be used or not: In JDT.UI we have the BindingLabelProvider for that, which we should make API for 3.3. To get a canonical name, clients should use getKey. I think getQualifiedName makes most sense for type declarations (not references). I'm fine with a.) or b.) but prefer b.) for getQualifiedName
(In reply to comment #2) > The empty string for captures isn't really helpful. I see two possibilities: > a. we find a notation for captures (for example use curly braces > java.lang.Class<{? extends X}>) This would break existing spec. > b. we skip captures for qualified names, and define that the qualified name for > a captures is its wildcard type I don't think this would be fine according to the current spec. The '<' and '>' are required and the capture fully qualified name is an empty string. So the actual returned value implements the current specs. I would close as INVALID.
The spec says that the qualified name of a capture is an empty string. But doesn't that still leave it us to define how the qualified name of a parameterized type with a capture as type argument is rendered? In the end we want the API to produce something useful. I don't think the current sulution is helping anyone.
Sure, but we still need to provide a solution that is not an API breakage. For me a) and b) would break existing API. I don't see a way to return something else that would not break existing API.
Martin, If you see a way to solve this that is not a breaking change for existing users, let me know. Otherwise I will close as WONTFIX. I think it would be time to fix this one or close it.
I leave it up to you..
Closing as WONTFIX. There is no way we can fix this without breaking existing users.
Verified for 3.7M1
