I still hate it.
It gets in my way every day at work. I love to write small, self-contained, testable units. But our code is peppered with @SpringAnnotations. You can never be sure what’s really going to happen.
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.
I stopped following the Java world (beside major releases language changes) but i'm surprised that Java has consistently bred misery. Something in this culture is special.
I do a lot of java development (even in my free time, voluntarily). I find it helps a lot when you avoid the Spring ecosystem, really anything that's popular or buzzword:y. The more buzzwords there are and the more start-ups you find on the project page, the more of your day you spend programming in some more or less undocumented YAML dialect, desperately piecing together snippets you don't understand from outdated tutorials and remarks on stack overflow.
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.
The core language has dramatically improved in the last decade. It’s not exactly a joy to use, but it feels a lot more pleasant than the XML-ridden, 200-char-line-length monstrosity we used to have in the 00s.
Used it non-stop for ~3 years at Pivotal Labs. Moved elsewhere and haven't touched it once. Don't miss it in the slightest. It turns out it just doesn't actually do anything you need that you can't easily do yourself.
I like Spring, Spring Boot is good, and the libraries do stuff that you'll need (while maybe you don't realize whether you'll need it yet).
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.
Caveat: I always avoid DI frameworks / libraries if possible. I just add an AppContext to all of my projects, then write "10,000 new()'s" in one place. That is my wiring. That said, I don't want to hate on people who are productive with DI frameworks / libraries. There is more than one way to do it well!
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!
It's been a while since I last was experimenting with them. I did try Guice briefly, but I stopped for some reason that I don't recall now. Perhaps I should have given it more time. Dagger I tried in a bit more detail, and I found the code-generation aspect of it to be unpleasant and not sufficiently abstracted. I don't know if that could have been addressed by IDE configuration, plugins, etc, but I had to stop working on that project.
It is interesting that you wrote <<I don't know if that could have been addressed by IDE configuration, plugins, etc>>. This is another thing that I don't like about DI frameworks. Usually, they require heavy IDE integration. (I recall this is less true for Guice.) Don't get me started about old school Spring XML...
We have a good time with it in our work. We don't use everything it has to offer, but we do use dependency injection, Spring MVC and JMS. We write testable classes, we new them up in @Bean methods and group them together in @Configuration classes. Everything is modular - you want to use our in-process message bus? Just @Import the configuration class. You want to include Jetty and use MVC? Just @Import the configuration class, you can set a couple of properties and authentication is enabled using our in house SSO.
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.
Not had the bad experiences that other people have had with Spring. I'm currently at a Java/Kotlin place that prefers lightweight frameworks. A lot of time has been invested in reinventing stuff Spring already does and does better.
I really feel like people often compare long-running projects with ill-defined/ever-changing requirements that churned through 100s of developers with some trivially small-scoped new microservice written in Y that can be written in 2 months by a single dev.
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.
> 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 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.
Well, what is the alternative? There is a minimum requirement we really should demand from any developer worth their money. Sure, there are plenty that are not too good with the base language either, but we really shouldn’t program in Comenius Logo, should we?
It really isn't that hard and gets even better as you incorporate tools like lombok and mapstruct. There's very little programming to do and with testing I barely bother starting my local docker containers before kicking off pipelines to try in the larger org
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.
Spring had me at dependency injection and application.xml then lost its marbles and we had to separate. I'm very happy with Clojure and/or Vert.x ever since.
Spring Boot is squarely down that road, too. It's no longer XML files, but YAML is no better. And it's impossible to find out which part of the magic is connected where, governed by which values etc. And when it fails, it's impossible to say why because it's all magically autowired and hidden.
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 cannot find that doc again but there was one with like 14 different places from which Spring Boot can read all its configuration from. No wonder it is hard to configure!
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.
The docs you're looking for is the externalized configuration section.
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.
> 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 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.
This is REALLY old. Spring is completely different. Yes it has it's problems but Spring Boot is still an excellent framework that has no serious rival in breadth/depth/ease of use balance.
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.
Quarkus had a really annoying static only DB layer which turned me off.
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.
I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy.
The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection).
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.
Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
The point is that most newbies don't understand the ramifications of JIT and AOT.
And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks.
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.
I feel you about that startup time garbage. I did end up working on a GraalVM based Spring Boot app that was super cool as part of our business requirements were taking in user provided Python and Javascript code for execution and executing that code on incoming events, sort of like a rules engine.
Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place.
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.
My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today.
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).
Spring works with everything and scales horizontally really well. It can play with every framework and has many engineers/knowledge around it.
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.
Yes it uses Hibernate. The integration through Spring Data is seamless. Also caching isn't just L2 Hibernate cache. It's external caching layer, integrations with Redis/memcached etc.
It provides encapsulation for all of these elements that you don't have to do on your own.
Considering this conversation branched from "What does Spring offer you there that you can't do with plain old Java?", I'm not so sure that's the case.
>> What does Spring offer you there that you can't do with plain old Java?
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.
I mean you do realize that many complex web apps use multiple frameworks for different things, right? Personally I don't like Java and haven't used spring, but take a modern web app and you could be using something like express/fastify, react + next, an ORM, a schema validator, and quite a bit of other domain specific pieces of functionality.
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.
Sure, you use a lot of frameworks - in parallel. But that's not what happens in Spring land. Instead, you get one framework (Spring) offering you an abstraction behind which another framework lurks, for things as large as say an ORM. Something that complex can of course not be hidden behind mere 1000s of Java interfaces, it all leaks horrendously and you find yourself "reaching through" the layers.
Just from my experience, its flexibility and feature set. Some points I find relevant (specific to Spring Boot):
- 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.
Given your comments about your Spring Boot 'bread and butter', it looks like you changed to Python & FastAPI. If so, why? Was it due to a reduction in overall complexity (despite the apparent rise in line of code)? Curious, thanks.
The entire standard including all the dozen vendors shipping products occupy about 10-20% of the market based on our stats. Spring dominates the market. It's been around longer than Jakarta and influenced it a lot. Since that's made of multiple implementations there are advantages and disadvantages involved.
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.
Yes, Spring is so ratched barely anyone starts a project with it these days [citation needed]. Today "Spring" really means "Spring Boot" which is "fine" until you start to live the sugar-water scene from Men in Black and realize is still Spring all the way.
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.
Spring Boot DI seems like a crutch for bad design decisions. You make these things called Beans and make them globally accessible from anywhere in your application. I won't lie that Spring Boot for backend APIs is really convenient though, after 6 months or so of figuring out how all the magic works.
>Constructors seems like a crutch for bad design decisions. You make these things called functions and make them globally accessible from anywhere in your application
I know allocating memory is haram for some, but DI is basically just moving constructor calls up one level
Show me a complaint about "dependency injection" as a concept, and I'll show you someone who does little or no unit testing.
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.
Went to a Spring conference a dozen years ago. It was positioned as Javas a answer to Ruby on Rails.
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.
Depends on the enterprise. We don’t use it and we’re pretty big. Many other teams here don’t, either. Some do — it’s a big place.
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.
> For all the hate Spring gets, it’s extremely widely used in the enterprise. Not sure why?
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.
> There are many people who don't have any problems with Spring. They might not love it but they don't hate it also.
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.
I recently inherited some spring projects after not having worked with it in many, many years. Apart from "it's all still xml"... I don't see why it would be worse than other frameworks. This is not "spring is awesome" and this is not "I like it", but it's been easy to work with and I don't hate it... which means it's already better than 50% of all frameworks I've ever worked with (not only Java, actually many languagess)
> For all the hate Spring gets, it’s extremely widely used in the enterprise. Not sure why?
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.
Usually, in the traditional enterprise, this kind of technical decision is not taken by the people who will have to actually use the tools.
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.
I'm not a Spring expert, but from my time working in it, Spring is designed with best practices as default config values.
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.
I have to agree on everything that author has stated. I also hate Spring with all my heart. I have hated it 10 years ago, now got onto a project that is using Spring Boot and hate it again.
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...
Java annotations are terrible to reason about. Once you get a hang of them, then it's somewhat easier. That being said, Spring takes these annotations to the next level of complexity. Spring boot just makes this more difficult to reason about with added annotations. Anyone who states that Spring annotations are just 'abstractions' and that's how software is built is welcome for a healthy argument.
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);
}
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.
I doubt that a hello world could meaningfully compare the two.
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.
I have found out that as soon as you describe your backend as Spring(Boot) application you have already failed at integrating and using Spring(Boot). Ideally, Spring should be extremely thin layer on top of your java application with, ideally, one-line controllers delegating tasks to your services and custom bean factories where you manually wire your services. Also, your java application should not have any Spring related annotations and dependencies. This really shines in hexagonal architectures where Spring is outside and is just used as input/interface to an application.
2014 is a geological era ago.
I like Spring Boot. In literally one day I built from scratch an app to expose a REST API, schedule a job, publish and consume to/from Kafka, do CRUD from/to CassandraDB without writing CQL. It's `the` RAD framework, without being a RAD.
Maybe there are framework that do just the same with the same effort and capabilities, Spring has the advantage to support and be supported by basically everything.
Yes, it has a lot of black magic, but I learned a lot reading its code when I had to.
One of the points that really resonates with me is magic annotations. When I learned spring I had trouble really understanding these magic annotations because all I did was add a comment, not direct code to do something. I've had similar issues with a typescript express JS framework that is slipping my mind. I spend all day trying to tell the code exactly what to do, so it's less than pleasant to turn on annotations that do things automagically without me explicitly telling it to do so.
This article seems to attract Spring sceptics or even haters. Spring is not that bad.
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.
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).
My biggest issue with Spring was, and likely still is since it hasn't been that long, the documentation around annotations. If a framework is going to go all in on magic annotations to define things, the documentation surrounding those annotations better be really good so people can learn how to use them properly and how they work so you can debug issues when they occur. However my experience with Spring was that finding any good documentation was impossible except for very basic understanding of a select few annotations.
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.
> Complexity : When interviewing candidates the most common answer to "any pitfalls to Spring?" is that it has a steep learning curve. Whether or not that's true is another discussion for another day,
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?
105 comments
[ 3.1 ms ] story [ 177 ms ] threadAlso 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:
[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.
But I am management here until I leave ;)
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
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.
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.
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
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.
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.
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.
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.
https://spring.io/projects/spring-cloud
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.
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)
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).
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.
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?