It's also widening the gap between Dev and Ops. I was a developer for 6 years and started moving towards DevOps and trying to build relationships between the ops teams and the programmers. The programmers are always whining about not being able to use the latest language/tool/library/<<insert flash tech here>> while the ops team are just trying to make the pile of junk they've been handed work.
Spring, and Spring Boot most egregiously, work only to widen the gap between devs and ops. The developers have no idea what a Boot app is doing internally for 90% of its stack. The ops guys just want to stably deploy something that is well understood and supportable when it falls over. Not to mention the memory management headaches it introduces...
I moved away from JS early on in my career because it's mostly a disaster waiting to happen, but now the Java devs have the same potential to output a steaming pile of crap that they don't understand.
> The developers have no idea what a Boot app is doing internally for 90% of its stack.
This is the biggest problem by far with Spring Boot. It’s not just hidden default settings or convention or configuration, it’s entire hidden applications.
We have had app teams whose Spring Boot application leaks memory at a rate that meant we needed to do app restarts once a month, even once a fortnight on occasion. Investigation is then hampered by half of the conversations we have being along the lines of "well we're using Spring Boot so it can't be our problem" and the other half are "it's Spring Boot causing the leak."
The dev team refused to accept responsibility as though they hadn't fought tooth and nail to use Spring Boot in the first place.
We monitor just about every aspect of the machines and JVMs that we own. When the Heap graph climbs steadily over days/weeks at a time, i.e. each GC still results in considerably more overall memory usage.
I read that as more of a criticism of the ORM/JPA and maybe xml than Spring Boot. In practice it's easy to pull down half the database with an errant "eagerly loaded" collection or attempt to deserialize a giant xml document into an in memory DOM, both of which can exhaust memory and hang jvms with very little information on what happened than an 'out of memory' exception.
Spring, and Spring Boot most egregiously, work only to widen the gap between devs and ops. The developers have no idea what a Boot app is doing internally for 90% of its stack. The ops guys just want to stably deploy something that is well understood and supportable when it falls over. Not to mention the memory management headaches it introduces...
I moved away from JS early on in my career because it's mostly a disaster waiting to happen, but now the Java devs have the same potential to output a steaming pile of crap that they don't understand.