Summary: | Open declaration opens wrong class with the same name | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Andrey Loskutov <loskutov> |
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | amj87.iitr, deepakazad, markus.kell.r |
Version: | 3.8 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | stalebug | ||
Bug Depends on: | 73957 | ||
Bug Blocks: |
Description
Andrey Loskutov
2012-04-04 09:15:59 EDT
I can reproduce using 3.7.2. However, this works using the latest 4.2 build (I20120321-0610). I think this got fixed along with bug 318401. Moving to JDT/Core for confirmation. Using 3.8M6, the toURI call resolves to org.eclipse.core.runtime.URIUtil.toURI(URL) Strange. I will take a look. (In reply to comment #2) > Using 3.8M6, the toURI call resolves to > org.eclipse.core.runtime.URIUtil.toURI(URL) > Strange. I will take a look. Andrey, can you confirm if you see org.eclipse.core.resources.URIUtil or org.eclipse.core.runtime.URIUtil? Analysing a bit more, according to JLS 6.4.1 "A single-type-import declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of: • any top level type named n declared in another compilation unit of p • any type named n imported by a type-import-on-demand declaration in c • any type named n imported by a static-import-on-demand declaration in c" So, in WorkspaceRoot, org.eclipse.core.filesystem.URIUtil should be the type available. (In reply to comment #3) > Andrey, can you confirm if you see org.eclipse.core.resources.URIUtil or > org.eclipse.core.runtime.URIUtil? org.eclipse.core.runtime.URIUtil Sorry I have no idea how I got org.eclipse.core.resources.URIUtil in the original bug description. It should be: TO BE: Unfortunately, org.eclipse.core.runtime.URIUtil is wrong class to open! org.eclipse.core.filesystem.URIUtil must be opened instead. This is most probably an effect of bug 73957. If WorkspaceRoot#findFilesForLocation(IPath) is a binary class, then it may have compile errors (which are not shown, since the class file is already compiled, but you can see them e.g. in the AST View). In a fresh workspace with a single bundle that only requires org.eclipse.core.runtime and org.eclipse.core.resources, the org.eclipse.core.filesystem bundle is missing from the classpath. Therefore, the resolution fails, and as a fallback, we just try to match the simple name (the guess being that the import could be wrong). Deepak, could that explain the difference in comment 1 (i.e. do you have org.eclipse.core.resources in source in your 4.2 workspace or did the plug-in from which you opened WorkspaceRoot also require org.eclipse.core.filesystem)? (In reply to comment #5) Ha! That explains what Ayush and I were observing yesterday. > Deepak, could that explain the difference in comment 1 (i.e. do you have > org.eclipse.core.resources in source in your 4.2 workspace or did the plug-in > from which you opened WorkspaceRoot also require org.eclipse.core.filesystem)? I do not have org.eclipse.core.resources in source. WorkspaceRoot is opened from 'External Plug-in Libraries' which obviously has org.eclipse.core.filesystem as well :-) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |