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

Remove more annotations from non-visible APIs #101

Open
cpovirk opened this issue Oct 7, 2024 · 0 comments
Open

Remove more annotations from non-visible APIs #101

cpovirk opened this issue Oct 7, 2024 · 0 comments

Comments

@cpovirk
Copy link
Collaborator

cpovirk commented Oct 7, 2024

  • Annotating them is more work, so we don't want to encourage more of that.
  • We already annotate them only incompletely, so we don't want the presence of annotations to suggest that we have been being complete.
  • Not only does annotating private APIs require more work up front, but even existing annotations have a cost because they complicate merges, as noted in cbe846f.
  • Even if we annotate private APIs correctly today, we can't rely on them to keep their current behavior even as reliably as public APIs do (which, as we know, is not 100% but should at least be highly reliable—and noteworthy when changes do occur).
    • [edit: I think this was a reference to behavior changes in System.console. However, I think we eventually concluded that System.console had technically remained @Nullable, even though the cases in which users could see null became much more restricted. We could also have the philosophical discussion about whether @Nullable can ever be truly "wrong" (as opposed to just a very imprecise and bad idea) in the return type of a static method :)]
  • I had forgotten about the crash we had from a change to an internal API back in Remove method-level Atomic annotations. #56.

[edit: done some in 300a39f]

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

1 participant