Yeah, that’s an annoying problem we have in Spinnaker. We have the javax.annotation one, we have Lombok’s annotation, there is the javax.validation one, the jakarta.validation update, and more nullability annotations from various static code analysis tools. Lombok is one of the things that looks for annotations named “NonNull” or “NotNull” (case insensitive).
> On Dec 2, 2024, at 13:01, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 >>
