The main issue with these annotations is that there are so many providers. It's so bad that tooling just now look for names like @NonNull _without considering the package name_, so there is no limit as to how much you end up with :-(
On Mon, Dec 2, 2024 at 1:58 PM Matt Sicker <m...@musigma.org> wrote: > > I’m alright with the JSpecify dependency assuming it has accumulated the > momentum we expected. Also, I thought annotations didn’t have to exist at > runtime anyways as long as you weren’t using reflection on them. > > > On Nov 22, 2024, at 03:52, Piotr P. Karwasz <pi...@mailing.copernik.eu> > > wrote: > > > > Hi all, > > > > On 19.10.2024 09:28, Piotr P. Karwasz wrote: > >> PS: Regarding annotations, can you take a look at issue #3110[4]. > >> Users are regularly reporting issues for annotations with a `provided` > >> scope. This is due to the `classfile` option to `-Xlint`, which > >> basically only covers missing annotations (of both `CLASS` and > >> `RUNTIME` retention) that occur at **compile time**. I would like to > >> take a per-annotation approach here: some annotations like JSpecify or > >> Error Prone's `@InlineMe` can be really useful to users, so we can: > >> > >> * add 3819 bytes of JSpecify dependency to the `compile` scope of all > >> artifacts. In the near future nullability annotations will be all over > >> the place and JSpecify (compared to the other 13 kinds of annotations > >> there) have some strong supporters[5]. > >> * keep the current _status quo_ for some annotations (e.g. `@InlineMe` > >> and those OSGi versioning annotations that are not mirrored in the > >> Manifest), > >> * write a tool that removes the other annotations from the class files. > >> > >> [5]https://jspecify.dev/about/ > > > > I decided to start implementing this proposal and I created PR #3228 to add > > JSpecify as `compile` dependency. The PR still allows users (include OSGi > > and JPMS users) to manually exclude the dependency, but I doubt anyone will > > do it. > > > > Are you OK with this change? IIRC the main argument against having > > non-optional dependencies in `log4j-api` and `log4j-core` was that we don't > > control them. The argument still stands, but it is micro dependency that is > > controlled by a large group of vendors, so its evolution is pretty much > > under control. > > > > Piotr > > > > [1] https://github.com/apache/logging-log4j2/pull/3228 >
