I hate Spring (2014)
samatkinson.com
samatkinson.com
It doesn't use XML anymore (although it can) it's all annotations. You can code to it with Kotlin if you don't like Java and can do some pretty cool things there. Java 17 has records and many other cool things that make the code very terse.
Also Spring Boot isn't a "Framework for a Framework" as the article claims. It's a convention based package of the applicable tools. That simplifies a lot of the development process and makes everything far more accessible.
The basic Spring Boot stuff is super simple. However, I will agree there's a LOT of complexity under the hood. That's a feature, not a bug. You need depth if you want to build something that scales in the enterprise and Spring does scale well.
I don't like DI very much. I would prefer a more direct framework with imperative programming which IMO fits better with Java. But all of them don't have the traction and breadth of Spring Boot which is why I use that. So I'm pretty happy with it.
Spring Data was way better with the interfaces.
I don't know if Quarkus changes recently (well, in 2-3 years) in that regard.
And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.
That's a huge benefit.
Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it.
Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples.
But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.
You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap".
Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
But to chime in, I much prefer the Quarkus/Vert.x ecosystem if I have a choice, due to developer experience and the overall ergonomics.
I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected.
I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem.
I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc.
Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things.
There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring.
This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently.
It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing.
Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.
Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).
This feels like "Mongodb is webscale". What specifically does Spring do better than its competitors?
Specially it has builtin caching, transaction management, DB access etc. But it connects to many external services for all of those seamlessly. It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows.
Aren't these mostly features of your data layer e.g. Hibernate?
> It abstracts all the layers so you can easily replace everything under the hood with full compatibility as your business grows.
Java is a perfectly capable language for implementing abstractions. What does Spring offer you there that you can't do with plain old Java?
It provides encapsulation for all of these elements that you don't have to do on your own.
A concise framework where all components talk the same language across the full stack.
Spring is many things, but it's not a "concise" framework by any means.
Well nothing. Since Spring it written in Java, anyone else using Java can do all of those things.
The things is Spring already does all these things and it does them well. It's well tested and well supported. Most people don't want to do all of this from scratch. So they need a framework anyways. So they choose Spring because it's the leading framework in Java world.
There are a lot of people who already know Spring and can become productive in a Spring codebase fairly quickly.
Yes. I was talking about Spring Boot there. Yes, that wasn't clear. Spring is a framework and some of the elements within it abstract other tools some of which are frameworks in their own right (e.g. JPA/Hibernate). There are many abstractions but Spring sort of unifies them to a single "story" you can work with. JPA under Spring makes a lot more sense with the JPA Repository etc.
Ofc these aren't all "frameworks" in the traditional sense, but that line is often arbitrary and I think this interpretation of OP's usage of the word is the most generous one.
- If I'm building a web service I can choose if I'm using a thread based sync approach or a reactive non blocking approach.
- Extremely opinionated and well thought out configuration management. Think of Viper from Go, or config with Pydantic from Python, just turned to 11.
- I can add support for many different data stores directly with the framework. Psql, Elasticsearch, Cassandra... the list goes on.
- Making critical sections of code, especially around data stores can usually be made transactional with a single annotation and managing the lifecycle of that transaction is similarly convenient.
- Robust caching solutions that are brain dead easy to add. I stress the robust adjective.
- Built in health metrics and ability to refresh configuration while running and rewire itself.
- Can speak OAuth2.0 out of the box.
- You can connect the logger with a little bit extra configuration to additionally spit logs out to something like Kafka with no extra code on your part.
This list alone doesn't seem super impressive but having built on things like Python+FastAPI, Node+Express/Hapi/Apollo, and Rust+Actix, while you can do all of these things, they are not generally just there, ready to use, and suitable for production.
My bread and butter used to be Spring-Boot w/ Lombok and I could take a service from inception to running in prod with fewer lines of code than I currently can with Python and FastAPI.
Extra Note: There will always come a time when developing with spring where you will shout to the high heavens about something the framework does a particular way or something you misunderstood. That is part of the pain of when the framework does so much for you.
What about Jakarta EE?
Don't get me wrong. I like Jakarta, Quarkus et al. They bring a lot to the table and the cross pollination with Spring (which goes both ways) is great. But if you want to hire someone the chance of them having real world experience with Spring is much bigger than them having similar experience with Jakarta EE. If they have Java EE experience it isn't as applicable.
Not really, Jakarta came from Java EE, which came from J2EE, which was released early 2000. Spring is from 2003 and started essentially as a framework for J2EE.
> and influenced it a lot.
It goes both ways.
Spring for instance started calling code "configuration" and wanted us to put it in huge amounts of XML. Java EE started with using annotations for bean definition and injection. Spring was initially against this idea, arguing configuration should be external and not embedded in the code. Citing that you would otherwise needed to recompile your code in order to change configuration.
Many years later Spring projects barely use those huge XML files anymore and its all autowire.
J2EE has been around for a while. But it was RADICALLY different and was pretty much horrible. Then it copied many of the AOP aspects of Spring (inject etc) as it evolved. The current standard of Jakarta looks more like Spring than its original form. As such most of the implementations of the standard are much newer.
So yes, the standard origins are old but that's not a relevant metric.
I said, cross pollination. E.g. just recently the Spring Native example is totally an example of Spring copying a great idea from the Quarkus et al.
It has nothing to do with XML, it's that Spring is full of interdependent, classpath and annotation driven magic that no one knows how will wire things up before runtime. A lot of stuff is just a plain string in annotation value that you cannot find or refactor, because it's not code.
Worst of all, there's usually no gain from using it. You usually trade 1 line for 1 line - instead of using compile time checked method calls, you type a cryptic annotation that is validated at runtime.
There's a lot of really bad solutions to problems there, like Spring Data Rest or auto generated repositories that force you to have setters for all fields in your models. Or stuff that simply does not work: https://stackoverflow.com/questions/34210903/springdatarest-...
Sometimes, after few hours of fighting it's way of doing things I just re-write what it supposed to do in few lines of Java code. And it's usually faster to write and easier to understand.
Sorry, I just cannot find any love for it. I really hate it when I have to write another AbstractAnnotationConfigDispatcherServletInitializer...
There are much better web development alternatives such as Javalin.
Compare this
import io.javalin.Javalin;
public class HelloWorld { public static void main(String[] args) { Javalin app = Javalin.create().start(7070); app.get("/", ctx -> ctx.result("Hello World")); } }
to
@SpringBootApplication @RestController public class DemoApplication {
public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); }
@GetMapping("/hello") public String hello(@RequestParam(value = "name", defaultValue = "World") String name) { return String.format("Hello %s!", name); } }
However, Spring cloud, has all the necessary distributed features built in. While I haven't used these, not having to write code for these is a god send. Load balancer - Check Service mesh - Check Circuit breaker - Check
Heck, they have even included all Netflix OSS components. So this alone is worth the pain of living with annotations.
What about a complex web app with many more http endpoints? Some of them having parameters that should be queried from, validated and converted from the URL? It is still the same amount of lines in Spring. Declerative does win in my opinion in this case.
Not to mention that when there is an issue, you get a 30+ line stack-trace that usually tells you nothing useful unless you've had the same issue before and can correlate the error with its solution.
It can be a pain in the behind but once you learn the Spring way of doing things it ain’t so bad.
Worked with a lot of frameworks and the fact is every requires you to learn the way to think about how to work with that framework
Almost every speaker talked about they wished they could use ROR but work required Java. So this is that they could do. I could hear great pain leaking from their souls.
I suspect a lot of enterprise devs inherit the decision, or move from project to project and don’t want to reinvent the wheel, and want a framework that’s portable (ie take their skills to another company), can hire for, etc.
We don’t because managing our dependencies is important for us. Also we have a long-lived “product” codebase so keeping it simple pays off. Concrete advantages for us:
Faster startup, smaller footprint, easier to reason about dependencies, and also the code is simpler, even for new joiners — anyone with a decent knowledge of Java will pick it up quickly.
It doesn’t tick the “has worked on Spring” checkbox but it’s not like it’s made us unemployable. People do leave from time to time.
There are many people who don't have any problems with Spring. They might not love it but they don't hate it also. They just care about getting their tasks done and getting paid. They also don't hang around on the Hacker News or write blogs or tweet. so their point of view isn't discussed much.
A lot of “enterprise” developers don’t care. There are many reasons for this, some positive, some negative.
But one outcome is that Spring becomes self perpetuating. Eg a new tech lead inherits a Spring project. Then at hiring time it becomes easier to ask for Spring experience. This drives an industry perception that you gotta know Spring.
The costs — overly complicated code, ridiculous startup times & containerisation cost, messier dependencies, are often ignored or hand-waved away saying “this is the cost of enterprise”. (It’s not.)
This is not to say Spring is inappropriate in an enterprise. What I am saying that many enterprise teams do not often have that cost/benefit conversation, instead they reflexively adopt Spring. That is the real problem.
It mirrors the way the enterprise works, with a myriad of services where no one knows what the other is doing and that has to work together through some kind of magic.
> Worked with a lot of frameworks and the fact is every requires you to learn the way to think about how to work with that framework
It is not my experience. Only "action at a distance" type frameworks are like that, and Spring is all about that. Frameworks where you are mostly just calling functions are usually much easier to get into with just a bit of example code and manpage-like documentation.
There are layers of technical decisions, progressively removed from the actual job of delivering applications.
There are constraints like the utter horror enterprise has of the idea of NOT treating developers live commodity interchangeable cogs. There is careerism, there are outsourcing companies trying to position themselves as "specialists in X". There are naive technology executives and managers that are easily fooled by tool vendors promising the nirvana of code so easy to write that you could possibly fire all your experienced developers and hire some juniors folks out of a Bootcamp. There is the manager trying to be promoted by selling up this bullshit... And we could keep on discussing this for days, as the enterprise is an endless sea of cargo cults, insanity and sheer idiocy.
Edit: Well, the whole "no idea how to configure a thing" is the common refrain of any and all Java frameworks. Pray that your IDE has enough smarts to autocomplete something for you.
I don't think it should be a complicated problem. On startup, the framework should be able to tell you in a log file, what are all the places it read each configuration item from, and which value was finally used.
I am big fan of design philosophy where the computer tells you how it understood your commands (this includes configuration), before it does a thing.
14 seems like a lot, but in reality you'll like use only a couple of layers in a production deployment.
The reason there's so many is that list is exhaustive and includes sources only relevant to development and testing, as well there are a number of ways you may want to inject environment specific configuration values (command line flags, system properties, jndi, environment variables, etc..), you would normally just pick the one that made sense for your deployment environment.
https://docs.spring.io/spring-boot/docs/current/reference/ht...
I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed.
What a mess
First, XML configuration in Spring is mostly a thing of the past. Most applications are configured with annotations and component scan these days. While it is true that there is some magic in it, it is relatively rare to cause problems. With proper tooling like IntelliJ Ultimate it is mostly easy to manage and understand. If that still feels too magical, you can use a Java API to manage your classes: https://docs.spring.io/spring-framework/docs/current/referen... Even nicer in the Kotlin edition: https://docs.spring.io/spring-framework/docs/5.0.0.RELEASE/s...
> Importing other Spring files
That sounds like mixing different projects or poor API design.
> Spring is now so complex that it has it's own framework, Spring Boot
That is not true as such. Spring Boot is not an abstraction over the Spring Framework. It is more a convenience layer with useful defaults and some auto-configuration.
From my experience Spring brings some advantages:
- Quick start with https://start.spring.io/
- Auto-configuration of several frameworks like Hibernate, Spring sets up all the project infrastructure for you
- Transactions are provided out of the box
- Useful additions like metrics can be added almost without effort - Good support for integration tests
- Easy to use AOP
- Powerful dependency injection (for example the support for generics is pretty good)
Some good concepts and cool ideas, not gonna lie, but when that rubber meets the real road things turn ugly or at least mushy.
Too bad Play Framework made a strategic mistake in V2 ( IMO ) and now it's pretty much dead.
Javalin it's pretty cool but I'm not sure it's for the Spring crowd, Quarkus seems to be the new hotness for them with the migration to micro-services - I think it will turn into another multi-year BDSM session just like Spring but only time will confirm that.
Play was a very successful Java framework, with Play2 they went full Scala while still maintain Java support, theoretically that's fine but in practice we all know one has to be the step-child.
Of course we have to take into account the context of the time, back then Scala was the hot ticket and Java sucked because it wasn't "functional programming" capable, but in practical terms they ended up splitting their resources and a large part of their Java user-base left. Once the Scala hype died down, the framework also died down.
In a more nuanced angle, Scala wasn't the root cause. The root cause was losing focus and do other things too differently from what made the framework successful and that included implementing it in a new language.
There were many problems on the ground just like every other framework, 2 that come to mind:
- Horrible compile times with Scala, if you happen to have a some big project with 100+ classes ( which means real World ) it would be comically slow. Yes incremental compilation, yes it got slightly better over the years but it's still slow.
- Big and many breaking changes every time you upgraded, the "WebService/WS" part changed completely pretty much every update 4 or 5 times ( from 2.2 to 2.6 more or less ). In general it seems to me they were experimenting a lot and respecting the time and investment of their their users wasn't a priority.
Of course there are even more reasons, like the fate of Typesafe/Lightbend, etc but IMO the Scala detour was a strategic mistake.
Having said all that, Play! is STILL one of the best frameworks in existence for Java today.
But I am management here until I leave ;)
Three years ago, our stack was Spring + Java. Now, we have transitioned our app to Spring Boot and Kotlin and I begin to appreciate this stack. No xml configuration, only code (or, more precisely, annotations that rely on reflexion), Kotlin data class for model, simple controller etc... I quite like it.
I come from a Python backend background with a lot of misconceptions about Java/Spring, and I like that our app can be bundled in a single "fat Jar" with all its dependencies. Much more pleasant (in my option) that the Python deployment story.
One think that I still dislike is the MVC template engines (we use Thymeleaf): they fill "ancient" to me and I would welcome something more "static" (like a Kotlin dsl for instance).
This article was from 2014, and not about CVE-2022-22965 (Spring4Shell) nor CVE-2010-1622. However, the "Complexity" point makes me think about SerDes (Serializer/Deserializer) libraries.
Are there any data binding libraries (deserialization, marshaling, pickling libraries) that do not have the class of weaknesses as the two CVEs (CWEs)? If there are any for Java, can they be used with Spring Boot (Spring Framework)? Maybe there are some for in another programming language?
Also we don’t upgrade because teammates are afraid of breakage. Because of that, we’re now at five different versions of Spring in our app.
If I had my way, I would rip it all out.
As I mentioned in a comment earlier today, frameworks make the easy things easier and the hard things harder. If your needs are to build a really basic CRUD app, then sure, Spring is nice. But since it probably isn't, if indeed you're doing something else more than a hello world TODO app, then it's an unimaginable pain in the ass, and it's a lot easier to cobble together what subset of its features you need from other libraries.
Apologies but English is not my first language. I can’t find “to gram” in any dictionary, including urbandictionary. Care to explain?
I try not to be too fussy about tech overall, but Spring is on my "I won't work with this again" list:
1. Spring
2. Mediawiki Visual Editor / OOJS UI
3. Typo3 2. Mediawiki Visual Editor / OOJS UI
[edit]
I had to look up OOJS UI. It appears I hadn't understood your comment.
Mediawiki Visual Editor is fine to use.
It's not fine to make plugins for.
That's neither a productive nor a cheap approach to software development.
I'm a DI fan and I've found alternative DI frameworks to not work as well as Spring's DI. I'm only talking about Spring's annotation-based configuration.
There are also several good reasons not to like it, though: the errors can be unbelievably confusing, and it's quite hard to get a good mental model of how and why things are done in it.
Real question: When Google Guice came out, there was a hype about it was better than Spring DI. Honestly, I think part of the hype came from their amazing PR, courtesy of "Crazy Bob". Have you tried it, and what did you think? If not, what other DI frameworks / libraries have you tried? Why did you prefer Spring? I am throwing zero share here. I am genuinely curious!
I think modern Spring lends itself very well to making services this way, if you can make the effort to make your application components modular, you can reuse the common stuff and have it interface nicely with the service specific code.
Of course the former will be a disgusting monster compared to that, but that would be the case with any 2 frameworks substituted.
Spring does a shitton of things, because enterprise business project require the strangest things. But it has a clear structure convention and if the developers actually know the platform instead of using the chimp-typewriter technique it does make other devs job easier. I am not necessarily a fan of runtime DI though, but otherwise I think it is a well-thought out framework making the easy thing really easy, and making the hard random godforsaken requirements of businesses possible — many possibly better liked framework forgets about the latter. I would be interested in what others consider a good framework (in any language)
Nonetheless, I would like to see a new framework slowly emerge making use of new java features as much as possible.
I consulted on a enterprise java project that had a few dozen full-time developers and a few consultants, maybe one of the full-timers "knew the platform" and certainly one of the consultants did. By the time I left a year later after finishing my part, I kind of "knew the platform" and the rest of the team was no further along than before.
Counting on people learning a very complex platform is just asking for heart ache.
Spring monoliths used to be hard but that was a long time ago. My advice is this though. If you have an app written to xml spring stay that way until it's eol. Mixing annotations and xml was hairy and made things answers and documentation less applicable.
Wrt the author sounds like some poor decisions were made. Leaking Spring apis is an obvious nono. Even from v1. Second modularization is for pluggability of common apis not for you to version internal software projects. Stuff like that. If you just sit and whiteboard how you should use this thing you'll see it's not that scary. There's no doubt it's a sharp tool which is good right? If someone really needs certain beans to not show up in specific contexts they're glad it's there as a feature and easily implemented.
I'm glad spring and spring boot are available. I've looked at other alternatives and don't consider them in the same league.
I know allocating memory is haram for some, but DI is basically just moving constructor calls up one level
The only real ways to do it are dependency-injecting mocks, or else maybe a Python-style "patch" approach where you're literally overwriting portions of the code under test at runtime. I've seen the latter kinda-sorta work in Python shops, but the former is far more sane.
If you're not only changing config but rewriting templates, then you're already fighting against the framework and deviating from best practices. Don't do that.
My understanding is that if you're regularly rewriting Spring provided templates, then you've likely hit the need for Spring AOP, so the DI magic can be kept manageable.
If you're a consumer and you're hitting this issue (needing to regularly provide own custom templates on the client-side), then you've likely hit the need for Spring Integration on the server-side.
play 1 was kinda that for a while, but it has been superseded by play 2, which went full scala
you never go full scala