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

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.

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.

"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.

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

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

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

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

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

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.

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.

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

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

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

--Dave Griffith

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