Java @Nullable annotations in generated classes

[roded]

We use Checkerframework to ensure a project's null-safety.

In our case, this is done by assuming that all fields and parameters are annotated by @NotNull implicitly while nullable fields and parameters are explicitly annotated by a @Nullable annotations.

The generated Kaitai classes do have some nullable constructor parameters which fail the null-safty check in a project in which Checkerframework is enabled.

It would be nice to be able to instruct Kaitai to add a (customizable) @Nullable annotation where appropriate.

[GreyCat]

Unless I'm missing something, nullable was never standardized in Java? JSR305 was shot down, and then we've never got any official support for these anywhere in vendor-provided Java classes?

If that's true, this complicates generation of such annotations quite a bit — i.e. instead of following one standard (which will still probably need at less on/off flag), we'll need to support X different ways, e.g.:

• from org.jetbrains.annotations
• from org.eclipse.jdt.annotation
• from lombok
• from org.checkframework
• etc, maybe some more?

[GreyCat]

Searching GitHub for all Nullable in Java, we can find that there are ~3.2M files using it. We can also explore how popular are specific implementations:

Implementation	GH hits
javax.annotation.Nullable	1.1M
org.jetbrains.annotations.Nullable	922k
androidx.annotation.Nullable	481k
android.support.annotation.Nullable	416k
org.springframework.lang.Nullable	159k
org.eclipse.jdt.annotation.Nullable	62.5k
com.sun.istack.internal.Nullable	3.9k
others	55.6k

[roded]

Yeah, what libraries usually do is allow configuring what annotation class to use as a nullable annotation. That way we, for example, could specify org.jetbrains.annotations.Nullable since that's what our Checkerframework configuration is configured for. Thanks for considering this.

[GreyCat]

Overall, sounds good then. We could add something like --java-nullable-class=... argument to CLI. The main challenge will be likely adding tests that prove that it works. Maybe something akin to what we do with C++ and valgrind — i.e. after the execution of tests runs, we add extra pass of static checking tool (?) which generates some kind of result which we interpret to add extra result statuses in our CI?

[generalmimon]

@GreyCat:

We could add something like --java-nullable-class=... argument to CLI.

I agree, although calling it "class" seems a bit technically inaccurate (apparently, the correct Java term is "annotation type"). I'd rather call it --java-nullable-annotation.

[GreyCat]

Ok, so the action plan roughly seems like is:

• Compiler code:
  • Add --java-nullable-annotation CLI argument parsing
  • Inject @Nullable and/or @NotNull annotations when this is activated in code generated for Java
• Testing code:
  • Pick some classes implementing Nullable/NotNull
  • Adjust tests CI to fetch these new dependencies
  • Adjust builds-formats to pass new CLI arguments to compiler to force generation of dependencies (probably we can get away with always having them enabled)
  • Add a testing pass for Java only (akin to C++ Valgrind) that will execute static checker on top of regular Java code.
  • Adjust test aggregation to have parser for static checker (akin to Valgrind XML parser) and make sure it signals which tests are broken this way

@roded Do you think you'll be interested in contributing any of these?

[roded]

@GreyCat Theoretically I'd be glad to. But I'm swamped for the next few months and I don't think I'll be able to find the time to contribute unfortunately. So long as this does not pick up more votes, feel free to keep this open till I do though.
Thanks for the attention on this.