> 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.
> Not to mention the memory management headaches it introduces...
Could you elaborate on this?
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.
Re:RedHat Mandrel Makes Java Native
by marktangotango on Thursday July 02, 2020 @10:15PM
(#23720434)
Just curious how you're measuring the memory leak in this case? Can you explain how that's being determined?
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.
Re:RedHat Mandrel Makes Java Native
by marktangotango on Thursday July 02, 2020 @08:27AM
(#23712384)
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.