Not necessarily. Some things cannot be checked at compile time. (...)

Sure, compile-time checking has its practical boundaries. For me creating the service graph falls within these boundaries.

In the end it’s the same controversy as managed memory vs unmanaged memory. Yes, you may try do your best and structure your complex apps. Or you may let a machine to do it — it’ll free you a lot of time to concentrate on your actual problem.

Sorry, but I don’t believe that distage or any other library/framework will remove the very hard problem of properly modularizing/structuring the application. It’s always a struggle ;)

I have to disagree with your disagreement. While your statement may be true for “most applications” it’s completely wrong for “most products” consisting of multiple “applications”. distage allows you to greatly reduce complexity of your product — by replacing microservices with a lot better idiom.

Well if you are proposing a new architectural approach, that’s a whole another story. But I have a suspicion that such a pattern (of composing otherwise independent parts) shouldn’t be so coupled to how these parts are themselves implemented.

Of course no. I doubt you may build something comparable to Jira or Jenkins without employing some powerful module system. distage provides you such a system — and, I believe, it’s the lightests and most robust implementation ever — while it can do most of the things OSGi can, apart of dynamic reloading and isolated classloaders (which are planned for implementation) — it has just several thousands LoC. Also it comes without heavy penalties so it’s very useful for mid- and even small-sized apps.

Again, I’m not saying that distage should never be used. I’m just probably placing the border where I would even start considering a DI library/framework much later than you. Luckily both approaches don’t impact the way you write the components (they are just classes with fields), so migration is always possible.