Spring is a Piece of Shit
Spring, the servlet framework thing, is a huge piece of shit.
It's way too fucking complicated to be helpful. And saying it is not complicated is invalid because if it wasn't, there wouldn't hundreds of blogs, books, and forums dedicated to helping it be understandable. All intrinsic understanability has clearly gone out the window.And here's the real root of it being a horrendous pile of dog shit:
Those damned configuration files. Those large XML files, arbitrarily placed, have all the wonderful functionality of code without the fun or type-safety or anything else you would want of Java.Don't get me wrong, I understand the idea of configuration files and even data-driven design, but here's where it goes stupid. Having config files instead of hard-coded values allows for several advantages:
(i)Non-programmers can change the functionality of the program, or at least it can be changed in a way that doesn't involve diving deep into the code base
(ii)No code changes
(iii)Changes require a restart at most instead of a recompile
All fine and dandy, but this is what really makes my hemorrhoids flare up:
The XML configuration files for Spring, if you look closely enough (1000km should do), you'll see that it is an exact replacement for Java code. "Beans" and other synonyms of bullshit are exact invocations of constructors and other methods.It's just a one for one. Nothing's for free. All advantages of a simple configuration language are gone. Now instead of just having to know the Java, you have to know all the extra XML tags which afford you no benefit on top of just writing some Java code.
And guess what, if you always submit code through a code review process, and the configuration language is so powerful that its a one for one swap for code, you should be submitting your configuration file changes for code review as well. Not reviewing these configurations would be like changing your Java for Python and not submitting for review because Python doesn't need to be compiled. I'm not saying all configurations or data changes in data-driven software should go through this, but with Spring, you ARE writing code, its just wrapped in XML tags.
So as for the benefits listed above, you don't get (i) because you need to know the code anyway. You do get (ii), but as I said, since this really is code, it should go through the proper code review channels, so you don't really get (ii). All representing code as configs does it take away type-safety so you can't find out mistakes until you try running. Why were we using Java anyway?
But oh, our savior, (iii), we don't need to recompile the code to pick up our changes. This is very true.
Building large projects for tiny changes can be very time consuming. Hmm, wait a second...this is Java, not like a C program where the last step will be to create the whole executable all linked up. So really only the Java classes that changed themselves would need to be recompiled, not all the libraries which, in a Spring project, is 90% of the code. But admittedly, it is some means of recompiling which does waste time. Even if just a little, it really adds up when they are frequent.
EXCEPT FOR THAT WHOLE FUCKING PART WHERE YOU ALWAYS NEED TO RE-PACKAGE THE WAR ANYWAY TO DROP INTO YOUR FUCKING WEBSERVER!
So you don't get the benefit of no recompile, you don't get the benefit of no code changes, and you don't get the benefit of not having to be a programmer to make code changes. All you get is a huge fucking headache from the pages and pages and pages of Spring documentation you have to read to be able to get all of the configuration in the right fucking place to make this piece of shit work.
Now, I still see the benefits in configuration files, but the code can be more explicit without wasting your time with the above if you could just create objects as you are doing in the damn XML without trying to figure out which FactoryFactory or ManagerManager it needs to be given to. Imagine something like
public static void main(String[] args) {
SpringServlet s = new SpringServlet()
s.addController(MyController.class)
String jdbcConnection = StringUtils.readFileAsString("/config/path/that/makes/sense/for/me/jdbc.txt");
s.setJDBCConnectionString(jdbcConnection);
s.start();
}
Now, I know I'm oversimplifying and mixing some fun like Hibernate in there, so just keep it in your panties; I'm just illustrating a point.
You could separate the above into any configuring classes you want instead of trying put the right configs in the right places so Spring can automatically help you in a way that just makes sense for your own project, and there's no POJOs or Beans or Dildos or whatever else Spring wants to shove up your butt.
Really quick about the proposed adding of controllers as above: doing if via config file: fucking stupid, whoever made a controller and didn't add it to their webserver? Doing it via annotations: pretty awesome. I do like the annotations, it really helps to make a project more understandable by having to understand less.
They are great for just saying "this is gonna do this stuff," and save us, it should work because someone on my team who spent two years learning Spring set up everything perfectly for annotations to work. Fantastic if you have that guy. Otherwise, this way is really simple. But Aaron, you have to remember to add each controller. Yeah, you also have to remember to add the annotations, so its not really different. And you'd find out if you forgot literally immediately because your first test to one of the URLs defined in the controller would fail if you forget to add it.
So instead of learning what to configure, the syntax for the config files, figuring out where to put them, you just instead have some simple Java code, very explicit in what you are configuring and when, and maybe the one JavaDoc page open for what would be the SpringServlet class whose public interface ought to be explanatory enough by itself. Yes it's code, but anybody writing controllers and stuff in this regard is going to be a Java programmer anyway. The only config changes that wouldn't require developer-level knowledge of the whole process would be things like your database connection information which could still be set via a simpler configuration file, preferable one not defined in XML because who needs that shit in their lives.
To everyone that wasted hours combing through StackOverflow.com and various blogs trying to get the information you needed to figure out what configuration to add, what annotation to add, and what the next cryptic error message meant, don't be hard on yourself, we were promised the world. And we were lied to.
This is of course just my opinion (I'm sure its just a coincidence that I am right and supporters of Spring are wrong).
Suck a fuck and eat a dick,
Aaron
