At Sling we use other classes from javax.annotation as well (compare with https://issues.apache.org/jira/browse/SLING-7135 <https://issues.apache.org/jira/browse/SLING-7135>). So most probably we have to rely on the official Oracle replacement and the question for me is how that behaves in the context of Java 8 which exports javax.annotation from the system bundle.
> On 2. Aug 2018, at 12:11, Karl Pauls <[email protected]> wrote: > > Would would be the problem with that? I wasn’t talking about a jpms module > - IMO, we can just create a bundle that contains and exports > javax.annotation and be done with it think. > > regards, > > Karl > > On Thursday, August 2, 2018, Konrad Windszus <[email protected]> wrote: > >> >>> However, I wanted to point out option b). IIRC, there is nothing >>> preventing us to just provide the package ourselves and then it would be >>> problem solved, no? >> >> Unfortunately not, due to potential split-packages: >> https://blog.codefx.org/java/jsr-305-java-9/ < >> https://blog.codefx.org/java/jsr-305-java-9/> >>> >>> >>> regards, >>> >>> Karl >>> >>> On Thursday, August 2, 2018, Julian Reschke <[email protected]> >> wrote: >>> >>>> On 2018-08-02 10:55, Stefan Seifert wrote: >>>> >>>>> ... >>>>> benefits: >>>>> - removes a blocker from achieving Java 9 compatibility >>>>> >>>> >>>> AFAICT, it's only Java 11 where there's an actual compat problem (but >> yes, >>>> that'll be the version we need to support soonish). >>>> >>>> ... > drawbacks: >>>>> - the jetbrains annotations include some more (mostly >> IntelliJ-specific) >>>>> annotations than only the nullable annotations >>>>> - the jetbrains annotations are no "standard annotations" >>>>> ... >>>>> >>>> >>>> Well, if there were "standard annotations" for this, we'd use them :-) >>>> >>>>> ... >>>> >>>> Best regards, Julian >>>> >>> >>> >>> -- >>> Karl Pauls >>> [email protected] >> >> > > -- > Karl Pauls > [email protected]
