Creating aliased annotations without editing Checker Framework source code

This is similar to part of #1665, so you probably won’t be excited about this either, but here goes…

Bean Validation (version 1 and 2 alike) allows annotating a constraint with another constraint to inherit its meaning. For example, if you write

@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE,
         ElementType.CONSTRUCTOR, ElementType.PARAMETER, ElementType.TYPE_USE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy={})
@NotNull
@interface MyNotNull {
    String message() default "";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

then you can use @MyNotNull as an alias for @NotNull.

Checker Framework doesn’t understand this and ignores the custom constraint.

Why is this useful? Well, in my case, I was using a validator that supported TYPE_USE constraints in accordance with the Bean Validation 2.0 spec but brought in an old Bean Validation 1.1 API dependency that didn’t declare TYPE_USE. I didn’t want to risk breaking something else by including the whole newer API, so I wrote code much like the above and used the custom constraint in my validated beans.

Another reason might be to combine several constraints into one, if I understand correctly that this is possible. It might not seem to matter much for Checker Framework as NotNull is the only Bean Validation constraint that Checker Framework supports, but if the programmer combines NotNull with some other constraints and uses the new constraint, Checker Framework should still pick up the NotNull.

By the way, Checker Framework currently (2.2.2) ships with an outdated definitions of javax.validation.constraints.NotNull that doesn’t declare TYPE_USE. Now that I’ve upgraded to a newer validator and no longer need my custom constraint, I’ve discovered that Checker Framework’s outdated definition overrides the newer definition from the validator and I have to tweak my dependencies to override it again. Does Checker Framework have to ship all those third-party annotations at all?

Start with the Bean Validation constraint-composition example in the issue and compare it with how the Checker Framework currently handles javax.validation.constraints.NotNull. Determine the intended behavior for custom composed constraints and bundled third-party annotation definitions. Done should include a clear resolution for alias recognition and the dependency-definition conflict described here.