The critical missing pieces and a path forward
volker.berlin at goebel-clan.de
Thu May 11 20:03:10 UTC 2017
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.
Another frequently cycle is between "Login/Permission" and "GUI". The
login needs a GUI. And the dialog elements of the GUI needs a permission
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 . Cycles are also set up
> amongst all automatic modules, after resolution, to make it easier to
> treat existing JAR files as modules without change .)
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.
More information about the jpms-spec-observers