5 ms·
That`s not spring boot, that`s whole spring (and google guice, etc), starting from the idiotic XML for bean wiring, to equally idiotic anntations, and finally,
by avodonosov 6y ago
That`s not spring boot, that`s whole spring (and google guice, etc), starting from the idiotic XML for bean wiring, to equally idiotic anntations, and finally, after 15 or how many years, they realized that plain java can be used for object creation. What a discovery! Still, they introduced @Configuration bullshit, etc.
(There are cases when such features may be useful, e. g. systems that are extended by 3rd party plugins, like Maven, although may be done without that as well).
For normall applications that´s nothing more than bloat and limitations. The problem that the majority of users follow cargo cults without understanding what are they doing. In result the ecosystem is full of bad practices.
AbstactArgumentBuilderFactoryFactory were in fashion for the same reason.
Otherwise Java is a neat little language and a good platform.
- abraae 6y agoWas "boolshit" a typo or is it a magnificent new pejorative?
- avodonosov 6y agoTypo :)
- chris_wot 6y agoAlso amazing new pejorative.
- Cullinet 6y agoah, I am promoted thus to reminisce upon my boolshitten youth spent vainly stabbing out crud most fervid and amorous to dump the vilest cores to jest with that naivest child me to know it better than to presume that my brittle logic could affect it so profoundly to do my bidding...
- bryanrasmussen 6y agoit's an amazing new type description where some shit is either true shit or fake shit.
- jcelerier 6y ago> e. g. systems that are extended by 3rd party plugins, That's most non-toy desktop software
- MattPalmer1086 6y agoFully agree. I've inherited an insane desktop application that uses the spring XML bean configuration. Then there's classes used to configure the configuration. And three separate property class types to pass the properties into the context, only one of which will persist the properties. And factory beans to instantiate a different bean depending on the properties passed in. And different XML configurations for each subproject which somehow join together but sometimes complain about dependencies being defined in the wrong place... Total nightmare. It's basically impossible to know what will be instantiated, extremely hard to inject and configure things. When I find the time I'm going to just create things directly from Java with constructor injection and ditch the whole sorry mess. Edit: did I mention how unbelievably slow it is as well?!
- laurent92 6y agoI’ve sometimes recreated the Dependency Injection in 200 lines, because I had an absconse error for an entire afternoon. Sometimes one has to fix the right problem (It was with Dropwizard not SpringBoot, but it’s a recurring theme in the Java ecosystem).
- ubertoop 6y agoThis is true in most languages really. It starts with people just wanting to speed up their development by turning common tasks into some macro, or annotation, or even library. But where does it end? It ends in a convoluted mess of dependencies, weird syntax, and hopeless stack traces. So much work can be done with plain old Java. Or plain old JavaScript. Or plain old C + stdlib.
- jmartrican 6y agoAgreed. Setting up Springs OAuth Client was so complicated and getting the configuration right was taking so much time. I replaced it with a simple Filter that just did the query itself. It easy to go to that filter and add whatever security logic you want (at least for me it is). There is a balance here that might be hard to get right. Spring and other frameworks make things easier until they dont. At some point it might be easier to just write code instead of configuring your way through these frameworks. Many times I rather write code then go configuration hunting. What I do like about Spring is that they offer a lot of hooks and interception points to overwrite with your own logic.
- ta988 6y agoAnd you end up writing yet another custom framework for yourself when you realize you are writing the same things over and over...
- Pet_Ant 6y agoBut you and up writing just the bits you need so that you end up with a framework that serves your use cases, that you grew so you understand and unencumbured by the use cases of others. It'll make you more productive... but not necessarily the person you hand it off to.
- ta988 6y agoYes totally agree with that, it is not only negatives.
- lmm 6y agoI'm no fan of regular Spring, but it offers some legitimate value and has relatively comprehensible behaviour. It doesn't break grep: when a class is instantiated by Spring you can find a reference to that class, and most IDEs can also follow those references. Adding a new dependency doesn't change its behaviour. Spring Boot is real a step change in comprehensibility, in the wrong direction. It's on a similar level to adding COME FROM to the language. You're not wrong to complain about Spring/Guice in general, but implying that they're remotely comparable to Spring Boot is thoroughly misleading. It's not the same thing at all.
- geodel 6y agoGood to see another big fan of Spring Boot as me. > Spring Boot is real a step change in comprehensibility, in the wrong direction. With VMWare's Tanzu crap for containers and Spring native initiatives, the idea is complete lock-in in VMWare ecosystem from developer desktop to running service. The goal seems that no one should have any visibility on their own systems except VMWare consultants.
- jacques_chester 6y agoI work for VMware, so I am not disinterested, and of course we want it to be easy to use stuff we sponsor or contribute to. But what exactly about stock Kubernetes and the fully-OSS-for-nearly-two-decades Spring Project strike you as "lockin"? This is a bit like accusing Red Hat of lockin for shipping a Linux kernel.