[stevvooe]

Where does this stand against dropwizard?

[mbell]

Personally, I would use dropwizard. Spark's key point seems to be avoiding annotation based constructs.

Compare (Spark):

  public class HelloWorld {
     public static void main(String[] args) {      
        get(new Route("/hello") {
           @Override
           public Object handle(Request request, Response response) {
              return "Hello World!";
           }
        });
     }
  } 

to (JAX-RS, which dropwizard uses)

  @Path("/hello")
  public class HelloWorld {
    @GET
    public String get() {
      return "Hello World";
    }
  }

[newobj]

Annotations are great until you want to do ANYTHING dynamic. "It's a trap!" Everytime without fail I want to do this kind of thing I end up ripping it all out later when I need more flexibility.

If Dropwizard lets me fall back to non-annotations, then awesome.

Really, five minutes ago I didn't know either of these projects existed, so right now I'm feeling a little giddy either way you slice it!

[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.

[swah]

Dropwizard is very well implemented and uses annotations for achieving a very concise syntax as far as Java goes. No XML too, which is a big plus for me.

But when I though how many lines some webapp I was writing would take in Clojure, I went to the corner of the room and cried.

My conclusion for now is that "first versions" should be written in dynamic languages.

[pron]

Right. This project should be compared to Jersey (the JAX-RS implementation Dropwizard uses). Dropwizard has other components as well (for monitoring, DB etc.).