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 " -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
