Bugzilla – Full Text Bug Listing
| Summary: | Invalid 'class cannot be resolved' markers when referencing a class named differently then the .java file it is in | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Andrew Clark <andrewc> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.1.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
Isn't it spec'd that the filename has to be the same as the class name? Moving to JDT/Core for comments/closure. This is a known issue in the JavaModel which doesn't handle secondary types properly. It isn't simple to fix, and the best approach is to have the file name and the type name match exactly. A public class must be declared in a file with the same name, but the same
restriction does not exist for private or package-level classes. The Java
language specification does say in 7.6:
"When packages are stored in a file system (§7.2.1), the host system may choose
to enforce the restriction that it is a compile-time error if a type is not
found in a file under a name composed of the type name plus an extension (such
as .java or .jav) if either of the following is true:
The type is referred to by code in other compilation units of the package in
which the type is declared.
The type is declared public (and therefore is potentially accessible from code
in other packages). "
In this case the first restriction is true, but this is only optional. The
specification also says:
"When packages are stored in a database (§7.2.2), the host system must not
impose such restrictions. "
But in 6.6.4, it also says this:
"6.6.4 Example: Access to public and Non-public Classes
If a class lacks the public modifier, access to the class declaration is
limited to the package in which it is declared (§6.6). In the example:
package points;
public class Point {
public int x, y;
public void move(int dx, int dy) { x += dx; y += dy; }
}
class PointList {
Point next, prev;
}
two classes are declared in the compilation unit. The class Point is available
outside the package points, while the class PointList is available for access
only within the package. "
...which implies that their example is valid and allows access to multiple
classes within the same .java file. Regardless, isn't it inconsistent that the
compiler itself works and creates valid byte-code but the lines of code are
being flagged as invalid?
As I said in comment #2, it is a known bug in our Java model which incorrectly reports a mistake though the code (and our compiler agrees too as you noticed) is correct. *** This bug has been marked as a duplicate of 36032 *** |
Invalid 'class cannot be resolved' markers (those red x's in the margin next to the source) appear when referencing a package-level class named differently then the .java file it is in. For example, this class in class1.java: package com.asc.bug; class Class_1 { boolean getTrue() { return true; } } cannot be found when a class in a different .java file references it: class Class2 extends Class_1 { // Class_1 is underlined and flagged as an error ... } Otherwise, the code runs correctly, can be debugged, no errors appear in the 'Task' view, and no red x's appear in any of the other perspectives (e.g. the 'Members' view in the 'Java browing perspective'). If the file name is renamed so that it is the same as the class (class_1.java), then everything seems to work fine. If it matters, I am using WDSc Advanced Edition for iSeries 5.1 which appears to be built on top of the 2.1.1 Eclipse tooling.