Investigate troubles caused by Spock integration

Reported here https://github.com/junit-team/junit5/commit/eaab286a53d534966de7cf6200955c0d3b8830f4. I need to check in more depth but perhaps one nice idea would be to have the support not dependant on the JfrEventTest annotation (global spock extension). If I understand that correctly Quarkus support works like that. It would make usage even simpler.

cc @gunnarmorling @sbrannen

[sbrannen]

@gunnarmorling, I think you misunderstood the point I was trying to make (likely because I was too vague).

I think the current behavior is desirable, as it allows to re-use annotated classes in different contexts. The canonical example being JPA entities which can be used as data structures on the client-side, without the need for having the persistence API on the classpath there.

Yes, that’s a great feature of Java. No doubt. We love it!

But… the Java compiler emits a warning if you try to use a third-party annotation in your own code when that third-party annotation is meta-annotated with a second third-party annotation that is not present in the class path.

And… if you compile with -Werror (which many projects do), your build fails.

We argued with the Java team that such a condition should not result in a warning that can fail the build, because of the fact that the exact same code (once compiled) works fine at runtime without the second third-party annotation on the classpath.

Does that make sense now?

---

Hmmm… maybe I should say fourth-party instead of “second third-party”. 🤔

[gunnarmorling]

Ah yes, got it now. Indeed I understood exactly the opposite of what you meant to say 😃 So yes, I agree there should be a way for compiling the code of this situation without any warnings (and without supressing other, unrelated, warnings), if that code can be run just fine later on.