[suchar]

From my personal experience, the first example doesn't really happen: thankfully I rarely see people randomly throwing annotations at methods/classes hoping one of them will stick. For most of the time annotations are self-explanatory.

However, there are some real issues with annotations in Spring/Java: - Application will sometimes run just fine without annotation processor/interceptor. Think of `@EnableScheduling` in Spring: you won't know that `@Scheduled` is not working (because of missing `@EnableScheduling`) until you observe that method is not executed. In this case static code is a clear win. - Annotation order: not all annotation processors/interceptors in Spring support specifying order. Annotation order in the code doesn't matter: it is lost during compilation. Good luck figuring out what is applied first in a method with `@Retry`, `@Transactional` and `@Cached` - will retry be executed within transaction or each retry will have its own transaction? This also is easily solved with static code instead of annotations.

As for compile-time error vs runtime-error: personally I don't really care as long as there is any error (which is not always the case in the first example) during the build/test/init/assembly phase. When I'm writing SQL queries in the code, I'm getting SQL parsing/compilation errors during application runtime - but that's fine, because I've written SQL-s against DB execution engine. When I'm writing Spark SQL job, I'm getting errors during query planning phase - and that's also fine, because I'm writing code against Spark's execution engine. Writing annotations against "annotation execution engine" (annotation processor/interceptors) doesn't seem any different or wrong in principle. Although, there are things that could be improved.

Stacktraces: there are a few additional interceptor method calls in the stacktrace when annotations are in use, however, most of the complexity comes from library/framework structure and developer's familiarity with it. Spring covers a lot of use cases thus it has its share of complexity. I'm not sure if "Spring without annotations" would be noticeably easier to work with, although I assume that feature-parity with Spring (MVC) is not a goal of this project so it probably will be easier to understand.

[Supermancho]

> From my personal experience, the first example doesn't really happen:

It happens every day, all day. Other developers don't see it, because it doesn't even compile.

> I rarely see people randomly throwing annotations at methods/classes hoping one of them will stick.

I see it, plenty, in other projects. I have done it, trying to work around an arbitrary 3rd party restriction. I can't get something to work and see some old SO and hope it applies. Look at the arcane combination and through trial-and-error figure out what is relevant...then work backwards. Sometimes you can figure out what's going on without a blog explaining the opaque behavior or the overly-simplistic documentation explaining what something does...or used to do or doesn't always in some specific set of conditions, mainly mine. All you have to know is every bit of how each annotation works and why, and how that interacts with every possible element of your compilation and runtime. This is the unrealistic state of "understanding" annotations for the vast majority of java developers...or maybe it's just me and everyone I work with.