Got a chance to work again on a Spring project after a few years of working with JavaSE.
All these horrible memories started rushing back. SpringJPA and its dark magic that only works unintuitively and under very certain conditions...

Ooooh boi. Now I remember. I remember it all.

Why do developers enjoy being squeezed into frameworks and enjoy spending half of a day figuring out how to make the application code compatible with the said framework rather than just writing code that they have full control over...? Masochists much?

To be fair, without frameworks like Spring we'd just be writing our own custom frameworks over and over again anyway.

@Hazarth but why? Why use frameworks when you can use feature-rich libraries and retain control over the flow, flexibility and still do things fast [if not faster]?

@netikras spaghetti code

Because developers are an intensely lazy group of people.

We all want to be paid the big bucks, but then we try to do the LEAST amount of work possible for it. We can't even be bothered to write our own left-pad function, gotta find a library someone else already wrote for us! It's all like that.

Spring allows developers to be SUPER-lazy... and I'm not ant-Spring or anything, I'm just making a general comment here. But Spring IS a big offender because of just how lazy it lets you be. You don't even have to write SIMPLE code! Just throw some annotations around and voila, the magic happens, and you've got a full application.

Oh, sure, we wrap our laziness up in some "we're more efficient and our clients don't care how we get it done as long as we do!" bullshit, but we take the exercise to an extreme that is just ridiculous sometimes.

Sure, a carpenter doesn't have to make their own wood, but are you still a carpenter if all you're doing is putting Ikea kits together?

@netikras A framework is just a pile of libs optimized to work well together for solving a set of problems. If your problem lies is member of the set, chances are the framework fits better than just a pile of libs not optimized to work well together.

I don't like using other people's frameworks either - i normally end up making my own instead.

@Oktokolo a framework usually takes control of the flow, whereas a library is a tool you use. With a framework, you are only writing code to configure how it does the job. But you can only configure as much as fw devs allowed you to.

Unless I'm mistaken?

Spring-boot, hibernate, spring-jpa, liferay, aop, .... They all feel like they are in control of the app. I can only configure bits here and there, but only this much....

Which makes frameworks irreplaceable foe small/simple projects, where only little control is enough. But not when you need advanced stuff... Imo

Spring boot (or other similar frameworks) I really quite like. It takes control of the application by design, but it's easy enough to bash into shape and the advantages it brings with dependency injection and reducing boilerplate are pretty compelling. I've yet to find an advanced use case where I felt completely limited by Spring.

Let's not confuse that with the other SpringXXX projects though, some of which are awful. I've never got on with JPA or Hibernate for example - they're great for barebones, simple relational database applications for demos, but in real world use they always seem to become a mess, hideously slow, or both - and that's before you get into working out if various entities happen to be attached to the session you're in so they'll actually update the persistence layer or not.

If I have to do relational DB stuff I generally prefer to use Jooq these days, though the fact the open source version doesn't support older versions of (for example) MySQL is annoying.

@AlmondSauce looks like we've both had business with the same sea monsters, aye!

Spring's DI I quite like. A bean-bag that's always around. But, as you say, SpringXXX "extensions", so to say, are a pain if you have to go anywhere beyond basics.

P.S. I've had a bone to pick with Spring's DI as well. Dynamically loaded beans, i.e. after app startup and only after configuration had been digested in I had to choose which implementation of an interface to wire in. Not before. And for speciffic reasons I couldn't defer this logic to a proxy-implementation of said interface that'd act as a dynamic decorator of sorts. I did have to rape Spring's bean factory and I feel filthy for doing so.

@netikras Frameworks don't have to be strict. They normally indeed do contain some control flow infrastructure meant to remove the need for a significant amount of boilerplate code.

Some frameworks allow you to just not use the control flow components while their other parts still keep being useful.

Other framework's components are tailored in a way towards use with the control flow components, that using them without it is just too painful. It seems that most web frameworks are of the latter type.