-
Notifications
You must be signed in to change notification settings - Fork 301
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
Update to JSpecify 1.0 and use JSpecify annotations in NullAway code #1000
Changes from 7 commits
54ec4d8
8447096
c2ef197
dfff62e
3ae385e
1b5538d
57a2661
b1c6d4a
15929e5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,7 +31,8 @@ dependencies { | |
annotationProcessor deps.apt.autoValue | ||
compileOnly deps.apt.autoServiceAnnot | ||
annotationProcessor deps.apt.autoService | ||
compileOnly deps.build.jsr305Annotations | ||
// Using api following the guidance at https://jspecify.dev/docs/using#gradle | ||
api deps.build.jspecify | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cpovirk this is encouraged, correct? This will bring in the JSpecify jar onto the annotation processor path for users, but they will have it there anyway I think if they are using a recent version of Error Prone. I think this could only cause a problem if for some reason they already have a dep on an old version of the JSpecify jar. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was wondering about Error Prone, too. All I've found there so far is a test dep, but it could have missed a full dep, especially since I didn't look at all at indirect deps. (So someday Error Prone will get it through Guava or Caffeine or whatever.) I think that including it should be fine. I think you're right that there could in theory be trouble if some other annotation processor wanted the old package, but that seems very unlikely, and things would generally work out OK even in that case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Error Prone will have the dep in 2.30.0 (or 2.29.3 or whatever the next release after 2.29.2 is): |
||
compileOnly deps.test.jetbrainsAnnotations | ||
compileOnly deps.apt.javaxInject | ||
|
||
|
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.
@cpovirk are we currently encouraging Android users to switch over from Android support annotations to JSpecify as well? Or will that cause problems for them?
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.
Phrasing is difficult :) We have had similar conversations internally.
On the one hand, it would be nice if we could find a way to avoid implying that the Android annotations (which of course are declaration annotations) are "just as good" as the JSpecify ones.
On the other hand, it would be nice to make clear there there are still tradeoffs, by which I mainly mean "Dagger (if you don't use a recent javac)." (On the plus side, maybe Android users can more upgrade their compiler especially easily, since they don't need to worry about setting
--release
? Part of me now wants for the NullAway docs to demonstrate configuring a Java 22 toolchain for Android, except that it's not really fair to put that on the critical path for NullAway adopters :))I was hoping to convince myself that we had an existing doc that covered this, but as you saw, I ended up leaving a comment on a JSpecify issue instead.
The best link at this point is probably https://jspecify.dev/docs/whether/#annotation-processors. Let me see if I can think of a way that I'd phrase that once I get back to my desk after a quick break. I'm hoping to propose a different framing for this sentence.
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.
On second thought: I might be putting too much emphasis on the ability to annotate type arguments, type-parameter bounds, and array-element types yet, since NullAway support there is still developing. (And of course NullAway already offers a way to treat unannotated types as non-nullable when you want it, so there's less reason for
@NullMarked
, too.)I think I'd probably just keep this as you have it for now, and we can revisit once we have docs that speak more directly to the tradeoffs. Maybe we'll also tweak the comment in the code block at line 29 at that point.
Hmm, but now that I'm here: Nowadays, people use
androidx.annotation.Nullable
instead ofandroid.support.annotation.Nullable
, right?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.
Will switch to refer to
androidx
, thanks!