Thread context class loader...

[Richard S. Hall]

And my point remains, OSGi has always supported cycles and they have not 
been abused.

-> richard

Adrian Brock wrote:
> 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
> "
>