The critical missing pieces and a path forward

[Alex Buckley]

On 5/15/2017 12:38 PM, Volker Berlin wrote:
> Thanks for the answer. What you suggest is:
>
>   * Splitting modules in interfaces and implementation. This can explode
>     the count of modules in a complex application from 300 modules to
>     1000 modules. You lost maintainability.

Only one module that participates in the cycle needs to be split.

>   * In your construct you lost also the declaration of runtime
>     dependency to "LoggingImpl". This dependency exists in real. You
>     have only removed it from compile time. The application will not
>     work if "LoggingImpl" is not present. This reduce also the
>     maintainability.

The "LoggingIntf" module that I suggested would discover providers via 
ServiceLoader can easily choose to stop if zero providers are found, or 
if providers other than the critical "LoggingImpl" module are found.

> This work nice if you have only the 2 modules. In real live application
> with 300 modules and more there can be 2-3 thousands dependencies.
> Without a full declared graph of runtime dependencies you can't manage
> it anymore.

I get the feeling there is some kind of disconnect as to how services 
work in the Java Platform Module System. The consumption and provision 
of services is denoted explicitly in the module declarations of 
"LoggingIntf" and "LoggingImpl", so it's easy to see how modules might 
bind to each other at run time.

I would also point out that code on the classpath can consume services 
provided by modules, and modules can consume services provided by code 
on the classpath (META-INF/services), so you can modularize the existing 
300-JAR codebase in phases.

Alex