Community
Participate
Working Groups
org.eclipse.core.filebuffers.FileBuffers#normalizeLocation returns different normalized IPath. Here is the detail. Given that the workspace location is "C:\workspace", and there are no files. Then, when we run the follwoing code, IPath path1 = new Path("C:/workspace/nonexistingfile"); IFile file = ResourcesPlugin.getWorkspace().getRoot().getFileForLocation(path1); IPath path2 = FileBuffers.normalizeLocation(file.getLocation()); IPath path3 = FileBuffers.normalizeLocation(file.getFullPath()); path2.toString() is "C:/workspace/nonexistingfile", whereas path3.toString() is "/nonexistingfile". The key is that if path1 points to the existing file, both cases return the same normalized path ("/existingfile") as its java doc says, yet if path1 points to the non-existing file, they are different. According to its java doc, For a path to a non-existing workspace file, the normalized form is the absolute form of the path. and I guess this differenece comes from IPath#makeAbsolute's behaviour. I really don't know this difference is what is suppoed to be. Because some WTP components asuume that FileBuffers#normalizeLocation returns the consistent IPath if the passed IPath is semantically same.
Good catch!
The code listed in comment 0 results in an NPE since IWorkspaceRoot.getFileForLocation(IPath) returns 'null' if there's no file at the given location: * @return the corresponding file in the workspace, * or <code>null</code> if none
Ah, the test case has a bug. Need a project. Both, the workspace and the project itself need to exist. Given that the workspace location is "C:\workspace", and the project location is "C:\workspace\project" and there are no files under this project, the revised test case is : IPath path1 = new Path("C:/workspace/project/nonexistingfile"); IFile file = ResourcesPlugin.getWorkspace().getRoot().getFileForLocation(path1); IPath path2 = FileBuffers.normalizeLocation(file.getLocation()); IPath path3 = FileBuffers.normalizeLocation(file.getFullPath()); path2.toString() is "C:/workspace/project/nonexistingfile", whereas path3.toString() is "/project/nonexistingfile". Note: According to IWorkspaceRoot#getFileForLocation java doc, it says : * The resulting file need not exist in the workspace. Actually, it works with 3.2M6.
The current behavior is correct and according to the spech which says: 1) Existing Workspace Files: For a path or location for which there exists a workspace file, the normalized form is that file's workspace relative, absolute path as returned by IFile#getFullPath() 2) Non-existing Workspace Files: For a path to a non-existing workspace file, the normalized form is the absolute form of the path i.e. path.makeAbsolute() 3) External Files: For a location for which there exists no workspace file, the normalized form is the absolute form of the location i.e. location.makeAbsolute() In your example IPath path2 = FileBuffers.normalizeLocation(file.getLocation()); you enter a location and not a path and hence 3) is applied While here IPath path3 = FileBuffers.normalizeLocation(file.getFullPath()); you enter a path and hence 2) applies. IPath path3 = FileBuffers.normalizeLocation(file.getFullPath());
David, what would you think ? If that spec is right, I would guess some WTP usage would have a problem.... .
I bet that WTP and many other clients would have by far more problems when we changed the contract after three years. The binding part of the API is the spec and not the implementation. The main problem/confusion is caused by combining path and location into one parameter, see bug 99610 for a way to improve this on our side.
(In reply to comment #5) > David, what would you think ? If that spec is right, I would guess > some WTP usage would have a problem.... > I believe we have already worked about this unusual spec in WTP. :) And, I agree, as long as it is spec'd that way, it should not be changed, ... just "added to", or an alternative provided ... as Dani is going to do in bug 99610. If you still see a problem in WTP related to this, let us know.
