Yeah, now I’m noticing even more, particularly from library-specific versions of the annotations. I’m glad we decided to use this library directly rather than introduce another set of annotations!
> On Dec 2, 2024, at 13:28, Gary D. Gregory <ggreg...@apache.org> wrote: > > Just on the CP for one app tooling stack: > > org.jetbrains.annotations.NotNull > org.jetbrains.annotations.Nullable > com.sun.istack.NotNull > com.sun.istack.Nullable > org.springframework.lang.NonNull > org.springframework.lang.Nullable > jakarta.annotation.Nonnull > jakarta.annotation.Nullable > javax.annotation.Nonnull > javax.annotation.Nullable > org.wildfly.common.annotation.NotNull > org.wildfly.common.annotation.Nullable > > What a (sad) joke! > > Gary > > On 2024/12/02 19:14:55 Matt Sicker wrote: >> 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 >>>> >> >>
