HN Explorer

23 comments

[ 4.3 ms ] story [ 54.0 ms ] thread
hnriot
this is a really confusingly named project. I immediately thought that the scala for Apache Spark ("Lightning-fast cluster computing") had been rewritten in java!
rxin
I had the same thought! Apache Spark 1.0 is actually going to support lambda functions in Java 8. A pretty big deal for making Java programmers' life easy.
tathadas
Maybe we should replace Jetty inside Apache Spark with SparkJava and ...

http://i.imgur.com/yhwhF5J.jpg

mahmud
Spark requires jetty to run in standalone mode, otherwise a servlet container.

Also, no memes on HN :-)

bilalq
This is great! Now that the verbose syntax is out of the way, I can see myself using this as a gateway to web development for those that have never done any programming outside of java for school assignments.
mbell
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
The main difference is Spark is just Java. No need for reflective annotation scanning or any other magic.
brazzy
Annotations are just Java. Welcome to 2004!
Argorak
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
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
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
In many cases annotations are just a crutch to work around glaring limitations in the Java language.
Terr_
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
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
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
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
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
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

They do use so compiler API which are not stable interfaces, but even without that, you can go surprisingly far.

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