The critical missing pieces and a path forward
volker.berlin at goebel-clan.de
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 , 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
> - 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".
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
More information about the jpms-spec-observers