The critical missing pieces and a path forward

[Volker Berlin]

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.
Another frequently cycle is between "Login/Permission" and "GUI". The 
login needs a GUI. And the dialog elements of the GUI needs a permission 
check.

Because we have understand this and the hierarchically classloader can 
not handle cycles that we have develop for years a classloader with cycles.
The alterative to cycles are large monolithic modulus/components. Such 
modules are very bad to maintain.

> (For those not familiar with the details of the design: Cycles are not
>   allowed when modules are resolved but it is possible to create them
>   post-resolution via the API, if needed [4][5].  Cycles are also set up
>   amongst all automatic modules, after resolution, to make it easier to
>   treat existing JAR files as modules without change [6].)
A light point but what are the advantages of modules in this case. I see 
no advantages across from classloaders. Because classloaders will never 
removed there is no need for a switch.

Volker
i-net software