The critical missing pieces and a path forward

[Alex Buckley]

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_  [2], 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 
[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] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html