Community
Participate
Working Groups
2.1.0-RC3 200303192032; problem persists from earlier builds. public class Flitsch { public static float BRATSCH = 42; public static class BRATSCH { } public Object o; public void sozzle() { Flitsch.BRATSCH = 43; Flitsch.BRATSCH b = (Flitsch.BRATSCH)o; } } In this code, the cast will be squiggled with the message "Flitsch.BRATSCH cannot be resolved." None of the other occurrences of Flitsch.BRATSCH will be squiggled, so the compiler is able to disambiguate the type from the field in other contexts, but not in a CastExpression. javac accepts the code. JLS section 6.5.1 provides: A name is syntactically classified as a TypeName in these contexts: ... As the type mentioned in the cast operator of a cast expression (15.16) ... Interestingly, if the unqualified typename is used in the cast, Flitsch.BRATSCH b = (BRATSCH)o, it is accepted. Only the qualified form gives trouble.
Reproduced. Indeed, this is a bug.
Created attachment 4278 [details] patch for BlockScope
Kent - pls verify patch
In this particular case, a workaround is to not qualify, however in general, when accessing from some external code, this isn't possible. However, this isn't a new bug.
Not critical for 2.1
Thanks for the quick patch! I'll give it a try. I'm not sure I understand the last couple of comments. If this is not a new bug, is it an old bug? I did search first, but I didn't find it. Sorry if I missed it. As you point out, the workaround of using an unqualified name is not feasible in the general case. Also, as you would guess, the problem is most likely to be apparent in generated code, where the member names are constrained by some external design requirement; otherwise one would just use different names and never see the problem. That means in the practical situations where this bug is likely to bite, there may be no really practical workaround--one that doesn't require redesign of a code generator and a number of related components.
By old bug, I meant it isn't a recent regression but rather a long standing bug. I agree this isn't trivial to workaround, but since we are in strict release mode (see Eclipse end game plan), only stop ship bugs are to be addressed at this stage. Such a collision scenario isn't very frequent to make it critical (we had it wrong in 2.0 as well, and nobody noticed until today).
Patch looks good.
Defer
Reopening
Fixed
Backported to 2.1 maintenance stream.
Fixed in 2.2 stream as well.
Verified.
Verified in 3.0M1
