Module-level `@NotNullByDefault`

[CC007]

In July the @NotNullByDefault annotation was added. This annotation can be used with target TYPE and PACKAGE, but sometimes you would want to have your fields, parameters and return types in (almost) every package in your module be default not null.

Therefore I propose to add the MODULE element type to the target annotation
So: @Target(value={TYPE,PACKAGE,MODULE}) instead of @Target(value={TYPE,PACKAGE})

This would also require changes in any annotation processor, IDE or language server that acts on the @NotNullByDefault. I don't know to what extent that is part of this repo.

[CC007]

This issue was made in response to the comments on #18

Maybe one day the @NotNullByDefault annotation could be expanded with a boolean applyToSubPackages parameter.

This is not a good idea. [...] This problem should be solved with module-level annotation.

[lwr]

It is not a good idea to add ElementType.MODULE to NotNullByDefault annotation, it will break current code for java8 env (a javac warning that can not be suppressed)

A better choice is to add a new annotation class such as ModuleNullMarked

[cpovirk]

FWIW, as one of the people involved in JSpecify, I too wonder from time to time whether we should have introduced @NullMarkedModule instead of including MODULE in the @Target for @NullMarked: While the enum-constant warning will finally be gone in Java 27, we also very occasionally hear of issues at runtime, both under Java 8 and under Android. A separate annotation would also have been a convenient place to document that module-level annotations help only if your users put your jar on the module path. I'm still not entirely sure what to think, given that a separate annotation would feel a bit awkward today and more awkward over time. So I'll just agree that adding MODULE does carry downsides.

[lwr]

As another option, we can add extension to NotNullByDefault as @NotNullByDefault (withSubpackages = true) to avoid java8 compatibility trap and bring more flexibility.