5 ms·

Spark still has the same problem (or feature depending on your tilt): It exists only to avoid annotations. In my opinion Spark: get("/hello",(request, res

by mbell 12y ago

Spark still has the same problem (or feature depending on your tilt): It exists only to avoid annotations. In my opinion Spark: get("/hello",(request, response) -> { return "Hello World!"; }; is still uglier than jax-rs: @GET @Path("/hello") String hello() { return "Hello World!"; }

benjiweber 12y ago
The main difference is Spark is just Java. No need for reflective annotation scanning or any other magic.
- brazzy 12y ago
  Annotations are just Java. Welcome to 2004!
- Argorak 12y ago
  I think I know what you mean, but annotations and scanning for them is definitely Java and used very widely. Honestly, when JUnit was still "just Java" by that definition, it was a much worse framework.
  - guelo 12y ago
    This is tangential, but before annotations JUnit still used reflection and scanning looking for methods named testXXX(). And honestly, it wasn't that much worse.
    - timclark 12y ago
      If I compare the lines of code between JUnit without annotations and JUnit with annotations I usually have less lines of code without annotations and I don't find it bothersome to name my test method correctly. Annotations in Java have always bothered me! Why are they needed? I don't need them in Clojure, Go, Haskell, C - similar behaviour is supplied by alternative means.
      - thescrewdriver 12y ago
        In many cases annotations are just a crutch to work around glaring limitations in the Java language.
- Terr_ 12y ago
  While it may use "magic" under the hood, I think the important thing is that the magical results are predictable. Annotations have their own usage-contracts, and have a certain degree of self-documenting code to tie everything together. ...So any sufficiently advanced magic is indistinguishable from science :)
  - timclark 12y ago
    JAX-RS annotations aren't really composable - functions usually are, although I haven't looked at the Spark implementation to find out. With plain functions if I need to wrap requests or responses I just wrap the functions. With JAX-RS I need to find or write an appropriate annotation or start adding filters. With plain functions I can share behaviour between resources by sharing functions.
- meddlepal 12y ago
  I've been pondering the performance implications of JAX-RS recently. All that reflection cannot be good for raw performance. I love how simple it is, but my company is at the point where squeezing every ounce out of our API servers is necessary. I've been fiddling around with Vert.x a little; but another option is just to use raw Servlets.
  - norswap 12y ago
    It could use annotation processing (aka compiler plugins) instead. Not sure how easy that is to bundle and deploy however (it's not hard to do by hand, by don't know if you can include that kind of stuff in a maven dependency for instance).
    - meddlepal 12y ago
      Are you suggesting something like Lombok for RESTful services? I am not familiar with using annotations at compile time to produce code; so while I guess it is totally possible, I feel like I would be doing it all from scratch.
      - norswap 12y ago
        AFAIK Lombok plugs into Eclipse APIs, it doesn't use annotation processing. Read this to get some idea of what can be achieved with annotation processing: http://scg.unibe.ch/archive/projects/Erni08b.pdf http://scg.unibe.ch/archive/projects/Erni08b.pdf They do use so compiler API which are not stable interfaces, but even without that, you can go surprisingly far.
chamakits 12y ago
I too prefer the jax-rs annotation style, but this is definitely by design on part of the Spark project. It emulates Sinatra for Ruby, which takes that 'clean' approach of doing things simply and predictably. You can very quickly understand how to use annotations with jax-rs. But that's declarative. You annotate your code, and understand that the framework will take care of the rest. This is great for fully built complex frameworks. The problem is, that with annotations you are marking something in a very ambiguous way that can be used by the framework in any way. Its easy to understand, but from just reading the code, you can't really know HOW the annotation is being used. Sinatra/Spark on the other hand are much more imperative. You need to assume very little about what the code actually does, as you are imperatively building exactly the way you'll be listening to requests, without having to know anything of how the framework is going to interpret anything. It's much more direct in what you wrote mapping to a very specific predictable set of actions, determined by the language, not so much the framework. Two separate ways of thinking/styles that are happy to live separately making people happy in different ways.
thescrewdriver 12y ago
That's very subjective. I find the jax-rs version with annotations scattered everywhere to be very ugly. I prefer my source code to not look like it has Twitter hashtags everywhere.

by mbell 12y ago

benjiweber 12y ago

The main difference is Spark is just Java. No need for reflective annotation scanning or any other magic.

brazzy 12y ago
Annotations are just Java. Welcome to 2004!
Argorak 12y ago
I think I know what you mean, but annotations and scanning for them is definitely Java and used very widely. Honestly, when JUnit was still "just Java" by that definition, it was a much worse framework.
- guelo 12y ago
  This is tangential, but before annotations JUnit still used reflection and scanning looking for methods named testXXX(). And honestly, it wasn't that much worse.
  - timclark 12y ago
    If I compare the lines of code between JUnit without annotations and JUnit with annotations I usually have less lines of code without annotations and I don't find it bothersome to name my test method correctly. Annotations in Java have always bothered me! Why are they needed? I don't need them in Clojure, Go, Haskell, C - similar behaviour is supplied by alternative means.
    - thescrewdriver 12y ago
      In many cases annotations are just a crutch to work around glaring limitations in the Java language.
Terr_ 12y ago
While it may use "magic" under the hood, I think the important thing is that the magical results are predictable. Annotations have their own usage-contracts, and have a certain degree of self-documenting code to tie everything together. ...So any sufficiently advanced magic is indistinguishable from science :)
- timclark 12y ago
  JAX-RS annotations aren't really composable - functions usually are, although I haven't looked at the Spark implementation to find out. With plain functions if I need to wrap requests or responses I just wrap the functions. With JAX-RS I need to find or write an appropriate annotation or start adding filters. With plain functions I can share behaviour between resources by sharing functions.
meddlepal 12y ago
I've been pondering the performance implications of JAX-RS recently. All that reflection cannot be good for raw performance. I love how simple it is, but my company is at the point where squeezing every ounce out of our API servers is necessary. I've been fiddling around with Vert.x a little; but another option is just to use raw Servlets.
- norswap 12y ago
  It could use annotation processing (aka compiler plugins) instead. Not sure how easy that is to bundle and deploy however (it's not hard to do by hand, by don't know if you can include that kind of stuff in a maven dependency for instance).
  - meddlepal 12y ago
    Are you suggesting something like Lombok for RESTful services? I am not familiar with using annotations at compile time to produce code; so while I guess it is totally possible, I feel like I would be doing it all from scratch.
    - norswap 12y ago
      AFAIK Lombok plugs into Eclipse APIs, it doesn't use annotation processing. Read this to get some idea of what can be achieved with annotation processing: http://scg.unibe.ch/archive/projects/Erni08b.pdf http://scg.unibe.ch/archive/projects/Erni08b.pdf They do use so compiler API which are not stable interfaces, but even without that, you can go surprisingly far.

chamakits 12y ago

I too prefer the jax-rs annotation style, but this is definitely by design on part of the Spark project. It emulates Sinatra for Ruby, which takes that 'clean' approach of doing things simply and predictably. You can very quickly understand how to use annotations with jax-rs. But that's declarative. You annotate your code, and understand that the framework will take care of the rest. This is great for fully built complex frameworks. The problem is, that with annotations you are marking something in a very ambiguous way that can be used by the framework in any way. Its easy to understand, but from just reading the code, you can't really know HOW the annotation is being used. Sinatra/Spark on the other hand are much more imperative. You need to assume very little about what the code actually does, as you are imperatively building exactly the way you'll be listening to requests, without having to know anything of how the framework is going to interpret anything. It's much more direct in what you wrote mapping to a very specific predictable set of actions, determined by the language, not so much the framework. Two separate ways of thinking/styles that are happy to live separately making people happy in different ways.

thescrewdriver 12y ago

That's very subjective. I find the jax-rs version with annotations scattered everywhere to be very ugly. I prefer my source code to not look like it has Twitter hashtags everywhere.