6 ms·

I find Java much more pleasant without Spring; I much prefer Jetty+Jersey+Guava+Guice. It sounds like that's pretty similar to how you're using Scala.

mmastrac 12y ago
Ditto. Spring feels like "the worst of Java", while the exact combo you list above is some of the best and the set I reach for. Jetty is showing its age a bit right now, but it's so much nicer than dealing with Tomcat.
frowaway001 12y ago
I think the difference is that stuff is less hastily cobbled together. People use additional libraries because they add value, not because they paper over ugliness and holes of existing libraries. Scala feels "designed", while Java feels "evolved".
- pjmlp 12y ago
  Yet I have 99% probabilities that my next JVM gig will be Java than Scala, as very few customers ask for Scala skills on their Request For Proposals.
  - frowaway001 12y ago
    How is this related to the topic?
    - pjmlp 12y ago
      That even though Scala is better designed than Java, without Java's cruft earned through evolution, most companies will keep on searching for Java developer skills.
      - frowaway001 12y ago
        We were discussing quality, not popularity.
lmm 12y ago
80% of the problems with java as it's usually written are bad policy rather than fundamental language problems. But there are real cases where language limitations mean you have to either use an unpleasant framework or write unpleasant code. Jersey's annotations are pretty nice, but they're still annotations, not really part of your code. You can be bitten by silly errors like an implementation's annotations not quite matching those on its interface, and when (as is often the case) the annotations get repetitive for a group of similar services, there's no way to factor the common part out. In Spray I can write route definitions that are just as neat as the Jersey ones, but it's plain old code which is an enormously powerful concept; a route can be refactored just like any other code. Guice is similar, e.g. declarative transaction support; better than managing database transactions by hand, but annotation-based proxying is a bit "magic" and confusing to debug. In Scala I can use a monad for transactional operations; the code (using for/yield) is almost as effortless as annotations, but operations which use the database show that in their type and the type system enforces that my transaction boundaries are in the right place. Even more importantly, refactoring in the normal way is safe. (Also e.g. the lifecycle features in Spring are really valuable (and virtually impossible to do without annotations in Java, at least pre-8). In Scala there's scala-arm, which achieves the same thing in a monadic way, with the same advantages as doing that for database transactions. And since the same abstractions are used in both cases, you can write types and helpers that work with both "database operation" and "requires lifecycle-managed resource")
- edwinnathaniel 12y ago
  So here's the thing about annotation and Jersey, I believe you can annotate the seralization of return type once at the top of your resource class, the rest, like http verb, needs to be repeated unless you take the convention one more level up a'la Rails. But that's Rails, a web framework that people said does not fit for microservice. Sinatra is. But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. You would have to catch the exception and convert it to the intended one per method on your controller.
doomspork 12y ago
I've never been a big fan of Spring so I was pleasantly surprised to discover Dropwizard which includes the tools you've mentioned, a few others, some best practices, and a little glue.
caoilte 12y ago
If only you knew the power of monads.

mmastrac 12y ago

Ditto. Spring feels like "the worst of Java", while the exact combo you list above is some of the best and the set I reach for. Jetty is showing its age a bit right now, but it's so much nicer than dealing with Tomcat.

frowaway001 12y ago

I think the difference is that stuff is less hastily cobbled together. People use additional libraries because they add value, not because they paper over ugliness and holes of existing libraries. Scala feels "designed", while Java feels "evolved".

pjmlp 12y ago
Yet I have 99% probabilities that my next JVM gig will be Java than Scala, as very few customers ask for Scala skills on their Request For Proposals.
- frowaway001 12y ago
  How is this related to the topic?
  - pjmlp 12y ago
    That even though Scala is better designed than Java, without Java's cruft earned through evolution, most companies will keep on searching for Java developer skills.
    - frowaway001 12y ago
      We were discussing quality, not popularity.

lmm 12y ago

80% of the problems with java as it's usually written are bad policy rather than fundamental language problems. But there are real cases where language limitations mean you have to either use an unpleasant framework or write unpleasant code. Jersey's annotations are pretty nice, but they're still annotations, not really part of your code. You can be bitten by silly errors like an implementation's annotations not quite matching those on its interface, and when (as is often the case) the annotations get repetitive for a group of similar services, there's no way to factor the common part out. In Spray I can write route definitions that are just as neat as the Jersey ones, but it's plain old code which is an enormously powerful concept; a route can be refactored just like any other code. Guice is similar, e.g. declarative transaction support; better than managing database transactions by hand, but annotation-based proxying is a bit "magic" and confusing to debug. In Scala I can use a monad for transactional operations; the code (using for/yield) is almost as effortless as annotations, but operations which use the database show that in their type and the type system enforces that my transaction boundaries are in the right place. Even more importantly, refactoring in the normal way is safe. (Also e.g. the lifecycle features in Spring are really valuable (and virtually impossible to do without annotations in Java, at least pre-8). In Scala there's scala-arm, which achieves the same thing in a monadic way, with the same advantages as doing that for database transactions. And since the same abstractions are used in both cases, you can write types and helpers that work with both "database operation" and "requires lifecycle-managed resource")

edwinnathaniel 12y ago
So here's the thing about annotation and Jersey, I believe you can annotate the seralization of return type once at the top of your resource class, the rest, like http verb, needs to be repeated unless you take the convention one more level up a'la Rails. But that's Rails, a web framework that people said does not fit for microservice. Sinatra is. But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. You would have to catch the exception and convert it to the intended one per method on your controller.

doomspork 12y ago

I've never been a big fan of Spring so I was pleasantly surprised to discover Dropwizard which includes the tools you've mentioned, a few others, some best practices, and a little glue.

caoilte 12y ago

If only you knew the power of monads.