Community
Participate
Working Groups
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.
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 ***
