On 22 Apr 2023, at 19:55, Gregg Wonderly <gregg...@cox.net<mailto:gregg...@cox.net>> wrote:
The dependency injection, like this, performed loosely, at runtime, is a problem only when the structure of association is loose. Modularity has injected this detail by suggesting that the “huge jar file” solution is a problem. I don’t think it has. A multi-module JAR would be precisely addressed at allowing huge JARs on the one hand, while on the other allowing the application to construct a minimal image that contains only the relevant portions of the JAR with all that benefits to optimisation, maintainability, and security modules brings (see https://openjdk.org/jeps/8305968). Jars inside of Jars and other mechanisms have become forbidden due to licensing issues and other blind attempts at control of “use” as something that provides value to the owner. I don’t see what has changed recently in regard to licensing. The impact of a library’s license does not change if it’s used on the classpath or the module path. Instead of providing sanity, we’ve opened to door to hugely complex paths of reference and association that are nearly impossible to understand and manage for large software systems. Quite the opposite. Modularity doesn’t change any "paths of reference and association”; it merely requires them to be explicit. — Ron
