The critical missing pieces and a path forward

Volker Berlin at
Mon May 15 19:38:54 UTC 2017

> It sounds like:
> - The implementation of "Logging" accesses the API of "Configuration", 
> to determine how much logging has been configured; and
> - The implementation of "Configuration" accesses the API of "Logging", 
> to record errors in config files.
> The cycle can be broken by refactoring either "Configuration" or 
> "Logging". In the spirit of the recent jigsaw-dev discussion about 
> Log4j [1], let's refactor "Logging" into "LoggingIntf" and "LoggingImpl":
> - "LoggingIntf" 'exports' an API for general use, so "Configuration" 
> 'requires' "LoggingIntf".
> - "LoggingIntf" also 'exports' an SPI.
> - "LoggingImpl" 'requires' "LoggingIntf" in order to gain access to 
> the SPI, and 'provides' an implementation of the SPI.
> - "LoggingIntf" 'uses' its own SPI and discovers providers via 
> ServiceLoader.
> - It may be that "LoggingImpl" 'requires' many other modules, and they 
> in turn have their own 'requires', eventually leading back to 
> "LoggingIntf", and that's fine. The dependencies of "LoggingImpl" may 
> even have their own 'uses' and 'provides' directives, all of which 
> will be bound in the same fashion as "LoggingImpl"-to-"LoggingIntf".
> Alex
> [1] 
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.
  * 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

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.


More information about the jpms-spec-observers mailing list