Community
Participate
Working Groups
20070412 1. set a breakpoint in TypeNameMatch.getQualifiedName 2. Open the new type wizard 3. choose a super interafce 'Map.Entry' 4. The breakpoint is reached and the qualified name is 'java.util.Map$Entry' should be java.util.Map.Entry
I guess you were talking about getFullyQualifiedName() or getTypeQualifiedName() as TypeNameMatch does not implement getQualifiedName()... By the way, as the TypeNameMatch only wraps calls to its IType, the answer is the same than in bug 156168 comment 2. *** This bug has been marked as a duplicate of bug 156168 ***
Maybe the Javadoc of TypeNameMatch.getFullyQualifiedName should have be as specific as the one on IType.
(In reply to comment #2) > Maybe the Javadoc of TypeNameMatch.getFullyQualifiedName should have be as > specific as the one on IType. > There's already an obvious reference to the IType Javadoc: * @see IType#getFullyQualifiedName(char) Is it really necessary to duplicate it?
Oops, sorry, you're right!
Please reopen this bug. We should not copy this bad behavior from IType. Almost every user of TypeNameMatch.getQualifiedName should manually change the $ to . or there will be a bug with methods like 'IProject.findType' or 'Signature.getSimpleName' ect. The search engine has the capability to give back the correct type name, with all enclosing segments correctly separated. Our old TypeInfo also did this correctly. Reading the spec of 'TypeNameMatch.getQualifiedName': /** * Returns the matched type's fully qualified name using '.' character * as separator (e.g. package name + '.' enclosing type names + '.' simple name). * * @see #getType() * @see IType#getFullyQualifiedName(char) * * @throws NullPointerException if matched type is <code> null</code> * @return Fully qualified type name of the type */ The first line is really clear. Again, that you use 'IType#getFullyQualifiedName' is an implementation detail. Other implementations of could implement TypeNameMatch without using a IType.
I'm completely confused: 1. you're asking to reopen a bug that you just closed (you just changed the status to CLOSED) 2. why would a client be more confused by TypeNameMatch#getTypeQualifiedName() than by IType#getTypeQualifiedName() ? (I agree that having a different separator for binary and source types is bad in IType#getTypeQualifiedName(), but this exists since 2.0 and nobody complained until now). 3. why do we have TypeNameMatch#getTypeQualifiedName() ? It looks like a helper for getType().getTypeQualifiedName('.') which is simple enough.
1. yes, after discovering another bug introduced by this problem I would like to reopen the issue. Sorry, setting it to closed wasn't my intention 2. I always meant getFullyQualifiedName. But both (getFullyQualifiedName and getTypeQualifiedName) have the same problem. We don't want $ as separator but '.'. Just as the first line of the APIs specs in TypeNameMatch says. It's not just a presentation issue, but a problem when using the qualified name programmatically. For example 'findType' doesn't work with qualified names for inner class files. The issue has been known in IType.getFullyQualifiedName('.') for a long time and we fought hard to get it fixed there. Unfortunately we didn't succeed and we had to add a work around: all our code has to use JavaModelUtil.getFullyQualifiedName to get the fully qualified name for ITypes. If there is any possibility to revert the decision for IType.getFullyQualifiedName, we would be more than happy. I believe most clients aren't aware of the subtleties, and I believe most clients have a bug with inner classes from class files. With the new TypeNameMatch we would have to introduce the workaround utility as well. Our old internal TypeInfo didn't require that, so that's why we introduce several bugs without realizing. 3. TypeNameMatch is an abstract class that can be implemented in different ways. It is anticipated that some implementations will implement getTypeQualifiedName in a more performant way than getType().getTypeQualifiedName(). In the open type dialog, the getXYName methods are called very often and for every element. So we should get the best performance possible.
(In reply to comment #7) > 2. I always meant getFullyQualifiedName. But both (getFullyQualifiedName and > getTypeQualifiedName) have the same problem. We don't want $ as separator but > '.'. Just as the first line of the APIs specs in TypeNameMatch says. You are right. Reopening this bug. [...] > The issue has been known in IType.getFullyQualifiedName('.') for a long time > and we fought hard to get it fixed there. For reference, what is the bug number ? [...] > If there is any possibility to revert the decision for > IType.getFullyQualifiedName, we would be more than happy. Unfortunately we cannot change the contract as it is very clear that $ is used for binary types. > I believe most > clients aren't aware of the subtleties, and I believe most clients have a bug > with inner classes from class files. I believe that most clients are smart enough to read the spec. [...] > 3. TypeNameMatch is an abstract class that can be implemented in different > ways. This is a typo in the spec (it was not intended to be implematable) and should be fixed. I entered bug 185119 for this. [...]
The discussion with the '$' was bug 120640 and probably a long chat with Olivier. Regardless if TypeNameMatch is spec'ed as implementable for external clients, it is still anticipated that there will be subtypes (maybe in jdt.core) that are not built from an IType. That's why getTypeQualifiedName() isn't required to be getType().getTypeQualifiedName(). It would be good if the spec says something about that: always use the APIs on the match first before acquiring the IType...
+1 for a useful API, i.e. also use '.' as separator for binary types.
*** Bug 206143 has been marked as a duplicate of this bug. ***
can this be fixed for 3.4?
*** Bug 209146 has been marked as a duplicate of this bug. ***
*** Bug 212878 has been marked as a duplicate of this bug. ***
To be investigated during M6. Maybe there are other cases outside search being problematic too; like in JavaModel; however this would be another bug.
*** Bug 165849 has been marked as a duplicate of this bug. ***
*** Bug 148243 has been marked as a duplicate of this bug. ***
Bug 156168 was actually fixed by changing the behavior for binary types to replace the $ in class file name by the given enclosing type separator (as this was what most clients expected) and by amending the spec. So fix for bug 156168 fixes this bug. Marking it as a dup again. *** This bug has been marked as a duplicate of bug 156168 ***
Verified for 3.4M6 using build I20080324-1300.
