1

Hell froze over and I'm thinking of adding a dependency to JSR-305 @Nonnull and @Nullable annotations to the jOOQ API, e.g. to make guarantees like:

public interface Field<T> {
    ...

    // The resulting Condition will never be null
    @Nonnull

    // The argument Field can be null for convenience
    Condition eq(@Nullable Field<T> other);
}

Among all the unfortunate options, I'm opting for JSR-305, naturally, because it appears to be the least intrusive dependency, despite it being dormant. These are my intrusiveness concerns:

My question:

JSR-305 annotations have @Retention(RUNTIME) for obvious reasons. This means that by adding such annotations, I would create a compile time dependency on that library. I can live with that.

However, I don't want to require that consumers of the jOOQ API add this dependency on their side to run the library. It should be possible to run jOOQ without running into any NoClassDefFoundError et al.

I've made the following test:

import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Retention;

class Annotated {
    @Annotation
    public static void main(String[] args) {
        System.out.println("works");
    }
}

@Retention(RUNTIME)
@interface Annotation {}

I've then copied the Annotated.class out of the project (without the Annotation.class) and ran it. It printed "works" as expected.

Is this guaranteed to work? If yes/no, why?

Note: I'm aware of this Q&A, but I'm looking for JLS-style formal proof of this behaviour. Also: I gave a bit more context than strictly needed because perhaps there's another solution.

Community
  • 1
  • 1
Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509
  • Found answer here: https://stackoverflow.com/questions/10032946/are-annotation-class-files-needed-in-the-runtime-class-path – Kier GRAY Aug 11 '21 at 08:37

0 Answers0