Community
Participate
Working Groups
Steps: o In the Resource Perspective, selected a package. o Right-click/Move to a new package. o Switch to the Java Browsing persepective. o Crtl-Shift-T to open the find dialog. o Paste in the class name (no package prefix) of one of the class that has been moved. o BUG -> The full name displayed in the list box is the OLD package + class name. o Hit enter gives you an error box: "Cannot uniquely map the type name to a type".
Actually, that is not the problem. The move, just, well, _moved_ the files. The package decl is now messed up for of all the java files in the package: they are the OLD package location. What to do: give a warning that you are shooting yourself in the foot or delegate the move to the java-aware part of eclipse?
Does this still occur in 3.1m6 ? If so, pls reopen
Reproduced using RC2 candidate (build N20050608-0010)
Reproduced with 3.2M6.
Simpler steps: 1. In Java perspective 2. Create Java Project "P" 3. Create package "p1" 4. Create "X.java" in "p1" with the following contents: package p1; public class X { } 5. Change contents to: package p2; public class X { } 6. Ctrl+Shift+T 7. Type "X" 8. Select X - p2 9. OK
SearchEngine correctly reports the path being "/P/p1/X.java" but UI tries to map "/P/p2/X.java" Moving to JDT UI for further investigation.
Dirk, can you have a look at this?
The TypeNameRequestor passed to SearchEngine#searchAllTypeNames receives the following values: char[] packageName: [p, 2] char[] simpleTypeName: [X] char[][] enclosingTypeNames: String path: /P/p1/X.java Although X is still sitting in p1 the packageName reported back is p2. Moving to JDT/Core for further investigation.
Right, the package declaration is p2. This is not the package fragment. But JDT UI should uses the package declaration to construct a path, when the correct path has already been reported.
Correct, but we drop some of the information (in this case the path) for optimization reasons (in the past we stored both but changed this around 2.x to produce a lower memory footprint). Even if we store both information then the UI would still show p2 which from a containment point of view isn't correct. What is the rational behind reporting p2 in this case ?
The rational is: there is a difference between the package fragment and the package declaration. In this case the package fragment is p1 (reported through the path) and the package declaration is p2 (reported through the package name). If both were equals in the case of this bug, we would loose information. Is your optimization still needed since you no longer have all types in memory ?
It is for sure less necessary but still saves a fair amount of memory since the paths are large. IMO the package for an type is always the package in which it is contained not the text after the package declaration statement. For the UI it makes more sense to present the containment information than the package declaration statement. IMO the user will be suprised if we show X - p2 in the all types dialog when the type still sits in X - p1.
The spec of TypeNameRequestor#acceptType(...) is not clear indeed. I entered bug 135493 to clarify it. From there, existing clients can either assume that the 'packageName' is the package declaration, or that it is the package fragment name. If we changed 'packageName' to be the package fragment name, we would loose the package declaration information, and clients assuming the package declaration would have no way to get this information. That's why I think it is better to keep the current behavior and let clients assuming 'packageName' is the package fragment name use the path instead to get the package fragment name.
Created attachment 37980 [details] Patch against org.eclipse.jdt.ui (2006/04/05 00:10:00) This patch uses the path to compute the package name if it is different from the package declararion. Note that it doesn't keep the path in memory.
I understand that it might be a little late to change this for 3.2 but from a client perspective getting the package declaration statement is IMO in 99% of the cases not what I would expect (JDT/UI renders always the containing package, and I think others do as well). So reporting back the package declaration statement would force almost every client which present the type in the user interface to parse the (from my understanding opaque) path. So I opt for the following: - we leave the bug in for 3.2 (we are shipping since 1.0 with this) or we add Jerome's patch to the type info factory. - in 3.3 we change the implementation to return the name of the containing package. If we think we need both values then we extend the TypeNameRequestor. Opinions ?
I think fixing the reported package would be the right thing to do: We always used the physical location of a file to define its package: This can be seen on Java element deltas that are always reported against the physical location. IType.getQualifiedName uses the parent chain to get the package (not the declaration). Using the patch looks like the wrong way to go. So either we change the reported package now, or we stick with the bug and fix it in 3.3.
Just wanted to add that from an index perspective, the package fragment is unknown. Since this is a pure index query operation, I would not call it a bug. I understand that this is not expected by all clients (99% is a big number ;-)), but we should make it clear and find another solution for post 3.2. In the meantime, applying the patch would still be a good idea.
No action planned for 3.2
Reopen as this problem does no longer occur since Open Type dialog have used TypeNameMatchRequestor instead of TypeNameRequestor...
Cannot reproduce this problem using 3.3 build. I assume this has been fixed when Open Type used new searchAllTypeName API method with TypeNameMatchRequestor...
Set target to 3.4M2 to include this bug in our milestone verification process...
Verified for 3.4 M2 using build I20070917-0010.
