Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External Annotations Format/s Support, instead LibraryModels #1024

Open
vorburger opened this issue Aug 20, 2024 · 1 comment
Open

External Annotations Format/s Support, instead LibraryModels #1024

vorburger opened this issue Aug 20, 2024 · 1 comment

Comments

@vorburger
Copy link

Greetings! 🤗

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

Coming today from enola-dev/enola#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

@vorburger vorburger changed the title Eclipse External Annotations (EEA) Support, instead LibraryModels External Annotations Format/s Support, instead LibraryModels Aug 20, 2024
@msridhar
Copy link
Collaborator

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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants