Hacker News Reader

Comment by rb808 | Hacker News Reader

I dont think this is true any more, especially with the changes in the last few years.

My beef is with Spring. Spring seems to make simple problems very complicated. Its like you have to learn a second more complicated API on top of the original. Plus when something goes wrong you get some 100 call deep stack trace. I just wish there were more pure Java applications without the Spring magic.

View on HN

I really enjoy using spring boot. My problem with Spring is that it feels like I’m mostly metaprogramming with annotations.

Also I hate that I need to literally use a program to create the boilerplate for a new spring app. And I can’t run my program without special IDE settings.

Weird, I've never really needed to use special IDE settings for my Spring boot projects at all; I can just gradle run my project, maybe with a different profile set in the environment.

This works for me most of the time. I use a program to generate the build.gradle, and then that file builds my project through my IDE. It’s meta all the way down.

I admittedly didn’t spend a whole lot of time with Spring Boot; I mostly did Ops with projects other teams build with the occasional Dev assistance when they painted themselves into a corner. But I’m hoping you might be able to help with a question I haven’t had much of an answer to: I agree there’s a lot of “metaprogramming with annotations”, but I didn’t ever find a great way to dig into an annotation and figure out what the hell it was actually doing, or how. Do you have any pointers for pulling back the curtain?

Edit: for example, Python “annotations” are generally just functions that return wrapped functions/attributes/classes/whatever. Java annotations seem significantly more “magical” than that.

Java annotations are meta-data, they don't do anything. Actual code which uses those annotations is located elsewhere. Usually you can use "Find usages" for a given annotation to find the actual code.

That's what I figured... it seemed like a lot of things didn't really take effect until something else happened at runtime. It seemed to me (as a seasoned developer with almost no Spring Boot experience) that there was a lot of mysterious magic there that was great until it didn't work, and then it turned into a debugging nightmare (e.g. stack traces that don't, at all, mention the code where the error exists).

I, personally, despite modern trends, don't like Spring Boot. It was never a big issue for me to configure required beans manually. Spring Core reference has all the necessary examples to cover it.

I guess, Spring Boot makes sense, when you're producing a lot of little web applications with microservice architecture, so copying over that manual configurations can become burden. My applications are monolith and last for many years, so it's not an issue for me to spend some time configuring everything as I need it and it's always visible and obvious what's happening.

None of those things are true.

For example for a rest service, https://spring.io/guides/gs/rest-service/ has everything you need to get started. A simple pom with a few dependencies, and a main class that invokes SpringApplication.run. You can just invoke this main class from your IDE like any other java application.

If, like 99% of Spring Boot use cases, you're implementing "microservices" you should look into Javalin[1]. Javalin will forever sour you to Spring Boot the first time you try it. No annotations in sight, no code generation, no special IDE support involved, no multi-page stack traces, no POM gymnastics, no magic. With Java 11 type inference the boilerplate is reduced to near parity with Kotlin.

[1] https://javalin.io/

I can identify myself as a strictly Java developer (nowadays) and my experience with Spring can be summarized as either:

> I imported that autoconfiguration library and everything works!

> Damn it, the imported autoconfiguration library does not work (or I need to change something), now I have to spend a day around Spring docs and stackoverflow to find how to get it working. Than I have to create a new class, override some random methods and inject my ugly code which feels like a hack now...

Just read the source. You can jump to the implementation of the autoconfiguration in your IDE, and they're usually only a dozen lines or so of bean creation.

This hits home. A lot of my work seems to be mopping up the mess that developers created by doing the former and applying the latter. Autoconfiguration is great for quick demo-days and a literal cancer for everything else.

Frankly, after some recent development on ES6 + node + express, I'm starting to question whether staying on Spring + Java is worth it.

I recall a veteran software developer commenting back in 2000 that a class written in Java was less than one third the length of the same one written in C++, so it's compactness definitely fueled it's popularity.

Since then, J2EE and EJB led to a lot of boilerplate and now everyone thinks class and member names in Java have to be at least three or four words long.

I'm always suspicious of people who offer opinions about Java, but then mention "J2EE", a term which has been obsolete since 2006.

Yep. And JavaEE that came after has actually made things a whole lot better. Idiomatic JavaEE can easily be <10% boilerplate.

The boilerplate isn't just in writing an individual class, though. It's also in the extra classes and interfaces that you might not create in C++.

And I wonder how much of the "compactness" you describe is simply because of Java's library. Library calls are very compact; having to write the code yourself (because your ecosystem doesn't have that library) is much more verbose.

> you have to learn a second more complicated API on top of the original

... that also doesn't actually benefit you in any tangible way.

Have a look at http://sparkjava.com/. Very simple and pure.

Have you tried Spring Boot? It reduces lots of the "complicated" stuff to declarative annotations and will provide you with very reasonable defaults for most use cases.

I dislike Spring "at the margin". I do prefer Spring Boot because it's less Spring-like than Spring.

Annotations often bring with them implicit, hard to debug, "magic" behaviour. I prefer boilerplate over annotations.

Spring seems to make simple problems very complicated.

This. My god, this.

Reply on news.ycombinator.com