Summary: | [DOM] java.lang.Class qualified name is "java.lang.Class<>" | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Scott Cowan <scowan> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | markus.kell.r, martinae, satyam.kandula |
Version: | 3.2 | ||
Target Milestone: | 3.7 M1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Scott Cowan
2006-08-02 10:48:15 EDT
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 |