r/java • u/[deleted] • Nov 27 '15
Why I hate Spring
http://samatkinson.com/why-i-hate-spring/22
u/Scaryclouds Nov 27 '15 edited Nov 27 '15
It's your fault if you let implementation details leak out of your interfaces.
As others have already said Spring hasn't been pushing XML configure for years now.
Finally, what is the alternative for handling class dependencies? Neither vanilla Java nor JavaEE offer a superior alternative (indeed inferior). I don't know of any other third party frameworks that do as good of job with class dependencies as Spring or have nearly the support, battle testing, and wide spread acceptance spring has.
11
u/mc_hambone Nov 27 '15
Basically his alternative was to use constructors, i.e., "the thing that Spring aimed to improve".
Also, Spring is not only a DI framework, but a framework to help develop most Java EE-oriented features, yet he doesn't address this aspect at all.
5
u/Scaryclouds Nov 27 '15 edited Nov 27 '15
Also, Spring is not only a DI framework, but a framework to help develop most Java EE-oriented features, yet he doesn't address this aspect at all.
Yup you are absolutely right on that point as well. Not to mention all the other libraries and projects that assist with other common business problems.
0
Nov 28 '15
The guy says he writes his own application context. Because AOP and bean scopes is easy to develop.
1
u/Scaryclouds Nov 28 '15
Yea kinda gave up reading halfway through. Glad I did because that point again only highlights his own ignorance.
37
Nov 27 '15
I stopped reading at XML. Spring hasn't pushed XML configuration for quite a long while (3.0) and some level of Java config has been available since 2.5ish. Spring is on 4.2 with 4.3 (final release) and 5.x coming out next year. Nothing like a bitchfest article from someone living in the past.
Might as well write an article complaining that Java 7 isn't "functional".
5
Nov 27 '15
I stopped reading at XML. Spring hasn't pushed XML configuration for quite a long while (3.0) and some level of Java config has been available since 2.5ish.
It looks like the author recently had to go back and dig through some old projects, though, which makes old pains fresh.
21
u/stormcrowsx Nov 27 '15
Annotations are just xml configuration with a new spin. You magically sprinkle them through your app and they do stuff. Its hard as hell to follow for new comers, its hard to track down later. They break at runtime instead of compile time.
8
u/squishles Nov 27 '15
So did the xml though. They're not immune to static analysis, it's all static final. Just no one's made a good tool for it.
I just like not having to keep two files open.
1
u/superPwnzorMegaMan Nov 27 '15
Scala has compile time checks for dependency injection. This article describes three methods without using a library.
5
u/Scaryclouds Nov 27 '15
That's an issue with Java and its tooling, not with Sprig though. It's not as though you could hope to switch between languages over such an issue either (unless you work for a start up).
1
-2
Nov 27 '15
Not sure what startups you are referring to, all those I've been involved with have moved way too fast to be willing to go back and change tech, as it's fairly little value add for a while. We just start new projects in the other thing we think solves the problem better.
5
u/Scaryclouds Nov 28 '15
That's kinda my point. With well established companies, it's typically difficult to introduce such new and radical changes because all the employees know X language. Whereas with a startup, there is less investment in a given technology.
-2
u/superPwnzorMegaMan Nov 28 '15
Oh but you definitively can, since you can just use your Java code (classes libraries etc) in Scala. seamless integration. You just have to decide to stop writing Java and start writing Scala.
1
u/Scaryclouds Nov 28 '15
I realize Scala can be run on the JVM. Just that getting such a change approved in most larger organizations is difficult.
3
u/vizzoor Nov 27 '15
While I agree you're not seeing the effects until runtime, you should absolutely have enough automated tests in your code to capture those breaks early on.
5
u/stormcrowsx Nov 27 '15
Yeah you should but it doesn't always work out that way. Most codebases I've seen are at best 80% covered or use so much mocking that some runtime errors slip by.
8
u/CubsThisYear Nov 27 '15
But at that point, why bother with static typing at all? If your answer is "unit tests" for everything, you might as well just ditch Java and use Python.
The problem with unit tests is that you can never know when you have enough (please don't say coverage solves this problem). With type-safety you have a universal quantifier. You can only check what your type system allows, but whatever you check you know that it applies to every input your program could ever possibly have. This is incredibly powerful and its not worth giving up to make writing the code slightly easier.
11
u/Zeffas Nov 27 '15
Well, I would argue that this kind of attitude is very narrow-minded. Hear "trigger-word" -> dismiss regardless of content.
Reminds me of two relatives discussing politics and basically agreeing on core things, but when both mention certain keywords in some irrelevant sentences - both get triggered and go into stupidity mode. One immediately labels another as socialist-communist, another labels other right-wing redneck and discussion is over.
In my view article correctly talked about xml and then explained about annotations.
13
u/Scaryclouds Nov 27 '15
But the guy clearly isn't up to date on spring. If he chooses to remain ignorant on a subject he chooses to write about and authoratatively declares he "hates", it becomes hard to take him seriously. Not to mention some of the issues he ran into to aren't issues idiomtic of spring, but idiomatic of poor design. If you choose to make an application and then have its sub-dependencies/modules depend on different versions of a third party library the fault doesn't lie so much with the third-party library but your inability to manage your dependencies.
His criticism of Spring Boot doesn't make any since either. Spring Boot is about containerization of Java applications and handling a lot of the boiler plate of spinning up a new application. Again, this is an issue regardless of what framework you choose to use.
The guy brought nothing to the table and everything in his article suggests he is much less smart than he thinks he is.
-4
u/Zeffas Nov 27 '15
But the guy clearly isn't up to date on spring.
Why? Because he mentioned XML? If so, I believe we are interpreting or reading article from completely different angles.
10
u/Scaryclouds Nov 27 '15
He didn't just merely mention XML configuration, it was the primary thrust of his displeasure with Spring. Not only was it the core idea of his first bullet point, but he also mentioned (or implied) complaints about XML configuration in his three other bullet points. Indeed he mentions XML 10 times in his article.
And again, Spring (Pivotal) also didn't like XML which is why they implemented Java configuration which they have been pushing for years now. Literally, literally, his primary complaint with Spring has not only been addressed, but been addressed before he even realized it was a problem. Yet he remains ignorant of this.
1
u/Zeffas Nov 28 '15
Again, maybe we read/interpret very differently, because conclusions I took were nothing of things you mentioned.
4
u/mus1Kk Nov 27 '15
Well, it's pot meets kettle at best. I mean, this point (and the article doesn't make any other besides XML and complexity) has been talked about to death. Why do we need another rant by some random Joe I never heard of?
5
u/Zeffas Nov 27 '15
I guess its all about perspective and psychology - how we interpret things.
I personally interpreted that part of article as - "annotations did not solve anything fundamentally, its the same xml".
So to me interpretations like "guy is living in last decade, xml is not used now" or similar, just sounds like complete and utter misinterpretation of article because of single "trigger" word.
Agreeing or not is a different discussion, but I just don't get why people are not trying to understand what is written before commenting.
2
u/nolandenuff Nov 28 '15
I think you didn't understand the author's point. Even though software and frameworks move very fast, there are still a lot of people who got started on this software/framework back in its early days. Speaking about Spring, I can tell you that we have a lot of people who started using it back from its 2.x days and that's why we see a lot of XML configuration still being used. Practices followed by people don't move as fast as frameworks do or they have just long left working XML configuration instead of changing it for change's sake. That's precisely what the article was about - the author had to move on to another project which was consuming artifacts produced by his old project and that's when he started seeing all the downsides to XML with Spring.
1
Nov 28 '15
I don't disagree with leaving a working XML configuration; however, if the author hates it so much and it's such a pain - refactor it out. That's what I did and I think it took me an afternoon or two of figuring out the Java equivalent to a few things that weren't well documented in the early 3.x days. These days the documentation is a lot better and it would be even easier.
If you're making something more readable/testable/maintainable - it's not change for change's sake.
1
u/nolandenuff Nov 28 '15
Right. I was pointing out a situation that the author might have found themselves in. Since they had moved to a different project, perhaps they were no longer in a position where they could change XML configuration over to Java based configuration. Instead, they publish a blog post about what they found wrong with XML based configuration and all its pitfalls. Now you tell me, is that so wrong? It could well have been their way of documenting all their mistakes? :-)
1
u/PaulRivers10 Nov 30 '15
Nothing like a bitchfest article from someone living in the past.
Just joined a job this year who's "new" project is using spring with xml configuration. It's for a large major company. That's just one thing on a pile of bigger problems.
-1
Nov 27 '15
[removed] — view removed comment
5
u/tsoliman Nov 28 '15
This is one school of thought and a valid one. This is why we need more non-spring-specific annotations (like @PostConstruct) that spring can still utilize.
5
2
u/cryptos6 Nov 28 '15
Why the down votes? I think this opinion is very valid. Actually there are DI frameworks without annotations and XML, like StructureMap (.net).
1
17
u/karlito1 Nov 27 '15
"XML? If you don't like it use annotations that are magic?"
Did you hear about Java config that is being pushed around for like 5 years now, it's totally typesafe and easy to maintain? Also Spring is full of magic for those who don't understand the magic happening, to me it is really simple, most of that magic is object proxying, nothing more or less.
Furthermore, Boot is only a Spring evolution, and more like a framework to help you and make using the Spring framework itself easier. It's really not unusual to take an existing framework and build something on top of it to make it more general and easier to use, a good example is Netty, alot of frameworks build on top of it, so is it also a framework that needs a framework?
Boot is just an autoconfigured Spring that fits most users, but still leaves you all of the power and free hands for writing anything you want in the "real" Spring.
16
u/stormcrowsx Nov 27 '15
This is exactly how spring went for me. I loved it when I was young and building a new app. All the complaints about hard to understand I brushed off as idiots who need to RTFM. Older wiser me has learned if I'm calling someone an idiot because they don't understand the library it probably means the library is too complicated.
Also the version conflicts are frustrating at best. Let a stable library be that uses spring 2 and the new apps using spring 3 break at runtime.
3
u/tkruse Nov 29 '15
With great Power comes great responsibility. The Spring "Magic" is power. But many teams do not act responsibly. They scatter configuration across modules in arbitrary way, stopping to clean up as soon as things work. It's not directly Springs fault, but it is something related to how little Spring supports or enforces clean module design, refactoring or debugging configurations.
This is what makes people hate Spring, that they have to clean up the mess other people leave behind, and it is painful to do so. Basically to check whether an intended refactoring causes any problems you have to rely on intensive testing.
0
7
u/mabnx Nov 27 '15
While I don't agree with some things he has a point:
(...) but I wanted to highlight the fact that Spring is now so complex that it has it’s own framework, Spring Boot. A framework for a framework. We are in Framework Inception (...)
4
Nov 27 '15
Spring is broken into a ton of pieces you can compose together, saying just "spring" anymore doesn't really tell you a ton. Though isn't spring boot more of just a sane default set to use with spring, not really a meta framework..?
5
u/frugalmail Nov 27 '15
(...) but I wanted to highlight the fact that Spring is now so complex that it has it’s own framework, Spring Boot. A framework for a framework. We are in Framework Inception (...)
There is nothing wrong with this. Even if you need more customization, you go to a lower level. This is standard software architecture, you build on the shoulders of giants before you.
3
u/squishles Nov 27 '15
XML
I don't like my own methodology, and have decided to make no attempt to update/change it in 5+ years.
magic
You can manage interfaces, types, and provide qualifiers where that's vague, to manage a simple concept that has exists in j2ee using the exact same annotations. FFS you're a god damn wizard Harry!?!
Importing other Spring files :
I really do wish it had an optional for junit testing =/ that's trying to solve something that should be handled with those spring profiles anyway though. Not like the dependency wasn't already there. Say you have your datasources.xml that provides an entitymanager off in the dao jar, not like your application is going to run without something providing that entitymanager it's asking for all over the place anyway.
Complexity
You string them up for the configuration, then they remove most of it by providing you with prepackaged common defaults and you string them up for that too. Really? I mean yea basically shoving a full j2ee container into that shit was probably going too far, but attacking it on the idea is kinda cheap when it was to fix the shit being compained about farther up in the list. It's like calling someone guilty for apologizing.
2
2
Nov 27 '15
I've at least a dozen large Spring projects going back the XML days and never had these problems. The simplest case is to autowire and instance of an interface. This isn't hard to understand in the slightest. Define an interface, define an instance as a spring bean, inject an instance of the interface. That took me about a week to get comfortable with and it's been smooth sailing for 10 years.
15
u/stormcrowsx Nov 27 '15
Then hand the codebase to a new guy and watch him struggle to understand where all the values are coming from.
Spring creates a blackbox in the middle of your codebase that's hard to see inside of. Its not like plain java code where a few eclipse ctrl-clicks and you've figured out the call chain and where all the values came from.
A week to get comfortable in Spring is wayy too overly optimistic, it takes more than a week for most juniors to even know why DI is a thing and what it does, pile ontop of it the need to understand proxying (and its pitfalls) as well as all the spring terms and its more like 6 months to get an effective junior.
1
u/sh0rug0ru____ Nov 28 '15
Its not like plain java code where a few eclipse ctrl-clicks and you've figured out the call chain and where all the values came from.
This has nothing to do with Spring. Your simple ctrl-click strategy will fail once you introduce the concept of separation of interface from implementation, abstract classes and multi-tier architectures. It will fail once you start writing reusable code that can be used in multiple contexts, or when you start segregating layers and separating cross-cutting concerns.
Spring is just a wiring technology, like CDI or Guice. The "problems" you say it creates are not problems at all, but the consequence of higher level software engineering.
5
4
u/stormcrowsx Nov 28 '15 edited Nov 28 '15
They jump through to the implementation, they give you no idea how that object was created or how it was proxied. Plain java code you can trace all the way back to main with very little effort.
In my experience the hardest bugs I faced were in the spring doing unexpected things hidden in Spring. For instance a guy called an @Transactional method from within a service, but because he was calling it from the service the proxying didn't work, because it only proxies outside calls. We got a bunch of bad data and it took quite a bit of dev hours to find because it was not intuitive. You can't easily step through that proxy stuff either when debugging.
0
u/fforw Nov 28 '15
For instance a guy called an @Transactional method from within a service, but because he was calling it from the service the proxying didn't work, because it only proxies outside calls.
This behavior is clearly documented:
In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual transaction at runtime even if the invoked method is marked with @Transactional. Also, the proxy must be fully initialized to provide the expected behaviour so you should not rely on this feature in your initialization code, i.e. @PostConstruct.
So you have developers using things they only half understand and it even works most of the time.. Now you hate spring and make it all constructor injection.
Now your aforementioned Bozos have to implement all transaction handling by hand, every time. What makes you think that will lead to less fuck ups?
5
u/stormcrowsx Nov 28 '15
The problem is there is so much non-intuitive behavior. Those little pitfalls cost a lot of time and for someone to forget a detail like that when coding isn't that far fetched not to mention most people don't read the manual. Yelling that they need to doesn't fix it, people won't read the manual.
1
u/fforw Nov 28 '15 edited Nov 28 '15
Having to produce the same boilerplate code for certain tasks over and over again gives ample opportunity for making mistakes, too.
What Spring does is that what's possible: Providing standard solutions to reduce that boiler plate. What you are expecting is magic, which doesn't exist.
2
u/stormcrowsx Nov 28 '15
It does exist, for instance in scala you can make a transactional block which does not do anything magical it just wraps one function in another function. Even in Java its probably possible now that you can pass functions to other functions easily.
Anytime you see proxying like the @Transactional annotation it can be replaced by wrapping a function in another function or higher order functions which are more predictable and can easily debug even.
-1
u/fforw Nov 28 '15
Yeah sure.. the bozos that can't even use Spring suddenly are all proficient in Scala.
Now with Java8 it can be done without much interface implementing. Java8 still isn't possible for everyone.
2
u/PaulRivers10 Nov 30 '15
You can do the whole thing with a simple Action pattern. It doesn't require specialized Spring knowledge, it's easy to trace into to figure out what's going wrong. It's very simple to do with no Spring involved whatsoever, and a lot easier for everyone to figure out, with far fewer bugs.
0
0
u/tonywestonuk Nov 28 '15 edited Nov 28 '15
I really, totally hate spring. It has nothing to do with DI, but more the mindset that spring brings along with it.
For example.
There is spring profiles, where you have a configuration file that can have different configurations based on a setting.
http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html
So, for live deployment, you have a different profile, than say development. The thing is, its totally idiotic to have such things.... It leads to large complex configuration files, maybe even per-developer configuration that ended up been committed to Subversion. In short, it leads to a mess.
The correct way should be to let the application pull information about the environment it is running in. Maybe by JNDI? This way, if say a database URL changes, then a whole new build/redeploy doesn't need to happen. Ops just do the update themselves. and bam....done.
Then this Spring Boot thing...... Where webserver and app is all rolled into one...... perfect for microservices...... We have several of these spring boot apps running on a single server..... the memory requirements are huge, to allow for caching. Hibernate connections have to have caching turned off as an update by one service might not be seen by another.... its really slow. its not the way....
then you have things like Spring Data Rest, which " makes it easy to expose JPA based repositories as RESTful endpoints. " Why does noone scream this is a very bad idea!! - it makes it so that you cant change the JPA repository, without changing your rest interface!.... the correct way would be to have some kind of MVC layer that interperates Rest requests, gets data from the datastore in whatever way it needs to, populates a DTO and sends it back.
In the end, the amount of spring projects I have worked on that end up just a mess, because people have followed these principals. Spring DI is ok, however the way it is advocated using it is to have a big service layer, and anemic domain. which is procedural code.... This isn't a fault of DI, but more of the 'Spring Way' mindset.
Spring, in my opinion, has done more to hurt Java than anything else.
7
u/olivergierke Nov 28 '15 edited Nov 28 '15
Disclaimer: I am the project lead of Spring Data.
Why does noone scream this is a very bad idea!!
Why do you think it's a bad idea to remove boilerplate code from software projects?
it makes it so that you cant change the JPA repository, without changing your rest interface!
No. Evolving APIs is hard, with or without Spring Data REST because once you've gone public with an API there are only certain things you can do to it. Whether the code that produced that API is a library (which helps you simplify things in the best case) or your custom code doesn't make too much of a difference. SDR actually leverages hypermedia intensively (ironically something people have complained about) which improves changeability. So one could argue that by being sent down that route by the framework, it's more likely you really get to use REST's beneficial parts (which evolvability is a key part of) rather than the usual "I flip some database tables by 90° and throw them as JSON over HTTP and call that REST", which is — in my experience — rather the default than the exception.
…the correct way would be to have some kind of MVC layer that interperates Rest requests, gets data from the datastore in whatever way it needs to, populates a DTO and sends it back.
As that's sort of what SDR does I have to assume you haven't spent too much time on it. You're right, it doesn't use DTOs, but there usually are a few ways to skin a cat. The SPIs, the projections feature and Jackson customizations have proven to be a useful toolbox for all kinds of customizations. And again, that's nothing the tool makes you having to think about, designing representations is the tricky part and the defaults we chose are in place for a reason (as usual: experiences from real-world projects) but can be differred from if needed.
If you want to have a look at amore involved sample, here is a Spring based implementation of the RESTBucks sample from the RESTful web-services book, that uses SDR for the CRUDdy parts but then hooks in custom implementation code to implement the more advanced parts using hypermedia etc.
https://github.com/olivergierke/spring-restbucks
It's all about taking the pain out of the boring parts. Now tell me you really really would've liked to code all the boring stuff you get out of the box yourself ;).
1
u/lukaseder Nov 29 '15
After the original peak of inflated expectations, the author is clearly in the trough of disillusionment now. It's OK, author. You'll reach the plateau of productivity with Spring, eventually.
0
u/nutrecht Nov 28 '15
No one noticed that this blog post was posted in March 2014? Nothing to see here, ancient posts is ancient (even though it was already outdated when it was posted).
0
0
Nov 27 '15
[deleted]
12
7
u/stormcrowsx Nov 28 '15 edited Nov 28 '15
I used to work with /u/vermooten, disregard what he says.
3
u/joequin Nov 28 '15
You have to say more than that. If you don't, I'm more apt to ignore you than the author. Not because I think you're lying, but because people who express their opinions of people and things the way you just did without any further explanation aren't usually worth listening to.
12
u/yawkat Nov 27 '15
What I dislike about spring is its complexity. While I can get a decent application running pretty fast, once you want to do anything non-standard the "right" way you get to dig through source files for hours just to find out how to insert that security adapter at just the right place to not break everything.