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

Allow NotNull and Nullable on package declarations #60

Closed
wants to merge 2 commits into from
Closed

Allow NotNull and Nullable on package declarations #60

wants to merge 2 commits into from

Conversation

spnda
Copy link

@spnda spnda commented Sep 23, 2021

When @NotNull and @Nullable are used on a package declaration in a package-info.class, all fields in all classes should be not-nullable or nullable by default, respectively. Frameworks like Spring have had these annotations for a while (@NonNullFields and @NonNullApi, and would therefore not require any new implementation for many static analyzers). It might also be a bit better to make these new annotations, but that's up to you, reviewers.

@amaembo
Copy link
Collaborator

amaembo commented Sep 24, 2021

Duplicated by #18
This problem is much more complex than just adding a new target and two lines of documentation. There are many questions to address, e.g.:

  • Does it apply to method parameters? What if it's necessary?
  • What about inheritance? What if we declare interface with a method String getString() in @NotNull package, then implement it inside the @Nullable package? Which resulting nullability should be used?
  • Does it apply to declared type parameters? What about type arguments? What if we declare interface X<T> {} in @NotNull package? Will all instantiations of T be assumed as @NotNull? What if we instantiate it inside the @Nullable package?
  • IntelliJ IDEA provides automatic instrumentation via annotation processor that turns @NotNull method parameters and return values into runtime assertions. It's quite difficult to implement this feature if you have @NotNull in package declaration which is a separate file (and can be even separately compiled).

I'm closing this, as we already have #18 to track the same problem.

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

Successfully merging this pull request may close these issues.

None yet

2 participants