On Wed, 2007-12-05 at 16:48 +0100, Genevski, Pavel wrote:
Hi Adrian,
I am particularily interested in this statement:
" * It isn't really that difficult to support "
What do you exactly mean ? What is the current mechanism for supporting
it ?
I haven't looked at how Stanley supports them.
Here's a flavour of the previous discussions (selected to answer your
question) on the topic from my mail archive.
Georgi and Richard discussing arguments against cycles and
how hard they are to implement:
"
Danov, Georgi wrote:
Hi,
I know it is closed now, however, cycles are something too serious
(for me) to let it just go :
- I know very well the importance of backward compatibility
and the pain of fixing your old mistakes that have become de-facto
standards
- the fact that SE itself has cycles should make it's
developers think if they really need them. It would be interesting for
me to understand, why do we have cycles in SE and what imposed their
existence.
- I am still behind the statement that cycles mean simply
*bad* design, and I've witnessed how huge product was de-cycled
successfully.
- why are cycles bad? Because they create clouds of components
that easily interconnect and create even bigger clouds. At the end, in
order to stop single component, you need to bring the whole
program/stack down.
- in the scope of small to middle application, which does not
need to be modular, cycles work and are not big problem. However, if you
think about platforms, that provide runtime capabilities, cycles harm
their operation.
I am not trying to say that cycles are good, but I don't think these
arguments against them are compelling.
For example, any coupling among components, whether a cycle or not,
creates a "cloud of components".
I agree that cycles should generally be avoided, but supporting cycles
is not the same as encouraging cycles.
My proposal is that the runtime can run with cycle support, but by
default this is off. This way legacy products will have alternative,
plus affordable transition plan. Freshly developed components will not
make use of cycles by default, so hopefully we see growing ecosystem of
cycle-free components.
Another, little more radical proposal is to allow cycles only for
legacy jars that are wrapped as modules. Cycles between 'normal' modules
should not be allowed.
It seems like your fear is that by supporting cycles, then everyone will
try to create cycles every chance they get. I don't think this is the
case. OSGi has always supported cycles, but it is still exceptional to
find the situation (even though it does happen).
-> richard
Georgi Danov
NW JST Deployment
Java EE 5 at SAP
"
Stanley and Richard discussing the complexity issue
raised by an early draft reviewer:
"
I think we have briefly talked about cyclic dependency many months
ago,
but I don't think we have fully discussed it. The early draft
currently
assumes cyclic dependency is supported.
NetBeans manages to work well without supporting cyclic dependencies,
and same as .NET (Visual Studio detects and prevents circular
dependencies to be created in assemblies). On the other hand, cyclic
dependency is supported in OSGi, Ivy, and Maven.
I agreed with the reviewer that supporting cyclic dependencies adds
complexity to the module system, and many cyclic dependencies can be
reduced by proper modularization. The fact that NetBeans and .NET
manage
to live without cyclic dependencies shows that it is possible to
produce
a module system with no cyclic dependency support that can still
satisfy
developers. On the other hand, while direct cyclic dependency can be
detected and avoided, it may be more difficult for developers to avoid
transitive cyclic dependency.
I won't sit here and argue that cyclic dependencies are a must have
feature, but I do think that they are not something that can always be
avoided, especially in the transitive case and even in the case where
you have closely related modules where you still want separation so that
you can have alternate subsystem implementations and independent
updatability.
However, as someone who has implemented large portions of the OSGi R4
resolver algorithm, I can say that supporting cycles was not a
significant source of complication in my code...that was actually the
easy part. :-)
-> richard
"
Glynn arguing for cycles such that modularization can
be incremental:
"
A use case for cyclic dependencies is modularising a large, existing
application. Cyclic dependency support makes it possible to adopt an
incremental approach:
1. overlay existing components with modules and define or generate
module
dependencies based on the existing code dependencies
2. regression test to make sure nothing is broken
3. analyse module dependencies e.g. to spot opportunities for a more
layered architecture
4. incrementally apply the improvements identified in #3, regression
testing after each set of changes.
Note that #4 may take more than one release to complete.
Without cyclic dependency support, the approach tends to be to wrap the
whole application in one big module and then gradually rework the code
structure to permit modules to be broken out into an acyclic dependency
graph. This approach feels quite different - there is a higher
*perceived*
cost to modularisation and a greater inertia inertia in making progress.
I
think this approach doesn't lend itself so well to parallel development.
There are also some admittedly relatively rare but important cases of
pairs
(or groups) of modules in the same subsystem that actually need cyclic
dependencies because of their close relationship but which benefit from
being split into separate modules because of the way the
responsibilities
split between the modules.
Glyn
"
Andy and Stanley discussing tools and warning about cycles:
"
First, I hope everyone had a wonderful holiday break, and have a great
2007!
Andy Piper wrote:
I think tools provided in Java SE should support cycles and creation
of modules with cycles. If its optional it won't get done and you may
as well prohibit them.
I agreed the tools provided in the JDK should support cycles and
creation of modules with cycles. It's the tools outside the JDK that I
think should have the choice to support cyclic dependency optionally.
In terms of defaults I think you should add options to -Xlint or
something equivalent. But if you want something stronger that's
probably ok as well.
So your suggestion is to warn developers when cyclic dependency is
detected, but not necessarily treat it as an error, right?
- Stanley
"
