2

I use @NonNull-Checking with Eclipse-JDT and was very pleased to see that it understands and respects the use of Apache Commons Validate. Which means in code:

Validate.notNull(someInput);
@NonNull String a = someInput;

Without the first line the second one produces a warning in Eclipse. I can only configure if "assert" should be respected. But without any further notice it also respects Validate#notNull and Objects#requireNonNull. This is great but I wonder:

  1. Is it hardcoded or configurable (in some plugin, file,...) which frameworks/methods Eclipse respects for proper Null-Checking?
  2. Can I write my own methods to let Eclipse know, some variable is guaranteed to be non-null?
groovedigga
  • 233
  • 3
  • 13

1 Answers1

3

The list is hard coded and can't be extended (other than by modifying the source code).

Some of the main classes involved as in org.eclipse.jdt.internal.compiler.lookup and org.eclipse.jdt.internal.compiler.ast including the TypeConstants and TypeIds interfaces and the ReferenceBinding and MessageSend classes.

greg-449
  • 109,219
  • 232
  • 102
  • 145
  • Thx. I didn't find documentation about this. Is there a full list of the supported frameworks/methods? – groovedigga Aug 02 '18 at 14:41
  • I don't know of a list, you can work it out by looking at the source code but that is also difficult to read. – greg-449 Aug 02 '18 at 15:08
  • 2
    @greg-449 well researched. Let me just add a link to the bug via which most of this was added: https://bugs.eclipse.org/382069#c6 . I admit, though, that this is not proper documentation ... – Stephan Herrmann Aug 02 '18 at 21:54
  • @StephanHerrmann Its a shame this is hardcoded. I realize doing the real analysis would be too expensive but perhaps an extensions of the EEA format would allow quick analysis. For example: Right now its 0 = Nullable and 1 = NonNull. What could be added is 4 more types: 2 for nullable/nonnull void like methods and 2 for nullable/nonnull for boolean like methods. – Adam Gent May 04 '21 at 12:59
  • 1
    @AdamGent, Your idea goes beyond the aim of **external** annotations, we would first need to define additional annotation types for specifying different (null-)contracts. Feel free to file an RFE in bugzilla. Once a new annotation is specified, representing it in EEA would be straight-forward. Unfortunately, experience tells that specifying new annotations with agreement of all parties involved is a hard nut to crack. E.g. see that `@LazyNonNull` has been proposed long ago, and still we don't have strong agreement that this would be a worthwhile addition. – Stephan Herrmann May 04 '21 at 13:54