@Nullable Inspection. Is it possible to improve?

One problem with @Nullable inspection is unwanted warning on nullable
getters. I understand of course that from analysis standpoint

@Nullable getPerson() {
return _person;
}

if (getPerson() != null) {
getPerson().getName();
}

should produce NPE warning since _person is not final and potentially can be
change between if statement and getName() call

I wonder if it is possible to doo deeper analysis to recognize that _person
does not change in this call block and avoid useless warning on getName()
call

If it is npt practical, I wonder if we could have some sort additional
annotations helping you to do partial analysis of this case and declare it
safe?
For example annotate setPerson() as the only place which changes _person so
your analysys do not have to chak for all possible places mutating _person


5 comments
Comment actions Permalink

Even if setPerson() is the only place that mutates _person, how can IDEA be sure that another thread will not call setPerson(null) in between those two getPerson() calls?

0
Comment actions Permalink

Well, for a case you give there is a simple condition sufficient for notnullness, i.e. calling method second time produces the same result. This condition could be marked with annotation, and also it could be sometimes inferred, for example when you return a field and do not assign to it in the subject method.
However in general case when two calls are separated by a call to another method things are not so simple, and so the system for expressing the intent would become complex not worth the efforts. Note also that notnull analysis does not take multithreading into considreation.

Eugene.

0
Comment actions Permalink

Eugene,

Even just this simple scenario would be a great help if it can be inferred.
If a bit more complex (where condition includes other calls) would be even
better.
But if inferrence is not possible I wonder if it could be a good idea (and
if it is possible at all) to add some annotation parameter to tell idea that
I guarantee that there will be no change to return of the method from first
method call to the second one (no idea how to do it for specific points)

Thanks

Alex


"Eugene Vigdorchik" <no_reply@jetbrains.com> wrote in message
news:22477150.1186296409308.JavaMail.itn@is.intellij.net...

Well, for a case you give there is a simple condition sufficient for
notnullness, i.e. calling method second time produces the same result.
This condition could be marked with annotation, and also it could be
sometimes inferred, for example when you return a field and do not assign
to it in the subject method.
However in general case when two calls are separated by a call to another
method things are not so simple, and so the system for expressing the
intent would become complex not worth the efforts. Note also that notnull
analysis does not take multithreading into considreation.

>

Eugene.



0
Comment actions Permalink

Of course the way to avoid this inspection triggering is to cache the
result of getPerson() out into a local variable in your code... Is there
a reason that this is not a sufficient solution?

N.

Alex Roytman wrote:

One problem with @Nullable inspection is unwanted warning on nullable
getters. I understand of course that from analysis standpoint

@Nullable getPerson() {
return _person;
}

if (getPerson() != null) {
getPerson().getName();
}

should produce NPE warning since _person is not final and potentially can be
change between if statement and getName() call

I wonder if it is possible to doo deeper analysis to recognize that _person
does not change in this call block and avoid useless warning on getName()
call

If it is npt practical, I wonder if we could have some sort additional
annotations helping you to do partial analysis of this case and declare it
safe?
For example annotate setPerson() as the only place which changes _person so
your analysys do not have to chak for all possible places mutating _person

0
Comment actions Permalink

that's what I am doing now but it introduces good deal of local variables
when I do not really need them and bloats code a good deal. One particular
which made me post here was a decorator class delegating to nullable
getSubject() using getSubject() == null ? .... It was marked all ower of
course and I really did not feel like extracting local variable in every
getter I had there


"Nathan Brown" <nedski@yNaOhSoPo.cAoMm> wrote in message
news:f96q1r$bgd$1@is.intellij.net...

Of course the way to avoid this inspection triggering is to cache the
result of getPerson() out into a local variable in your code... Is there a
reason that this is not a sufficient solution?

>

N.

>

Alex Roytman wrote:

>> One problem with @Nullable inspection is unwanted warning on nullable
>> getters. I understand of course that from analysis standpoint
>>
>> @Nullable getPerson() {
>> return _person;
>> }
>>
>> if (getPerson() != null) {
>> getPerson().getName();
>> }
>>
>> should produce NPE warning since _person is not final and potentially can
>> be change between if statement and getName() call
>>
>> I wonder if it is possible to doo deeper analysis to recognize that
>> _person does not change in this call block and avoid useless warning on
>> getName() call
>>
>> If it is npt practical, I wonder if we could have some sort additional
>> annotations helping you to do partial analysis of this case and declare
>> it safe?
>> For example annotate setPerson() as the only place which changes _person
>> so your analysys do not have to chak for all possible places mutating
>> _person


0

Please sign in to leave a comment.