-
Notifications
You must be signed in to change notification settings - Fork 85
build: use JSpecify @Nullable instead of JSR305 #444
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
Conversation
rebased on latest main and the build issue is gone |
Based on a little searching, I am not sure that checkerframework is something we should be buying in to:
JSpecify seems to have a lot of industry backing (Google, Jetbrains, Meta, Microsoft, Oracle, PMD, ...) so maybe that is a better direction? |
I don't mind which alternative we use we just shouldn't use JSR305 in my opinion. |
Signed-off-by: Niels Pardon <[email protected]>
Signed-off-by: Niels Pardon <[email protected]>
I rebased on current main and pushed a commit switching to JSpecify |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me but really needs the blessing of @vbarua on the preferred nullability annotation library.
I actually don't have strong preferences here. As @/bestbeforetoday points out, JSpecify seems to have broad industry support so I'm happy to switch to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
JSR305 has been dormant for years and was never finalized. It would be better to use alternative approaches like the checkerframework which is e.g. what Apache Calcite is doing.