-
Notifications
You must be signed in to change notification settings - Fork 619
Add missing nullability annotations to Firestore. #600
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
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
1608731
Add missing nullability annotations to Firestore.
vkryachko 6656cd6
Remove varargs nullability annotations.
vkryachko 27bf36a
gJF
vkryachko 0e25a7a
Add androidx.annotation lint detector.
vkryachko aaff08d
Change nullability check:
vkryachko 9a0a5c2
Address review comments
vkryachko 66c01ec
Address review comments.
vkryachko b631b75
ktlintFormat
vkryachko File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I'm not a fan of the Nullable change to androidx (but also can't say I care too strongly). Is there any good reason to prefer the android-specific version of this over the standard one other than just being consistent with the source of
NonNull
?In some cases this change would be harmful. For example, we share our
CustomClassMapper
with the Firestore Java Server SDK. If we had properly annotated methods like this one then we really should usejavax.annotation.Nullable
because we can't have android dependencies on the server.Also, the javax version of this seems to be the only
Nullable
I get with code completion so this is going to rot without some kind of wider announcement to go reconfigure IDEs and add a linter check or something like that to enforce the preference. Is this change really worth all that?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.
You're right, it has no Kotlin behavior difference compared to
androidx
it's mostly for consistency across all SDKs, so I am ok in principle to revert firestore back to using jsr305 annotations. That said, there is nothing standard about javax annotations, they are part of a JSR that has been dormant since 2006 and is unlikely to become standard at all.As for
androidx.annotations
being unusable on the server, I don't think that is true,androidx.annotations
is a jar(not aar) that has no dependencies so nothing prevents them from being used on the server. Whether they have any semantic meaning for java server frameworks is a good question though.That said, I don't feel too strongly but I have a slight preference towards androidx at least for the public APIs for consistency's sake across SDKs, and I am ok to keep javax for all internal APIs if you like. wdyt?
Uh oh!
There was an error while loading. Please reload this page.
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.
I'd prefer some outcome where we can set it and forget it as far as Android Studio is concerned. Having different classes for public and private classes is something you can't make automatic--every code-completion import would have to choose and it seems like such a speed bump for something that has no practical value. It also seems low enough value that it's unlikely to get caught in code review.
JSR 305 was never ratified, but it seems effectively standard, especially for Google distributed software. For example, even if we standardize on the androidx one, JSR 305 will be in our classpath because that's what Guava, gRPC, and others use.
I'm more concerned that this standardization isn't going to hold automatically since doing so requires people to change their editor configuration. We need to do something to force the world to track on that: a lint check that disallows
javax.annotation.Nullable
would be sufficient. Absent that, we'll soon have bothandroidx
andjavax
flavors in our API and otherwise which I think is worse than mixing the sources of NonNull and Nullable.To be clear: I'm actually OK with standardizing on the androidx one throughout. The number of classes where we need to interoperate with the server is quite small so we can opt of a lint check in those cases should we implement such a check. My argument is essentially that we shouldn't standardize on androidx without such a lint check.
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.
Added lint check, note also that kotlin interop lint checks will provide automatic fix hints(in IDE) with correct(androidx) annotations.
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.
Actually, I am going to disable it for now as it ripples to other SDKs, and this PR is already large enough. Will re-enable in a follow-up PR