Hacker News Reader

Comment by lmm | Hacker News Reader

Spring Boot is setting the Java ecosystem back 10 years. But such missteps aside a lot of modern Java libraries have a more "plain old Java" attitude, and it's now reasonably idiomatic to write Java code in a style that doesn't depend heavily, or even at all, on reflection.

(Myself I'm interested to see how well this handles Scala, since avoiding reflection completely is pretty much the norm there).

View on HN

It's also widening the gap between Dev and Ops. I was a developer for 6 years and started moving towards DevOps and trying to build relationships between the ops teams and the programmers. The programmers are always whining about not being able to use the latest language/tool/library/<<insert flash tech here>> while the ops team are just trying to make the pile of junk they've been handed work.

Spring, and Spring Boot most egregiously, work only to widen the gap between devs and ops. The developers have no idea what a Boot app is doing internally for 90% of its stack. The ops guys just want to stably deploy something that is well understood and supportable when it falls over. Not to mention the memory management headaches it introduces...

I moved away from JS early on in my career because it's mostly a disaster waiting to happen, but now the Java devs have the same potential to output a steaming pile of crap that they don't understand.

> The developers have no idea what a Boot app is doing internally for 90% of its stack.

This is the biggest problem by far with Spring Boot. It’s not just hidden default settings or convention or configuration, it’s entire hidden applications.

> Not to mention the memory management headaches it introduces...

Could you elaborate on this?

I read that as more of a criticism of the ORM/JPA and maybe xml than Spring Boot. In practice it's easy to pull down half the database with an errant "eagerly loaded" collection or attempt to deserialize a giant xml document into an in memory DOM, both of which can exhaust memory and hang jvms with very little information on what happened than an 'out of memory' exception.

We have had app teams whose Spring Boot application leaks memory at a rate that meant we needed to do app restarts once a month, even once a fortnight on occasion. Investigation is then hampered by half of the conversations we have being along the lines of "well we're using Spring Boot so it can't be our problem" and the other half are "it's Spring Boot causing the leak."

The dev team refused to accept responsibility as though they hadn't fought tooth and nail to use Spring Boot in the first place.

Just curious how you're measuring the memory leak in this case? Can you explain how that's being determined?

We monitor just about every aspect of the machines and JVMs that we own. When the Heap graph climbs steadily over days/weeks at a time, i.e. each GC still results in considerably more overall memory usage.

Seconded. Throughout all my time working on Java, Scala and Clojure, I've considered reflection to be a code smell. It's a bit more complicated with Clojure, since it uses reflection to bootstrap the language.

There's a burgeoning ecosystem in Clojure for creating native apps using GraalVM native image

https://github.com/borkdude/babashka is a good place to start

Babashka is a scripting tool that is meant to be compiled with GNI and a great tool but to link your own Clojure app like that a good starting point might be https://github.com/taylorwood/clj.native-image

(or https://github.com/taylorwood/lein-native-image if you are using Leiningen)

Spring Boot is setting the Java ecosystem back 10 years.

How so?

By Spring 4.x it felt like the ecosystem had learned the value of staying close to vanilla Java - annotation-based configuration meant that there would be a (Java) reference to any class that was instantiated by Spring, constructor injection meant that there was less need for Spring-specific lifecycle methods like afterPropertiesSet() and it was more practical to write "dual-use" classes that could be used with or without Spring.

Whereas for me Spring Boot has the same feel as the bad old days of early Spring 3.x - lots of magical constructs that were impossible to understand unless you knew all the Spring specifics. A Spring Boot application will behave completely differently based on just which libraries happen to be on the classpath - the exact same code might start up a tomcat server when run one way and not when run another way - and has a whole host of new Spring-specific things that you have to learn if you're going to understand how your application is behaving.

It increases the distance between the developer and the actual, deployable executable that they output. It's like all these JS libraries that allow you to spin up an app in 20 lines. It's meaningless garbage unless you understand the libraries, but the people who are writing those apps usually just copy and paste the code from somewhere.

I am quite happy that with my hops between Java and .NET, every time I land on a Java project I have been able to avoid it.

Apparently you are not representative of average HN user :/ just kidding..

Well, it is true, specially if you follow my threads regarding games development, or paying for software. :)

Reply on news.ycombinator.com