It can be worth understanding why the Java ecosystem evolved that way. It's not because simplicity wasn't valued, but rather it's not code simplicity that's val

It can be worth understanding why the Java ecosystem evolved that way. It's not because simplicity wasn't valued, but rather it's not code simplicity that's valued. Rather, much of the Java ecosystem is designed to allow dozens of independent teams, totaling hundreds of developers, within a company (or across companies) to build their small piece of the application, with whatever build process is used by them. Then you put all the .jar files in one bundle, and the AbstractFactoryBuilderLookupServiceBuilders puts the pieces together at runtime. It's complex as hell code-wise, but it simplifies the amount of cross-team/cross-company alignment and synchronization that has to happen in order to cut a new version of the application containing hotfix 8495 for the part of the app maintained by Steve's team. There's actually a decent parallel between that and Microservices. Microservices make maintenance of the whole more complicated by introducing the network between pieces, but allow each piece more flexibility in how it's developed.