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
