Bugzilla – Full Text Bug Listing
| Summary: | Classpath ordering not respected with duplicate types in JRE and source | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | mirko, philippe_mulet |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
All source in your source folders wins over any .class file on your classpath. I doubt we will ever change this. It's not that I would see a real use in such a setup; I just found it strange that Open Declaration and the hovers tell a different story than the compiler. Frankly, I don't care too much whether this will be fxed or not, unless it is a regression (I didn't check). From comment #1, I would take that we won't change that ever (Philippe?). Then, shouldn't we repurpose the bug at handling the discrepancy raised in comment #2? (Checked a recent build, and F3 does point the user to the JRE if it's before the sources in the classpath, and to the source Enumeration else. This is wrong if F3's meaning is to point the user to the type used by the invocation site.) Pls decide. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |
I20050610-1757 (3.1RC2) - new workspace, import plug-in org.junit as source - change classpath ordering such that the JRE is the first entry; .classpath: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="src-junit"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="output" path="bin"/> </classpath> - add cu /org.junit/src-junit/java/util/Enumeration.java: package java.util; public interface Enumeration { // boolean hasMoreElements(); // no questions! Object nextElement(); } => The compiler reports errors on references to Enumeration#hasMoreElements(): "The method hasMoreElements() is undefined for the type Enumeration". I would expect that my Enumeration.java is not consulted, since the version from the JRE wins the classpath race. Interestingly, when I hover over references to Enumeration in the editor, I get the javadoc from the JRE version. Also, Open Declaration (F3) jumps to the JRE version, even from error-marked class to hasMoreElements().