search

uber / NullAway

A tool to help eliminate NullPointerExceptions (NPEs) in your Java code with low build-time overhead
MIT License
3.62k stars 290 forks source link

External Annotations Format/s Support, instead LibraryModels #1024

Open vorburger opened 3 weeks ago

vorburger commented 3 weeks ago

Greetings! 🤗

https://www.lastnpe.org founder ⛲ here.

Coming today from https://github.com/enola-dev/enola/issues/845.

Just wondering if NullAway had ever considered External Annotations (such as Eclipse EEA and also old Wiki, or that Annotation File Format from Checker Framework Support), instead of LibraryModels?

Or perhaps someone hacked some sort of LibraryModels generator kind of thing? I dreamt of something like that in https://github.com/lastnpe/external-annotations-esperanto, many moons 🌝 ago - but never did it.

/CC @cpovirk

msridhar commented 3 weeks ago

Hi @vorburger! Short answer: I think it shouldn't be too hard to write a LibraryModels implementation that just parsed external annotations and then returned the right nullability info from its methods. This could be built outside of NullAway and plugged in as a service loader, and we'd be happy to help with fixes within NullAway if needed to accommodate this. Our cycles are extremely limited so we're unlikely to have time to build this ourselves anytime soon.

Longer answer: a key motivation for NullAway has always been fast running times, so NullAway can run on every build. When we were first writing NullAway we looked at supporting Checker Framework stub files, but we were concerned about the time required to parse many stubs. So we went with LibraryModels at first, and eventually created a binary astubx format that is fast to parse. Right now we are actively working on building the support required to translate the annotations in https://github.com/jspecify/jdk to an astubx file so NullAway users can use those annotations; see https://github.com/uber/NullAway/issues/950. Given our limited cycles, and our longer-term effort to better support the JSpecify annotation semantics, we figured it best to focus on supporting the annotations provided in the JSpecify project.

Or perhaps someone hacked some sort of LibraryModels generator kind of thing?

I don't think any kind of code generator is needed necessarily. What I would try at first is to just write an implementation of LibraryModels that parses info from the external annotation files and returns it. If performance is an issue, one could try lazily parsing only the relevant parts of the external annotation files. Only if that was too slow would I resort to something like code generation, but at that point I might just consider generating astubx.