Community
Participate
Working Groups
From bug 110030 comment 6: A) A method or statement 'certifies' a reference' null state A frequent pattern when dealing with references is to rely on methods throwing an exception if a null check fails. Null reference analysis could try to find out that the reference to 'o' is not null in the following example: void m(Object o) { Assert.isNotNull(o); o.toString(); // warning } -- B) the return value of a method is known to be non-null Another pattern is to have a method that returns a value that is guaranteed to be non null: void m(Object o) { o= objectOrDummy(o); o.toString(); } Object objectOrDummy() { if (o == null) return new NullObject(); return o; }
If not doing a full features analysis, it might be a suficient hack to simply know that a few method will throw exceptions or otherwise will never return, e.g. junit.framework.Assert.fail() java.lang.System.exit() Especially for unit tests, it might be a good idea if the analyser simply knows the semantics of junit assert methods because that is kind-of an industry standard.
*** Bug 127575 has been marked as a duplicate of this bug. ***
Implementing this without an annotation mechanism similar to @NotNull / @Nullable may be hard, as you have to perform arbitrarily complex flow analysis... Annotations would allow to keep the analysis local.
Maybe we can at least add @NotNull and @Nullable (for compatibility with IDEA) and starting dealing with the easiest cases?
*** Bug 154191 has been marked as a duplicate of this bug. ***
Philippe, I believe we need to discuss what we want to do here.
Interprocedural analysis belongs to static analysis, not to compiler. If information was available from annotations etc... then we could improve our analysis, but we would never consider going interprocedural (simply using better input from message/field expressions, rather than unknown).
WONTFIX then.
