The critical missing pieces and a path forward
alex.buckley at oracle.com
Thu May 11 21:47:06 UTC 2017
On 5/11/2017 1:03 PM, Volker Berlin wrote:
> Am 08.05.2017 um 16:57 schrieb mark.reinhold at oracle.com:
>> Forbidding cyclic module relationships is one of these new constraints.
>> That such relationships are generally a bad idea is not just my personal
>> view; see, e.g., Kirk Knoernschild's compelling arguments against them
>> in his fine book,_Java Application Architecture_ , specifically in
>> Â§4.4, "Cyclic Dependencies -- The Death Knell".
> I does not understand the discussion here. It is inpossible to write a
> large complex application without cyclic dependencies. The classic cycle
> is "Logging" and "Configuration". The configuration define the type of
> logging like level, file, format, etc. If there any errors in the
> configuration then it write it to the logging module.
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"
- "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".
More information about the jpms-spec-observers