I've started adding nullability checks to the packages in org.eclipse.jdt.core related to the new indexer.
Specifically, I turned on nullability checking in the JDT core project settings, added @NonNullByDefault to the package settings of the packages I was messing with, and added @Nullable annotations where appropriate.
All good so far.
However, at this point I hit a few stumbling blocks and I was curious about how we should address them.
1. Where should the external annotations for the JDK live in the short-term?
2. How should we suppress the errors and warnings in packages/classes that haven't been updated yet?
3. What should our policy be for dependencies on other Eclipse plugins that haven't been annotated yet?
Item 1: Where should the annotations live?
Okay, so long-term we probably want to crowd-source the external annotations for common libraries like the JDK and install them automatically... but I'm not talking about that here. In the short-term, we need a place to put enough external annotations for the JDK such that we can compile JDT core without warnings. It should probably be a common location so that all the JDT core plugins can refer to it.
Suggestion:
- Create a new (non-java) project in the JDT core git repository to hold the external annotations for all the other JDT core projects.
- Call it org.eclipse.jdt.extannotations
- Give it top-level subfolders for "jre" and any other libraries we depend on.
- In every JDT core project, the classpath entry for the JRE system library will refer to the workspace path /org.eclipse.jdt.extannotations/jre for its external annotations.
Item 2: How to suppress the extra errors
Unfortunately, you can only turn on nullability testing for an entire project even though we probably only want to do the adoption for individual packages one-at-a-time. How can we suppress the errors in packages that haven't been updated yet?
Option 1:
- Is there any equivalent to @SuppressWarnings that works for an entire package? If so, we could turn on nullability testing, suppress the warnings for all packages that haven't been updated yet, and remove the suppression from each package as we do the update.
Option 2:
- Disable nullability testing in projects that haven't been fully adopted yet but still adopt the @Nullable annotations where possible. Developers working on packages that have the @NonNullByDefault annotation can enable nullability testing locally.
Option 3:
- Update our nullability tester such that it only reports errors + warnings in packages and classes that use the @NonNullByDefault annotation, and doesn't create extra errors or warnings elsewhere.
Personally, I like option 3 if it's not too hard.
Item 3: Dealing with non-annotated Eclipse dependencies
For example, JDT core depends on IProgressMonitor, which hasn't been annotated yet. This is also going to be a problem for other Eclipse plugins that depend on other non-annotated plugins.
Option 1: Add external annotations for the non-annotated Eclipse dependencies just as we would for the JDK.
Option 2: Contribute patches that annotate the dependencies and temporarily live with or suppress the warnings until those patches are accepted.
Option 3: Suppress the nullability errors caused by non-annotated dependencies.
What does everyone think? Are there any objections if I get started on this?
- Stefan
