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
