Community
Participate
Working Groups
I20050919 Compiler should provide support for null reference analysis, coupled with use of @NonNull annotation.
See also bug 96063
Created attachment 30700 [details] Null checks stage1: provides checks upon locals. No way to selectively suppress the warnings yet. User preferences should include the following line to get the warnings activated within Eclipse: org.eclipse.jdt.core.compiler.problem.nullReference=warning Batch compiler added a new warning toggle option, which name is 'null'.
*** Bug 80252 has been marked as a duplicate of this bug. ***
Created attachment 33507 [details] Experimental version for checks upon locals Released as v_634a. May have to roll back depending on the results of an experimentation run within the team.
Created attachment 33699 [details] Patch to change the behavior on second error - applies to v_634a Following a remark from Frédéric about the fact that the warning on line 2 below was annoying, prototyped a version in which in case of error in a test against null, the null status of a variable is no more changed. if (strings != null) { int length = strings == null ? 0 : strings.length; // 1 - complain for (int i = 0; i < length; i++) { System.out.println(strings[i]); // 2 - used to complain } } By the new behavior, we complain on line 1 and no more modify strings status, which means that it remains known as being non null (and 2 is OK). This changes quite a few test cases diagnostics, which can be seen in the patch. But this only affects second and following situations (never the first diagnostic for a given variable) and the results seem rather OK. Feedback will be appreciated.
Committed a couple of cleanup changes in preparation for integration build of tomorrow. Did not release the suggestion of comment #5. Feedback welcome.
I understand that this request may go over the aim of analyzing local variables, but here it comes anyway: A frequent pattern is to rely on methods throwing an exception if a null check fails, but this is not recognized by the analysis; the following code triggers a warning: void m(Object o) { Assert.isNotNull(o); o.toString(); // warning } To solve this, the analysis would have to find out under what circumstances the exception is thrown...
(In reply to comment #7) Thanks for your feedback. What is due to stretch what we've done so far quite a bit indeed. This is part of inter procedural analysis, for which we may consider a separate effort. Moreover, this calls for something we had not thought much about yet: tell the system that a given method warranties that one of its operands is non null or else the normal control flow gets broken (here it is an exception, but it could be a call to System#exit). Would you please file a separate bug?
(In reply to comment #8) > Would you please file a separate bug? Bug 126551
(In reply to comment #9) > (In reply to comment #8) > > Would you please file a separate bug? > > Bug 126551 > thx
Released in HEAD. NullReferenceTest provides lots of examples of the feature behavior.
The following paper might be relevant for this bug: P. Chalin and F. Rioux, "Non-null References by Default in the Java Modeling Language." Can be downloaded at: http://www.cs.concordia.ca/~chalin/main.html The authors argue (correctly, I think) that by default, one should assume that a method argument is meant to *not* be null. If not, you tag it (say, with @AllowNull). This would be the opposite of how the suggested @NonNull annotation would be used.
this paper seems even more relevant (no JML): www.cs.umd.edu/~jspacco/marmoset/papers/hovemeyer-paste2005.pdf this last one is also on the subject: research.microsoft.com/~leino/papers/krml109.pdf
(repeating for easier clicking) this paper seems even more relevant (no JML): http://www.cs.umd.edu/~jspacco/marmoset/papers/hovemeyer-paste2005.pdf this last one is also on the subject: http://research.microsoft.com/~leino/papers/krml109.pdf
Thanks for the input. I suggest that further comments regarding null reference analysis be added to one of the following bugs, or to new ones if appropriate: bug 126551: [compiler] null reference analysis: add interprocedural analysis bug 96063: [compiler] Null pointer analysis needed in autoboxing/autounboxing bug 123399: [compiler] missing null ref warning upon specific if/do while case bug 127244: [compiler] Null reference analysis doesn't understand assertions
Verified for 3.2 M5 using build I20060214-0010
Is this the right bug report to lobby for a @NotNull annotation? If not, please excuse my bold attempt to comment a "fixed" bug. IDEA has recently introduced @NotNull and @Nullable annotations which come quite handy as the help to fix the "static" type system of Java and help to combat NPEs. While the solution is not perfect, it adds value and it would be nice, if Eclipse would also recognise the same annotation because that would help to make code more portable between IDEs. See http://www.jetbrains.com/idea/documentation/howto.html for details on the semantics of IDEAs annotations.
(In reply to comment #17) > Is this the right bug report to lobby for a @NotNull annotation? I would suggest that you use https://bugs.eclipse.org/bugs/show_bug.cgi?id=126551 instead.
*** Bug 107804 has been marked as a duplicate of this bug. ***
