Comment by traspler | Hacker News Reader

Comment by traspler | Hacker News Reader

Spring Boot really comes away awful in this article (and the one he links in the article). I have mostly worked on projects using Dropwizard and Spring Boot and have come to like some of the easy to use abstractions but I have only scratched the surface of these frameworks, I assume, and most of it I will probably never use. Most of the time it did not matter that much to give the Server a GB more memory but recently we had some real issues with CloudFoundry. To me it seems that it's not possible to somehow magically tweak Spring Boot to behave better. So I came to wonder, what other framework would strike a better balance? Maybe not offer the crazy specialised stuff Spring offers or maybe needing some more work to get something to run but then offer vastly better memory and speed charactersitics?

I guess one way would be to implement the things I actually use myself with less abstractions but that honsetly feels very daunting to me. The Java ecosystem is so vast and between Handling the Requests, DB access (with or without ORM), persistance, caching, security, I really have no clue on where to even start doing something like this myself. If someone more seasoned here has some input, I would be highly interested!

You mentioned Dropwizard early on, in my experience I have found it to be the polar opposite of Spring.

Where Spring is an "everything but the kitchen sink" framework, Dropwizard is just a collection of best-in-class libraries that are easily swapped out if you prefer something else.

I don't get to do so often professionally, but if given my choice of tools ill generally opt for a combination of Dropwizard in Kotlin.

One big drawback of Dropwizard (at least for us) was that it was very problematic to deploy it as a war in a tomcat environment. There is wizard-in-a-box but there were a lot of issues with that as well.

Well, if you're doing microservices you're usually nullifying most of the benefits of this kind of architecture if you're just deploying them on war files on a single application container.

If you're deploying a dropwizard app as a war in tomcat you're doing something a bit odd.

True but sadly project specs sometimes change in odd ways.

Yeah, that's definitely a square peg + round hole problem. Dropwizard is intended to be deployed as a "Fat Jar" and does not need tomcat/tomee.

This is nice because it makes it easier to treat your servers like disposable cattle when (almost) all of your configuration and dependencies live in your easily deployed Jar.

For me dropwizard looks like what you'd get from a room if experienced Java guys picking the best of breed to do one thing and one thing well.

Spring boot feels like it was from a room full of people where there's a guy in the corner with a form of tourettes that makes him keep yelling "Spring! Take the Spring option!"

It just isn't always the best option and sure, you can often switch out for something else but that defeats the point of an opinionated collection of the best available choices.

If you think Spring could make better bundling choices, tell them. They are very open to feedback.

And if they don't qualify as "experienced Java guys" then I don't know who can, short of Gosling.

Agreed. Kotlin + Dropwizard is an interesting approach. How well do Kotlin and Jersey play together in your experience?

Wonderfully, no complaints so far.

You should add the Jackson Kotlin module so you can pass Kotlin data objects around: https://github.com/FasterXML/jackson-module-kotlin

This combination has made me as productive as I've ever been.

> Most of the time it did not matter that much to give the Server a GB more memory but recently we had some real issues with CloudFoundry.

A long-standing difficulty with the Java Buildpack was working out how much memory to give it -- the Garden container engine is particularly ruthless to any process going above the allocated memory limit. I believe it got a lot of attention in v4 (edit: see [0] and [1]).

My personal pet peeve is that the memory quota is identical for staging and runtime. Which means that memory-intensive staging operations force you to have wasteful runtime memory allocations. I mostly noticed this when using Rails apps that pull in Nokogiri -- it gets compiled during staging and often that causes a lot of memory usage.

Disclosure: I work for Pivotal, we do the majority of Cloud Foundry engineering. We also sponsor Spring.

[0] https://www.cloudfoundry.org/just-released-java-buildpack-4-...

[1] https://github.com/cloudfoundry/java-buildpack-memory-calcul...

Thanks for the links. It's good to see that there is ongoing development to improve the situation.

It would still be nice to be have a Spring Boot app work on a 512MB container but even pretty simple ones don't seem to.

There must be more we can do, but I honestly don't feel qualified to say what it is. Ben Hale is the fellow to ask, he's the JBP maintainer.

I've recently toyed with the idea of taking libbuildpack and OpenJ9 and just ... seeing what I can do. But I'm ill-qualified to tinker with either and it's in the pile of fifty kerjillion other sideprojects I want to do.

Reply on news.ycombinator.com