[sverhagen]

It's always scary to have a lot of power hidden behind an annotation that you don't completely grasp. But I rather take that than having to reimplement all the logic, such as for security, that isn't core to my own business. I have come to trust Spring as a quality product, which will do a better job at those things than I would ever be able to do with the (not in an unhealthy way) resource-challenged teams that I tend to work on.

[lomnakkus]

Personally, I don't like annotations, and it's related to a very specific word you used: Hidden.

Annotations feel very action-at-a-distance-esque because the code that scans for them and processes them is completely separated from the annotation itself. There's no really universally applicable way of just going "show me all the code that processes annotation X" to your IDE... and that's often scary and can also lead to incredibly hard-to-debug problems which would be near-instantly solvable if you could just see the code which processes an annotation immediately.

I feel decorators/higher-order functions are generally to be preferred since it's actually about applying concrete transformations. (Of course they may not always have equal power, but a lot of the time annotations are basically just a HOF in disguise.). Unfortunately, without good type inference the syntax of HOF can get incredibly clunky.

[denisw]

> There's no really universally applicable way of just going "show me all the code that processes annotation X" to your IDE

Isn't "Find References" literally that? All code that makes use of an annotation at runtime (which is the case for all Spring annotations) needs to refer to the annotation's type at some point.