Handling of (@NotNul param1, ...) at Runtime

Hello,

I noticed that Demetra seems to enforse @NotNull annotation for method call
parameters at run time. Is it correct? If it is, how and at what point it it
is done? Is it done by IDEA compiler? If so how to do it outside of IDEA?

Do you think is it a good idea to completely rely on annotations and stop
checking parameters for Null?
When doing both @NotNull and explicit checking for null inside methods I get
bunch of annoying warnings "Condition abc == null is always false". Well it
but I am kind of uneasy about removing explicit null checks from my code.

What's your opinion?

Thanks

Alex


14 comments
Comment actions Permalink

The checks are indeed inserted by IDEA after compiling classes. This feature is controlled in compiler settings page. Outside of IDEA javac2 task we provide also inserts these checks.

As for warnings, they are issued regardless of instrumentation, it is a part of @NotNull contract, the instrumentation is aimed to just verify that contract.

0
Comment actions Permalink

Thank you Eugene!

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

The checks are indeed inserted by IDEA after compiling classes. This
feature is controlled in compiler settings page. Outside of IDEA javac2
task we provide also inserts these checks.

>

As for warnings, they are issued regardless of instrumentation, it is a
part of @NotNull contract, the instrumentation is aimed to just verify
that contract.



0
Comment actions Permalink


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

The checks are indeed inserted by IDEA after compiling classes. This
feature is controlled in compiler settings page. Outside of IDEA javac2
task we provide also inserts these checks.

>

As for warnings, they are issued regardless of instrumentation, it is a
part of @NotNull contract, the instrumentation is aimed to just verify
that contract.



0
Comment actions Permalink

You should also note that you can turn off the @NotNull instrumentation in the Settings/Compiler page. I only turn on the @NotNull checks for debugging, since I know I'm not going to ship with them on and want to keep my normal testing as close to production as possible.

--Dave Griffith

0
Comment actions Permalink

On the other hand, IDEA itself is shipped with checks on in EAP, and it does not seem to slow it.

0
Comment actions Permalink

Eugene Vigdorchik wrote:

On the other hand, IDEA itself is shipped with checks on in EAP, and it does not seem to slow it.


I'll take the chance again to propose to make the checks work and behave like
assert statements, i.e. to make them dependent on the -ea JVM switch and throw
AssertionErrors instead of IllegalArgumentExceptions. That way one has control
over any potential runtime-overhead and this would make it more obvious that the
checks are a feature one should not rely on as they may not be present at all
when using a different compiler.

Sascha

0
Comment actions Permalink

It's not a question of speed, but rather of having something other than javac in our build cycle. Management's a bit too conservative for that yet.

--Dave Griffith

0
Comment actions Permalink

Nope, this is not javac dependent, I personally use Eclipse for compilation with @NotNull instrumentation turned on.

0
Comment actions Permalink

Hello Eugene,

Yet, one has to use javac2 task of JetBrains to get runtime checks in production.
That's a problem.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Nope, this is not javac dependent, I personally use Eclipse for
compilation with @NotNull instrumentation turned on.



0
Comment actions Permalink

Nope, this is not javac dependent, I personally use
Eclipse for compilation with @NotNull instrumentation
turned on.


I think what dave meant here is that you can't use @NotNull instrumentation with javac only, and adding an extra step to his deployment process is a no-no.

0
Comment actions Permalink

Exactly.

OTOH, it's an utterly bitchin' debugging tool, even if I can't deploy with it, so I'm certainly not complaining.

--Dave Griffith

0
Comment actions Permalink

David,

If you use it for debugging primarily, I assume you do your own null checks
in method calls. Does it bother you that all such checks are marker as
warning because @NotNull make them redundant? It bothers me very much
because they pollute my error/warning bar with meaningless warnings
"Condition abc == null is always false".

Is there any way solve this issue?

Given "optional" nature of static null analysis and a possibility that the
code will be used without javac2 enhancement, I just can't convince myself
to give up explicit null checks.

Thanks

Alex


"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:813009.1148928728533.JavaMail.itn@is.intellij.net...

Exactly.

>

OTOH, it's an utterly bitchin' debugging tool, even if I can't deploy with
it, so I'm certainly not complaining.

>

--Dave Griffith



0
Comment actions Permalink

Yup, a very accurate summation of my current state. Some way of suppressing those warnings would be very handy.

--Dave Griffith

0
Comment actions Permalink

Dave Griffith <dave.griffith@cnn.com> wrote:

Yup, a very accurate summation of my current state. Some way of
suppressing those warnings would be very handy.


Or to use other words: some way to suppress the warning for that part of
the code that is meant to enforce this contract in production mode. That
is for the

if (xy == null) throw new IllegalArgumentException();

part at the beginning of a method.

Best,

Dirk Dittert

0

Please sign in to leave a comment.