Community
Participate
Working Groups
When using Spring's Assert to handle invalid arguments, I'm getting "Potential null pointer access" afterwards. "Null check" is given as an argument, it's not in "if" condition anywhere. Example: public void isEmpty(Object arg) { Assert.notNull(arg != null, "Invalid parameter."); System.out.println(arg.hashCode() > 0); // <-- getting warn here for "arg" }
We have support to recognize a few utility methods as asserts. Apparently, nobody brought the Spring assert to our attention when we implemented that. See bug 382069 for a list of supported assert facilities. To get support for Spring's Assert please specify the qualified class name, and all methods that you think should be considered by null analysis, along with a description of the underlying contract. Thanks. BTW: to explain why you are getting the warning: when the flow analysis sees the expression "arg != null", it recognizes that the developer wasn't 100% sure about the nullness of 'arg', hence it assumes that past this point dereference without check is unsafe.
Seems this is completely invalid. That Assert is called in wrong way, unfortunately I picked up an existing example written be someone else. It should be Assert.notNull(arg, "..."); In fact, spring's assert is org.springframework.util.Assert.notNull to be considered as runtime null validator.
(In reply to Marton Dinnyes from comment #2) > Seems this is completely invalid. > > That Assert is called in wrong way, unfortunately I picked up an existing > example written be someone else. It should be Assert.notNull(arg, "..."); n.p. thanks for the update. > In fact, spring's assert is org.springframework.util.Assert.notNull to be > considered as runtime null validator. Since I don't have spring installed: please provide the exact signature that should be recognized by the compiler. Is it just this one method or are there more methods like this? Also a link to their Javadoc would help.
Object MUST be null: org.springframework.util.Assert.isNull(Object) org.springframework.util.Assert.isNull(Object, String) http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/util/Assert.html#isNull(java.lang.Object) http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/util/Assert.html#isNull(java.lang.Object, java.lang.String) Object MUST NOT be null: org.springframework.util.Assert.notNull(Object) org.springframework.util.Assert.notNull(Object, String) http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/util/Assert.html#notNull(java.lang.Object) http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/util/Assert.html#notNull(java.lang.Object, java.lang.String) These are links to 3.2.x javadoc, however it hasn't changed ever, and also the same in 4.x.
You might also want to consider covering guava's com.google.common.base.Preconditions Example, in checkArgument(boolean expression) people tend to state Preconditions.checkArgument(arg != null); // <-- throws exception if false (instead of using .checkNotNull) So after a line like this, arg will not be null.
Thanks for the references. com.google.common.base.Preconditions is already covered as per the bug I mentioned earlier. Note that any changes we are discussing now will be scheduled for 4.5.
Would it be possible to make a configuration page to cover these kind of checks on user side? There might be other libraries offering these kind of checks which are not even public (I am facing this right now). I should be able to give a list of static methods which would be considered in null check analysis.
(In reply to Marton Dinnyes from comment #7) > Would it be possible to make a configuration page to cover these kind of > checks on user side? There might be other libraries offering these kind of > checks which are not even public (I am facing this right now). > > I should be able to give a list of static methods which would be considered > in null check analysis. The compiler can only consider s.t. of which it "knows" the exact semantics. If you say you have some similar methods in a library, who will ensure that those have the exact same meaning as the utilities we have examined and added to the analysis? If there's a subtle difference, it's the compiler that will get blamed for "wrong" or "missing" warnings. Hm ... OTOH, after the advent of java.util.Objects.requireNonNull, i.e., a solution that is standard and available to everyone, do we really need to support gazillion of "identical" methods?
Ran out of time for 4.5, sorry.
Too much on my plate for 4.6. Bulk deferral to 4.7
Ran out of time for 4.7. Bulk move to 4.8.
bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
