Community
Participate
Working Groups
On the following test case, javac 6, 7 and ourselves all generate code that will yield an NPE on line 8, which is a pity since a better indication of the problem would be line 11 (the one where the 'faulty' dot stands): public class X { X next; X (X next) { this.next = next; } public static void main(String args[]) { X x = new X(new X(new X(null))); x. // line 8 next. next. next. next. next. toString(); } } Interestingly enough, on the following variant, we get the NPE on line 14, while javac 6 and 7 stubbornly keep line 8: public class X { X next; X (X next) { this.next = next; } public static void main(String args[]) { X x = new X(new X(new X(null))); x. next. next. next. // next. // next. toString(); // line 14 } }
Now I fail on line 12, not 11 though. The field on line 11 is null, but the access is failing only in line 12 when the field is accessed. Does this look better?
The cascading field reference case is also wrong. public class X { X x; X next; X (X next) { this.next = next; } public static void main(String args[]) { X x = new X(new X(new X(null))); x.x = x; x.foo(); } public void foo() { this. x. next. next. next. next. next. toString(); } } Since the field references are sharing the source start, we must use the source end position. Fix under testing.
(In reply to comment #1) > Now I fail on line 12, not 11 though. > The field on line 11 is null, but the access is failing only in line 12 when > the field is accessed. > Does this look better? > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, the line of the first selector that follows it is OK as well, or the line of the selector that yields the null value (better?), provided that we are consistent and the user can rely on us to be consistent (then a test on a simple case will give her a clue of what to expect).
(In reply to comment #3) > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, I disagree. The dot itself means nothing. It is the subsequent field access that will fail. If you write your test case: x .next .next .... I would expect the same line to be returned. I have one last issue to solve before I can release the fix.
Released for 3.3M6.
(In reply to comment #4) > (In reply to comment #3) > > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, > I disagree. The dot itself means nothing. It is the subsequent field access > that will fail. The dot is the common part of the syntax for dereference, for multiple uses (field access and method call). This may not be the best candidate, but it means at least that.
Verified for 3.3 M6 using build I20070320-0010
