I have never understood this argument. What is exactly the problem with identifying the executed code?
If you inject the bean and call the method you will get caching (because you are using the proxy). If you call the method from within the bean itself however you're not using the proxy and you won't get caching.
It's stuff like this on steroids when you start mixing annotations that makes it really difficult to reason about the code.
*I would do it by introducing a new annotation:
@ProxyImplementation
public @interface Cacheable {}
Maybe Sonar or similar tool already does this kind of analysis.
Imagine I'm looking at a class that is annotated. What is the next step to find the code that gets executed for the annotations?
2. “Find usages” on annotation/annotation properties leads you to init stage, where metamodel is usually built
3. “Find usages” on metamodel classes leads you to the implementation of the behavior defined by annotation
4. Run your code with the breakpoint inside the annotated code. Check the stack trace at the breakpoint, look at the methods and fields of the framework classes in it to validate your understanding of how it works from step 3.
The RetentionPolicy.SOURCE annotations are handled by an annotation processor at compile time, so it is a bit different, but the general idea is the same.
It’s usually one click in IDE to download the sources of an open-source lib like Spring and one click to find the usages of the annotation in those sources (or better, reads of the properties of that annotation). I do not think it is really a big problem to find how the code works both at init and at execution stage.
With an annotation-based framework, how do you do the same? You could find usages of the annotations, and then manually read the thousands of places “@GET” is referenced?
From my exprience there are multiple reasons - The main one: I've learned tons from reading code. The ability to jump into code that does X to see how it's implemented is worth a lot to me. This is something I love about the jvm ecosystem which is unfortunately not present in many other languages. - Many libraries/frameworks (Spring Data comes to mind) provide very leaky abstractions. Understanding how the underlying technology is used can make a big difference. - Address questions when the documentation is not clear enough. - And last: to discover bugs in libraries. This is not common, but it happens.