2 ms·
I think a big part of it is that common libraries do it and ask you to do it more. Spring and Tomcat and etc are, imo, abominations of complexity -- but you sti
by ajkjk 9y ago
I think a big part of it is that common libraries do it and ask you to do it more. Spring and Tomcat and etc are, imo, abominations of complexity -- but you still often find yourself buying into their ecosystems. Especially if you're working on code that's a few years old.
- ajkjk 9y agoI'll add: both Spring and Tomcat exemplify this quality that a lot of earlier (2000-era) Java frameworks have (others: Hibernate, actually literally anything that embraces XML...), of being "extensible mostly in name only". You can, in theory, implement modules that tie into various parts of their functionality -- and in practice I've found myself doing it occasionally -- but it's almost always regrettable. Anything you figure out how to do in these will itself just become un-figure-outable for the next engineer who handles it. (One of the most frustrating tasks in my engineering career involved trying to debug why Spring beans loaded by a Spring-Tomcat integration layer, in the initialization of a Tomcat container, weren't discovering XML files loaded at another stage of initialization. When I look back on that year I think I might have indirectly changed jobs because of it. Hah.)