You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dyn

You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dynamic loading and execution of code through reflection and other mechanisms actually is a bad thing? If i got a euro for every time i run into problems at runtime when porting Spring to Spring Boot or Spring Boot 1.X to Spring Boot 2.X projects, i'd have enough money never to have port projects like that over. Whereas without such dynamic logic, if your code compiles, you can be pretty confident that there won't be such oddities, classpath or dependency conflicts, weird scoping rules for Maven (especially with the <provided/> option which means that all of the sudden your app becomes dependent on an app server and its specifics - does your install of Tomcat or TomEE have the correct version of the .jar you want to use, or maybe it'll be missing, or maybe there'll be two libraries loaded at the same time?). Of course, picking a tech stack in which such approaches and dynamism aren't even prevalent is also a good alternative, though not everyone enjoys the more static way of development either.