Comment by slantedview | Hacker News Reader

Comment by slantedview | Hacker News Reader

Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4].

The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless complexity that's so pervasive, where Spring is/was the poster-child. Building generation after generation of newer APIs on top of the old stuff doesn't remove the fact that the old stuff is still there. Hiding complexity with code generation doesn't remove the fact that code still needs to be generated. And the same with annotation driven programming. And JPA/Hibernate/etc.

Simplicity isn't about hiding mountains of legacy complexity under a shiny new API, or annotations, or code gen - it's about having a stack that is understandable and easy to use from top to bottom without requiring magician's toolbag of tricks to hide the complexity. I get the feeling that most JVM developers don't even know what this looks like - Dropwizard is a great example. Other languages/ecosystems tend to not have this legacy baggage, so you can't blame their developers for thinking that the mainstream JVM frameworks are ridiculous. Because they are.

/end-rant

[1] https://www.playframework.com/

[2] http://sparkjava.com/

[3] http://www.jooq.org/

[4] http://www.dropwizard.io/

I really like annotations.

And I really enjoy working on JavaEE.

For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.

This is so true! ... I was ready to give up on J2EE (prior to the name change and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no longer an XML configuration nightmare with 10 classes to define all the required interfaces and implementation.

To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity objects or JAX-B objects to be completely declarative. Start with @Data and @Value.

[1] https://projectlombok.org/

My argument isn't about using tools that reduce boilerplate through codegen or annotations, it's to use tools where boilerplate doesn't exist. Why do you need JPA? Why do you need EE? Chances are, you don't.

Boilerplate and annotations are two wildly different beasts on my understanding :

Boilerplate is things I have to repeat mindlessly every time I want to do something.

Annotations on the other hand usually is one single line of code.

Disclaimer : not a native English speaker although I am fairly sure about this.

Edit: look at hodao from the tomitribe GitHub account. Or DeltaSpike from Apache.

I'm guessing you like annotations because they're less painful than what you were used to previously. You don't need an EE server to serve up a basic web app. Or even a complex one.

You don't need, but they are free and wonderful.

Everything already configured and tested to work out of the box, including transactions.

Yes, you might get away with a smaller initial download with something else but the server is a onetime download and your deployed apps are small.

+1 for Dropwizard. Setting up Dropwizard was a breathe of fresh air in the Java world.

If you can swing it for your project, I would suggest trying to sidestep ORM altogether by using a NoSQL database like MongoDB.

Indeed. I recently received a pull request to swap Hibernate into a Dropwizard project with a relatively simple data model that was operated on by some simple JDBI repository implementations. The pull requester obviously spent a lot of time on it, and I felt bad rejecting it, but in total the Hibernate impl would have added several thousand lines of code to something that worked perfectly fine as it was. I really don't understand the need to use complex things just because they're popular.

How do you feel about Spring Boot? It's a very similar concept to Dropwizard: one project that does all the basics out of the box.

Include JOOQ, if that's what you want.

Spring boot is fine, but it was basically created as an answer to Dropwizard, so why not just use the original thing?

It works great for me. I'm not into original-er-than-thou as a way to settle engineering questions.

Reply on news.ycombinator.com