[mbell]

I don't know what you mean by dynamic but dropwizard is just a selection of other libraries wired together into a framework with supporting code (config, etc) which is built for high performance HTTP services serving JSON, but it can do HTML rendering. The above code is compliant with any JAX-RS implementation, JAX-RS is probably the most well done Java spec I've ever worked with which isn't saying much, but it doesn't suck.

[icambron]

I think by dynamic, they mean that you can't really edit the annotation at runtime. In this case, it would be that you can't choose the HTTP verb using an if statement, for example. Other annotations have parameters, which you might also want to tweak.

Annotations trade flexibility for succinctness and readability. That's often a great reasonable tradeoff and a good place to start, but you might find yourself ripping them out later.

[penrod]

One example would be that with Spark you could procedurally create and register multiple Route instances. That is not an option with an annotation-based API that requires you to have a distinct annotated class per route.

More abstractly, one of the characteristics of object-oriented design is the use of polymorphic objects. APIs which require you to define monomorphic annotated classes violate this and lose generality as a result. They are effectively class-oriented or method-oriented rather than true OO.

[meddlepal]

Why would you want that feature? Also I'm pretty sure nothing about jaxrs annotations prevents such a thing from being possible but the servlet container may get in your way of doing it easily.

[penrod]

Why would you want to procedurally generate routes or verbs? I dunno, perhaps there might be a use case where one would want to define them in configuration or a database. But being able to do something like this is not a "feature," it's just the inherent flexibility of expressing semantics in code.

Why would you want an API that breaks the flexibility of code by forcing it to be glorified XML?

[lmartel]

By dynamic I think he just means that annotations are a really hacky way to do things. You use annotations in place of java code, and while you can tweak java code you can't tweak what an annotation does or how it does it.

[mbell]

> By dynamic I think he just means that annotations are a really hacky way to do things.

Why?

> You use annotations in place of java code, and while you can tweak java code you can't tweak what an annotation does or how it does it.

Why can't you tweak an annotation? Annotations are built into the language, the entire point of them is to allow code to detect their presence in the bytecode and thus react at runtime. e.g. wrap a method marked as @Transactional in a database transaction.

[lmartel]

You're right--instead of "can't" I should have said that a lot fewer Java developers are willing to mess with them, vs. changing code.

Edit: and they're hacky because they're magical--it's entirely not obvious what they're doing.

[mhixson]

This is sort of getting off topic, but... I agree that annotations are magical. The good news is that they announce magic is happening. When I see unfamiliar annotations in Java code I know to look at their javadocs. I like that kind of magic much more than magic by convention (e.g. the location of the given file on disk).