Hack NullAway LibraryModels generator MVP POC

[vorburger]

The goal of this issue would be to explore hacking a converter from annotated Java sources to a NullAway LibraryModels generator MVP POC.

Use case / application would be for / driven by enola-dev/enola#845 (and possibly also using NullAway e.g. for my https://github.com/vorburger/ch.vorburger.exec or https://github.com/vorburger/ch.vorburger.fswatch or https://github.com/MariaDB4j/MariaDB4j).

Approach/steps planned would be to:

• Add NullAway to some of my projects, in increasing order of complexity:
  • https://github.com/vorburger/ch.vorburger.fswatch
  • https://github.com/vorburger/ch.vorburger.exec
  • https://github.com/MariaDB4j/MariaDB4j
  • https://github.com/enola-dev/enola/
• Life happily ever after if no ext. lib issues, done; else:
• Hand write ✍️ .java, in a TBD https://github.com/lastnpe/jspecify-null-external-annotations-augments
• Hand write equivalent but ugly PITA LibraryModels
• Hack an equivalent code generator

https://github.com/javaparser/javaparser, and/or it's apparent (?) fork https://github.com/eisop/stubparser, used by (?) https://github.com/typetools/annotation-tools may be of interest - although I don't yet fully understand if any of that is even needed... what's wrong with plain simple Java reflection?!

Re. uber/NullAway#1024

/CC @cpovirk FYI

[cpovirk]

FWIW, the Checker Framework groups (EISOP + Typetools) are trying to move off JavaParser IIUC, as they've had issues:

• https://github.com/typetools/checker-framework/pull/6678/files#diff-971e22c4585548de4af53a99142aeec0bdc6504ffb5ea57f425e8a718bcac13aR1354
• Inconsistent inferred annotated file generation during WPI iterations causing non-termination typetools/checker-framework#6570 (comment)
• Update JavaParser to 3.26.0 uber/NullAway#970
• Update to JavaParser 3.26.0 typetools/checker-framework#6648
• Compiler Crash on Parsing Specific Java Program typetools/checker-framework#6631
• Compiler exception due to mismatch between JavaParser and javac typetools/checker-framework#6630

Their likely replacement is https://github.com/plume-lib/javac-parse/blob/main/src/main/java/org/plumelib/javacparse/JavacParse.java, which contains the same basic boilerplate as various similar tools use (example).

As for reflection: If you can actually compile the annotated Java sources, then that could work fine AFAIK. (Maybe bugs around type annotations are more likely for reflection than for build tools, but I don't know. I at least doubt you'd have significant issues for annotations on "root" locations (e.g., fields and method return types, as opposed to type arguments inside those).) I think we ended up with our approach in part because we were interested in annotations for the JDK, which might be trickier to build? I don't actually remember the details of that discussion, if even I heard most of them in the first place. (I do think that trying to do the job with only a "parser" is a bit sketchy: You really want the deps of the classes to be available, I think. But apparently they mostly get away with it.)

[msridhar]

A couple of thoughts / questions.

• By default, NullAway treats calls to unannotated code optimistically; it assumes methods in this code always accept null and never return null. So, even when adopting NullAway, you may not observe issues related to the third-party libraries (since the issues are likely to be missed errors, not false positives).
• Do the annotations for the library model originate in Java source code, or some other type of file (like the EEA files)? If it's Java source code, we're working on a converter from Java source annotations to astubx as part of our efforts to consume the https://github.com/jspecify/jdk annotations in NullAway. (We are using JavaParser for now.) Once we're done we could put that code in a separate Maven artifact and perhaps you could re-use it for other libraries.