9 ms·

I hate Spring (2014)

58 points by hashhar 4y ago

lizardactivist 4y ago
8 years later, how do people feel about Spring today?
- Hackbraten 4y ago
  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. If I had my way, I would rip it all out.
  - agumonkey 4y ago
    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.
    - marginalia_nu 4y ago
      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.
      - agumonkey 4y ago
        Spring is still the first name that comes with Java jobs (from my limited sample). What features / libs do you enjoy (design/perf/safety) ?
      - mosdl 4y ago
        I've found using just jersey libs tends to give me enough power while being maintainable for WebApps. Add your own annotations when needed, etc
    - Hackbraten 4y ago
      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.
      - agumonkey 4y ago
        I saw that, that's why I'm surprised spring still ~~grams~~ harms devs. I thought the culture evolved too.
        Hackbraten 4y ago
        > spring still grams devs Apologies but English is not my first language. I can’t find “to gram” in any dictionary, including urbandictionary. Care to explain?
        agumonkey 4y ago
        finger failure on my side, I meant "I'm surprised spring still harms devs"
  - codebolt 4y ago
    What about Spring4Shell, isn't updating at this point pretty much a necessity?
    - Hackbraten 4y ago
      It is. We’re paying the price right now, and justifiably so.
- GlennS 4y ago
  I haven't worked with it in almost that long, but I still hate it quite a lot. 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
  - ogogmad 4y ago
    2. Mediawiki Visual Editor / OOJS UI I find this helps with adding citations. I don't know why you'd fuss over something that seems easy to learn and easy to ignore. [edit] I had to look up OOJS UI. It appears I hadn't understood your comment.
    - GlennS 4y ago
      Ah yes, sorry, I was very unclear there. Mediawiki Visual Editor is fine to use. It's not fine to make plugins for.
- twic 4y ago
  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.
  - pandemic_region 4y ago
    > It turns out it just doesn't actually do anything you need that you can't easily do yourself. That's neither a productive nor a cheap approach to software development.
- amoe_ 4y ago
  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.
  - throwaway2037 4y ago
    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!
    - amoe_ 4y ago
      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.
      - throwaway2037 4y ago
        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...
- bloat 4y ago
  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.
- qlm 4y ago
  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.
- kaba0 4y ago
  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.
  - Ensorceled 4y ago
    > 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.
    - kaba0 4y ago
      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?
- smrtinsert 4y ago
  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.
spacemanmatt 4y ago
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.
- smrtinsert 4y ago
  I see into your apps future. It's 4 years from now. You've long since left and management has decided - it's time to port to spring boot
  - spacemanmatt 4y ago
    You're not wrong. But I am management here until I leave ;)
dmitriid 4y ago
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.
- js8 4y ago
  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.
  - kaba0 4y ago
    Spring is not that hard to debug if you look at the logs. It is pretty exact in what is missing for example.
  - papercrane 4y ago
    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. https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html https://docs.spring.io/spring-boot/docs/current/reference/ht...
- davedx 4y ago
danjac 4y ago
The industry, thankfully, has moved beyond XML configuration hell to the sunlit uplands of YAML configuration hell.
invalidname 4y ago
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.
- konradb 4y ago
  Micronaut or Quarkus seem like good competitors, does Spring Boot have the edge over them?
  - krzyk 4y ago
    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.
    - jxi 4y ago
      It has to be static or AOT compatible to compile to native with Graal.
    - 4y ago
PedroBatista 4y ago
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.
- joshlemer 4y ago
  What was Play's strategic mistake?
  - PedroBatista 4y ago
    Scala. 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.
recursivedoubts 4y ago
the jvm is screaming out for a rails-like web framework that keeps things simple 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
- pea 4y ago
  Play 2 was all fun and games until you needed to parse JSON
- erik_seaberg 4y ago
  Isn’t Grails supposed to be that, using Groovy’s dynamic dispatch and monkey-patching the way Rails used Ruby?
yellow_lead 4y ago
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.
- bberrry 4y ago
  Taking a dependency as part of composition is quite different from being "globally accessible" in my opinion.
- ohgodplsno 4y ago
  >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
- StevePerkins 4y ago
  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.
victor106 4y ago
For all the hate Spring gets, it’s extremely widely used in the enterprise. Not sure why? 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
- yen223 4y ago
  If you absolutely positively need to use Java, usually because of talent reasons, Spring is one of the easiest ways to get a web service up quickly.
- treeman79 4y ago
  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.
- signal11 4y ago
  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.
- pritambarhate 4y ago
  > 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.
paol 4y ago
Someone put (2014) in the title please. Some of this information is outdated.
hussainbilal 4y ago
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.
szastamasta 4y ago
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-repositoryeventhandler-not-running-when-controller-is-added 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...
- deepGem 4y ago
  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); } @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 https://spring.io/projects/spring-cloud
kklisura 4y ago
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.
The_rationalist 4y ago
albertopv 4y ago
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.
- albertopv 4y ago
  Downvoted. If even a simple post like this is a problem, I can't be part of HN community anymore.
  - caladin 4y ago
    I appreciated and upvoted your comment!
f1yght 4y ago
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.
cryptos 4y ago
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/reference/html/core.html#beans-java-basic-concepts 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/spring-framework-reference/kotlin.html#bean-definition-dsl 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/ 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)
jicea 4y ago
I work on a medium Spring app (~250,000 loc). 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).
xboxnolifes 4y ago
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.
alipitch 4y ago
> 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?

58 points by hashhar 4y ago

lizardactivist 4y ago

8 years later, how do people feel about Spring today?

Hackbraten 4y ago
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. If I had my way, I would rip it all out.
- agumonkey 4y ago
  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.
  - marginalia_nu 4y ago
    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.
    - agumonkey 4y ago
      Spring is still the first name that comes with Java jobs (from my limited sample). What features / libs do you enjoy (design/perf/safety) ?
    - mosdl 4y ago
      I've found using just jersey libs tends to give me enough power while being maintainable for WebApps. Add your own annotations when needed, etc
  - Hackbraten 4y ago
    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.
    - agumonkey 4y ago
      I saw that, that's why I'm surprised spring still ~~grams~~ harms devs. I thought the culture evolved too.
      - Hackbraten 4y ago
        > spring still grams devs Apologies but English is not my first language. I can’t find “to gram” in any dictionary, including urbandictionary. Care to explain?
        agumonkey 4y ago
        finger failure on my side, I meant "I'm surprised spring still harms devs"
- codebolt 4y ago
  What about Spring4Shell, isn't updating at this point pretty much a necessity?
  - Hackbraten 4y ago
    It is. We’re paying the price right now, and justifiably so.
GlennS 4y ago
I haven't worked with it in almost that long, but I still hate it quite a lot. 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
- ogogmad 4y ago
  2. Mediawiki Visual Editor / OOJS UI I find this helps with adding citations. I don't know why you'd fuss over something that seems easy to learn and easy to ignore. [edit] I had to look up OOJS UI. It appears I hadn't understood your comment.
  - GlennS 4y ago
    Ah yes, sorry, I was very unclear there. Mediawiki Visual Editor is fine to use. It's not fine to make plugins for.
twic 4y ago
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.
- pandemic_region 4y ago
  > It turns out it just doesn't actually do anything you need that you can't easily do yourself. That's neither a productive nor a cheap approach to software development.
amoe_ 4y ago
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.
- throwaway2037 4y ago
  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!
  - amoe_ 4y ago
    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.
    - throwaway2037 4y ago
      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...
bloat 4y ago
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.
qlm 4y ago
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.
kaba0 4y ago
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.
- Ensorceled 4y ago
  > 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.
  - kaba0 4y ago
    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?
smrtinsert 4y ago
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.

spacemanmatt 4y ago

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.

smrtinsert 4y ago
I see into your apps future. It's 4 years from now. You've long since left and management has decided - it's time to port to spring boot
- spacemanmatt 4y ago
  You're not wrong. But I am management here until I leave ;)

dmitriid 4y ago

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.

js8 4y ago
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.
- kaba0 4y ago
  Spring is not that hard to debug if you look at the logs. It is pretty exact in what is missing for example.
- papercrane 4y ago
  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. https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html https://docs.spring.io/spring-boot/docs/current/reference/ht...
davedx 4y ago

danjac 4y ago

The industry, thankfully, has moved beyond XML configuration hell to the sunlit uplands of YAML configuration hell.

invalidname 4y ago

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.

konradb 4y ago
Micronaut or Quarkus seem like good competitors, does Spring Boot have the edge over them?
- krzyk 4y ago
  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.
  - jxi 4y ago
    It has to be static or AOT compatible to compile to native with Graal.
  - 4y ago

PedroBatista 4y ago

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.

joshlemer 4y ago
What was Play's strategic mistake?
- PedroBatista 4y ago
  Scala. 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.

recursivedoubts 4y ago

the jvm is screaming out for a rails-like web framework that keeps things simple 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

pea 4y ago
Play 2 was all fun and games until you needed to parse JSON
erik_seaberg 4y ago
Isn’t Grails supposed to be that, using Groovy’s dynamic dispatch and monkey-patching the way Rails used Ruby?

yellow_lead 4y ago

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.

bberrry 4y ago
Taking a dependency as part of composition is quite different from being "globally accessible" in my opinion.
ohgodplsno 4y ago
>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
StevePerkins 4y ago
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.

victor106 4y ago

For all the hate Spring gets, it’s extremely widely used in the enterprise. Not sure why? 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

yen223 4y ago
If you absolutely positively need to use Java, usually because of talent reasons, Spring is one of the easiest ways to get a web service up quickly.
treeman79 4y ago
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.
signal11 4y ago
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.
pritambarhate 4y ago
> 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.

paol 4y ago

Someone put (2014) in the title please. Some of this information is outdated.

hussainbilal 4y ago

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.

szastamasta 4y ago

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-repositoryeventhandler-not-running-when-controller-is-added 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...

deepGem 4y ago
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); } @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 https://spring.io/projects/spring-cloud

kklisura 4y ago

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.

The_rationalist 4y ago

albertopv 4y ago

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.

albertopv 4y ago
Downvoted. If even a simple post like this is a problem, I can't be part of HN community anymore.
- caladin 4y ago
  I appreciated and upvoted your comment!

f1yght 4y ago

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.

cryptos 4y ago

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/reference/html/core.html#beans-java-basic-concepts 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/spring-framework-reference/kotlin.html#bean-definition-dsl 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/ 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)

jicea 4y ago

I work on a medium Spring app (~250,000 loc). 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).

xboxnolifes 4y ago

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.

alipitch 4y ago

> 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?