Just FYI : http://classworlds.codehaus.org/ allow non-hierachical classloader

/davidB

On Tue, Dec 2, 2008 at 13:29, Ricky Clarkson <ricky.clarkson <at> gmail.com> wrote:
> Just to be clear, I'm not suggesting that Scala should use its own
> classloader, just that supporting what Bruno wants wouldn't require
> abandoning separate compilation or moving off the JVM.  Also, I expect it
> doesn't cause a huge problem to have two jar files both containing a
> generated AB.class (or a mangled name).
>
> 2008/12/2 David MacIver <david.maciver <at> gmail.com>
>>
>> On Tue, Dec 2, 2008 at 11:38 AM, Geoffrey Alan Washburn
>> <geoffrey.washburn <at> epfl.ch> wrote:
>>>
>>> Ricky Clarkson wrote:
>>>>
>>>> Would I be correct in saying that to support what Bruno wants without
>>>> problems Scala would have to introduce its own classloader?
>>>
>>> Using a custom classloader might work.  However, based upon what Martin
>>> has told me, the Java classloader design is completely broken because it is
>>> not compositional.  Therefore, requiring a custom classloader for Scala
>>> programs completely rules out the ability to use Scala in a number of
>>> important places, like Eclipse, where an alternate classloader cannot be
>>> specified.
>>
>> No, I don't think that's true. As long as the classloader setup is such
>> that it correctly delegates to a provided parent classloader it should be
>> fine to make work. e.g. it's perfectly fine to run JRuby inside an OSGi
>> container, and JRuby does much crazier things with classloaders than Scala
>> would ever need.
>
>