Hacker News Reader

Comment by pron | Hacker News Reader

This project is nice but it's important to mention that there is actually a "Java micro web framework" standard called JAX-RS that is pretty widely adopted (with solid open-source implementations by JBoss, Apache, Oracle and others). Here's a rather old comparison of JAX-RS implementations: http://www.infoq.com/news/2008/10/jaxrs-comparison

Its most notable implementation is perhaps Jersey (https://jersey.java.net/documentation/latest/getting-started...), which is used, for example, by Dropwizard (mentioned in another comment).

Some of these implementations include important features like health and performance monitoring.

View on HN

JAX-RS still has the same problem with nesting and redundancy, doesn't fit the word "micro" or draw parallels with Sinatra.

To quote another commenter, here's JAX-RS code:

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

Seems very Sinatra-like to me.

You don't see all the redundancies in that code?

I see the term "get" twice. The class name is redundant with the resource path. I suppose not a huge problem because many MVC frameworks require classes, but not even close to Sinatra.

Sinatra:

  get '/hi' do
    "Hello World!"
  end

You're counting required language keywords towards what makes a micro-framework? That's bullshit. You're never going to get away from some of the keywords in Java, nor does that make JAX-RS less 'micro'

Here is an example in Groovy using JAX-RS:

  @Path("/hello")
  class HelloWorld {

    @GET 
    def sayHello() {
      "Hello, world!"  
    }
  }

Almost as clean. The braces and parens make it a bit uglier; but those are just part of the language.

The point is that you shouldn't have to configure things like @Path because they can be inferred from the class name. Why not:

  class Hello {
    def get() {
      "Hello, world!"
    }
  }

I would prefer to see this and then let someone have a routing config somewhere else if they want to move the /hello endpoint.

It doesn't work how you want it, fine, don't use it. It's super brief for the rest of us.

Sounds like a preferential thing then; I prefer to keep everything together.

I've never liked the separate routing config approach. Play Framework uses(d?) it in the 1.x branch and I always found it annoying.

Similarly old-world Servlets were done that way too. You'd put the routing information in an XML file and the container would read it at start up.

Not only uglier, but a lot sloooooooower.

Concision is a virtue.

Further, not a big fan of annotations. Which is declarative programming for Java. In which case, just use a dynamic programming language.

I am a big fan of stepping thru code with a debugger. Which rules out programming via XML (eg Spring) and annotations.

You can step through all of Spring in your debugger with no problems, whether you configure it in xml or via annotations. Spring is not "programming in xml".

Also, Python has decorators and Python 3 will soon have function annotations.

step through all of Spring in your debugger with no problems

You misunderstand. Java breakpoints, yes. Spring breakpoints, no.

To troubleshoot Spring, the best you can do is trace (log) and inspect untyped nested hashmaps.

No thank you.

The IDE can sometimes pre-detect trivial errors. Whoopie.

Python has decorators and Python 3 will soon have function annotations.

My condolences.

You're missing out on all the power that jax-rs gives you though with how it binds to things like jackson.

eg:

  @Path("/companies")
  public class CompanyResource {
    @GET
    @Path("/{id}")
    @Produces(MediaType.APPLICATION_JSON)
    public Company getFromDB(@PathParam("id") String companyId) {
      return SomeDatabase.get(companyId);
    }
  }

  public class Company {
    List<Person> employees;
  }

  public class Employee {
    String name;
    int age;
    Employee manager;
  }

You start to understand how good jax-rs and modern Java can be when you actually start using it for something useful.

Using SparkJava this is what it looks like:

  get(new JsonTransformer("/companies/:id") {
    @Override
    public Company handle(Request request, Response response) {
      return SomeDatabase.get(request.params(":id"));
    }

  });

  public class Company {
    List<Person> employees;
  }

  public class Employee {
    String name;
    int age;
    Employee manager;
  }

So it's got the same functionality as the industry accepted standard, same concision as the industry accepted standard, only the syntax is different. Why not just use the industry accepted standard syntax, then? Why isn't Spark a JAX-RS implementation?

I haven't written Java in a while and I've never seen any other examples of JAX-RS, so feel free to take this with a grain of salt. That said, in my opinion JAX-RS looks uglier, less clear, and more verbose than Spark, and I'd want an alternative to JAX-RS were I ever to write Java web code.

Agreed, Per Wendel the creator of Spark explains here too:

http://www.sparkjava.com/why.html

I have done JAX-RS, for small web apps where you aren't trying to build in the kitchen sink, Spark is looking nice. Spark doesn't seem to be trying to replace JAX-RS, it seems to just be making the syntax a bit easier and doing lightweight REST in a way I find unique and really applicable to small web apps. He uses plain Java main.

You can use a plain Java main with JAX-RS, too (when using an embedded server like, say, Jetty – just like Spark). Dropwizard does exactly that.

Well, I don't know... I'm sure Spark is great, but dropping a widely accepted, well established and quite liked standard just for an arguably "bit easier" syntax (especially when there haven't been any major complaints about the standard syntax) seems like the wrong tradeoff. I would have loved a JAX-RS implementation with other compelling features like performance, monitoring etc. Another good JAX-RS implementation is always welcome.

Reply on news.ycombinator.com