The critical missing pieces and a path forward
alex.buckley at oracle.com
Tue May 16 22:34:03 UTC 2017
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
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.
More information about the jpms-spec-observers