Community
Participate
Working Groups
Given package p; public class X { class Y { } } as binary (e.g. in a JAR). Calling getFullyQualifiedName('.') on a the BinaryType describing Y returns p.X$Y instead of p.X.Y as the documentation says
Problem is in NameMember.getTypeQualifiedName(char, boolean) which does not replace '$' with enclosingTypeSeparator for CLASS_FILE when indexOf('$') != -1...
I read again the documentation: /** * Returns the type-qualified name of this type, * including qualification for any enclosing types, * but not including package qualification. * For source types, this consists of the simple names of any enclosing types, * separated by <code>enclosingTypeSeparator</code>, followed by the * simple name of this type or the occurence count of this type if it is anonymous. * For binary types, this is the name of the class file without the ".class" suffix. * * For example: * <ul> * <li>the type qualified name of a class B defined as a member of a class A * using the '.' separator is "A.B"</li> * <li>the type qualified name of a class B defined as a member of a class A * using the '$' separator is "A$B"</li> * <li>the type qualified name of a binary type whose class file is A$B.class * using the '.' separator is "A$B"</li> * <li>the type qualified name of a binary type whose class file is A$B.class * using the '$' separator is "A$B"</li> * <li>the type qualified name of an anonymous binary type whose class file is A$1.class * using the '.' separator is "A$1"</li> * </ul> * * This is a handle-only method. * * @param enclosingTypeSeparator the specified enclosing type separator * @return the type-qualified name of this type * @since 2.0 */ String getTypeQualifiedName(char enclosingTypeSeparator); The important point is: For binary types, this is the name of the class file without the ".class" suffix. ... * <li>the type qualified name of a binary type whose class file is A$B.class * using the '$' separator is "A$B"</li> So, we behave as documented => close as INVALID
*** Bug 165849 has been marked as a duplicate of this bug. ***
*** Bug 182179 has been marked as a duplicate of this bug. ***
Sorry, it's unbelievable, but I have to reopen this. From HEAD of IType: /** [..] * This is the name of the package, followed by <code>'.'</code>, * followed by the type-qualified name using the * <code>enclosingTypeSeparator</code>. [..] * <li>the fully qualified name of a binary type whose class file is * x/y/A$B.class using the '.' separator is "x.y.A.B"</li> [..] */ String getFullyQualifiedName(char enclosingTypeSeparator); /** [..] * For binary types, this is the name of the class file without the ".class" suffix. [..] * <li>the type qualified name of a binary type whose class file is A$B.class * using the '.' separator is "A$B"</li> [..] */ String getTypeQualifiedName(char enclosingTypeSeparator); Javadoc of getTypeQualifiedName(char) was changed on 2005-12-14 from * <li>the type qualified name of a binary type whose class file is A$B.class * using the '.' separator is "A.B"</li> ==> The definition of #getFullyQualifiedName(char) is inconsistent: It says it uses the type-qualified name (which would result in "x.y.A$B"), but its example says "x.y.A.B". The implementation has probably been to return "x.y.A$B" for a long time, so I think the only action we can take now is to finally make the specification of #getFullyQualifiedName(char) match the implementation.
Created attachment 80247 [details] Fix Fix with big warnings for the unexpected behavior of this API. We definitely need to make sure clients are made aware of the deficiencies of these methods.
Assign to Jerome who has the most valuable feedback on these API methods to decide what to do finally on this long standing issue... (see also bug 120640)
Can't we just fix the behavior to what the user expects here: No $, only '.'. Even if it involves some dirty tricks in the implementation, but it would jut make all users life easier and less complicated. This issue is a source of reoccurring bugs. At the moment we in JDT UI have a utility method to wrap and fix getFullyQualifiedName. The search engine was always capable of returning the full information (package name, enclosing type names, type name). We need this for correctness also there. See discussion in bug 182179 comment 7.
Would that be ok if the fully qualified name of a binary type named A$B (as in package x.y; public class A$B { } ) were "x.y.A.B" ? Note that since getFullyQualifiedName(..) is a handle only method we cannot open the underlying .cass file to get the information.
(In reply to comment #9) If there's no more information, the correct assumption would indeed be that A$B.class comes from a nested binary type See JLS3 3.8: "The $ character should be used only in mechanically generated source code or, rarely, to access preexisting names on legacy systems." and JLS3 13.1: "The binary name of a member type consists of the binary name of its immediately enclosing type, followed by $, followed by the simple name of the member."
I've just plowed into this bug while looking into links in the Javadoc view. Ouch, ouch, ouch. This is horrible. BinaryType is not fulfulling the specification of IType, and is behaving inconsistently with SourceType. Please fix. The concern about literal $ in class names seems silly - if the implementation can't resolve the ambiguity, then it can't resolve the ambiguity. But why not go for the option that will be correct 99.9% of the time, rather than the 0.1% option?
Created attachment 92167 [details] Proposed fix and regression tests
Fix and tests released for 3.4M6
Verified for 3.4M6 using build I20080324-1300.
