Can you provide an example project?

You can close it. I could bypass in Eclipse.

Thinking about this a bit – I think I know what is going on.

ODL projects are all derived from odlparent, which provides Eclipse annotations as <scope>provided</scope>, so we do not generally see this issue – but it kinda is a real one, as for our docs artifacts we need to spell them out.

While annotations are completely optional at runtime, at least some of them end up being visible in our API contracts, hence rather than being scope=provided, they should be optional dependencies. This is certainly true of immutables.org and checker-qual (for which we already do some amount of dancing). JDT annotations seem to also fall into this category.

At the end of the day these end up falling into three buckets based on their RetentionPolicy:

• RetentionPolicy.SOURCE are clearly scope=provided, as they do not leak outside of build project (@MetaInfServices falls here)
• RetentionPolicy.CLASS are probably scope=compile, optional=true, which means we need to deal with their packaging (i.e. filter for features)
• RetentionPolicy.RUNTIME are an extension of RetentionPolicy.CLASS, but we also need to evaluate how our supported runtimes interact with them

Hi rovarga 
Yes I just found a way to get around this in Eclipse. I disabled Null analysis.

So there will be no fix until version 13? We use 8.0.9

I guess I can live with it. Thanks for the explanation though.

//mikael

That's odlparent-13, which may or may not be Potassium.
The project you are seeing this in can be fixed by adding either

      <dependency>
        <groupId>org.eclipse.jdt</groupId>
        <artifactId>org.eclipse.jdt.annotation</artifactId>
        <version>2.2.700</version>
        <scope>provided</scope>
      </dependency>

(which is what all ODL projects do implicitly) or

      <dependency>
        <groupId>org.eclipse.jdt</groupId>
        <artifactId>org.eclipse.jdt.annotation</artifactId>
        <version>2.2.700</version>
        <optional>true</optional>
      </dependency>

(which what this issue will end up doing, I think)

In both cases you can omit the version if you pick it from odlparent (through a dependencyManagement import)

An unfortunate side-effect of this is that optional stanza is not propagate via dependencyManagement, requiring users to repeat the declaration.

So the first cut is in – it requires all dependencies to be explicitly declared, which in turn ends up being quite invasive. We'll see where this goes.

Okay, so this ends up being ugly beyond words.

The problem is not jdt.annotation, which ends up being an API contract – and hence we just end up 'requires static transitive' it.

The problem are other annotations on public class, which DO NOT form API contracts, like:

• @SuppressFBWarnings, which we definitely do not want to require transitive to, as they are purely local things to make SpotBugs behave. For that we essentially need to create package-private utility method holders, which are annotated and provide enough rope for the usual code
• @SuppressModernizer, where we explicitly provide things like bridges to Future.transform(), which invariantly must take Guava's Function. For those we drop the annotation and widen suppression to cover the entire artifact

So we end up battling what is essentially insane tool semantics. I just do not get why a tool like Eclipse would need to resolve an upstream annotation on a private method in a subclass. It is private and retention=CLASS for $DEITY's sake, so the world is not fluffing coming down – but hey, we absolutely MUST resolve it. Okay, yeah, that make some sense – in which universe?! It is by JLS definition a private detail (especially in JPMS world). Why in the seven circles of anti-Valhalla would a subclass ever even care about that?!