Bug 53555 - SourceType#get*QualifiedName() methods return unusable/invalid names for local types
Summary: SourceType#get*QualifiedName() methods return unusable/invalid names for loca...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-02 18:45 EST by Luc Bourlier CLA
Modified: 2004-05-18 11:09 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luc Bourlier CLA 2004-03-02 18:45:54 EST
SourceType#get*QualifiedName() methods return name that are non-standard (there
is no standard) for local types, and the javadoc in IType doesn't specify what
we should expect from these method in these cases.

For anonymous classes, SourceType#get*QualifiedName() methods return names like
'<OuterTypeName>$<number>'. This is the format that almost all Java compilers
use to name anonymous classes, but this format is not specified, Java compilers
can add the identifier they want after the '$'. Even if the compiler uses this
format,  the way it orders the anonymous classes can be different than the way
JDT does it.

For local classes, SourceType#get*QualifiedName() methods return names like
'<OuterTypeName>$<LocalTypeName>'. This format isn't used by any compiler that I
know of. In fact this the format usualy used by compilers form inner (no-local)
classes. Compilers usualy use '<OuterTypeName>$<number>$<LocalTypeName>' to name
local classes, but as for anonymous classes, there is no specification.

I don't know what should be returned, but I'm not sure that what is actualy
returned helps anybody. May be the javadoc in IType should say that for local
types in source types, the names returned are not 'official' names.
Comment 1 Philipe Mulet CLA 2004-03-03 03:10:40 EST
Why is the output so important to you ? These are mostly for presentation 
purpose. Are you trying to infer back things based on them ?

I agree that local type name look weird.
Comment 2 Luc Bourlier CLA 2004-03-04 02:59:37 EST
We are using this name when adding and removing breakpoints.

In the process of adding/removing breakpoint, we are using
IClassFile#getElementAt() or ICompilationUnit#getElementAt() to get a first idea
of in which type, the user is trying to add/remove a breakpoint. And we use the
name of this type to check if the user is trying to add breakpoint (not existing
breakpoint at this location) or to remove a breakpoint (existing breakpoint at
this location).
I pretty sure that some time ago, you were not returning elements like local
types when calling the getElementAt() method, so we had no problems. Now you are
more precise in your results, it's great, we just have to manage it.

I modified our code to only use type with 'well-know' names (see bug 52385),
because it doesn't matter what you decide to do with this bug, you will never
return the right names for local types, because there is no 'right' names.

I filed this bug report mainly because the implementation does something that is
not specified in the javadoc of the interface.
Comment 3 Jerome Lanneluc CLA 2004-03-04 04:53:33 EST
Thanks. I'll update the spec then.
Comment 4 Jerome Lanneluc CLA 2004-05-12 11:56:08 EDT
Improved the spec of IType#getTypeQualifiedName(char). Other get*QualifiedName
() methods refer to this one.
Comment 5 Frederic Fusier CLA 2004-05-18 11:09:10 EDT
Verified for 3.0 M9 with build I200405180816.