Re: [jdt-dev] Null pointers in the java compiler

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

JDT core has different null policies in different parts, even within the compiler.

For AST classes null simply means: an optional element is missing.

For binding classes (package ../lookup) we have
- explicit empty arrays Binding.NO_TYPES etc
- MissingTypeBinding to signal a necessary type could not be resolved
- Problem*Binding to signal various semantic problems (with details in #problemReason)
If despite these explicit encodings of empty collections and errors a binding field
is found to be null where it shouldn't, this typically means that an expected phase
of compilation hasn't happened where it is assumed to have happened already.
I.e., an NPE regarding a field of some binding type is typically the symptom
of a bug that happened earlier.

Such problems may happen during compilation proper, but since that scenario is
executed more than anything else, most bugs here have been reported and fixed.
Unfortunately, annotation processing may interact with the compiler in ways
that influence the processing order. At least that's the typical APT-related
NPE from my experience.
I don't see where additional null sentinels could help. Even the initialization
state of various objects is systematically recorded, e.g., using a ton of bits
from TagBits.
Interestingly, in a few cases org.eclipse.jdt.annotation.Nullable isn't the
solution but it's the cause of the problem ;P, because evaluating these annotations
in the compiler is one stakeholder fiddling with processing order that may get
in conflict with other stakeholders (like APT).

To sum up: for this class of bugs, all it needs is:
- a reproducing example
- Jay and (Sasi or me) sitting down together to figure out the interaction between
  annotation processing and compilation proper

If you want to help, I hope the classification above helps a bit. Otherwise
ping us in the bug you are looking at, telling your findings, and we may be
able to give more specific hints for debugging.

It would be interesting to know, if there are other fields (not of a binding type)
that cause similar grief wrt APT.

best,
Stephan

On 10/18/2015 05:02 AM, Stefan Xenos wrote:
> A lot of the APT-related bugs I've been looking into are NPEs in the Java compiler. These can be tricky to investigate because it's
> not immediately clear (to me at least) what a null value means for a particular field or why the field was null in a given
> circumstance. It's also hard to distinguish a field which was not present due to - say - a parsing error versus a field which is not
> present due to a programming error in initialization.
>
> Anyone know any good techniques for debugging these?
>
> CDT seems to be using a pattern which may help here. Instead of using null to indicate a problem (an intentionally-omitted field),
> they insert a non-null sentinel value containing metadata describing the nature of the problem. So if one of these sentinels shows
> up in an unexpected place, it offers some insight into the reason for the field being omitted... and it also disambiguates parsing
> errors (non-null sentinels) from initialization bugs in the parser (null).
>
> I'm not suggesting that this be adopted everywhere (which would be a crazy amount of work), but was more curious about what the JDT
> community felt about the pattern in general. Would patches which adopt this pattern in known problem cases be useful? Well received?
>
> What about the use of org.eclipse.jdt.annotation.Nullable and Nonnull? Would it be helpful for me to add these annotations in
> locations (in jdt.core) where I've been able to infer the intended contract?
>
>    - Stefan
>
>
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-dev