Re: [cp-patches]: Patch: UIDefaults fix

[Meskauskas Audrius]

These two loaders I believe should be the same by default, but there is 
a method in Thread to set the thread context class loader directly. This 
can help as workaround when the user classes must be loaded from some 
other place. For instance, when we run Mauve test, the system class 
loader = default context class loader = loader, used to load the 
application is the loader who started the Ant. It will not load any test 
class by name because these are loaded by the custom Ant class loader.

To get the test work, I obtain the class loader of the testlet and 
temporary set it as a context class loader for the thread that enters 
the Testlet.test. Then Thread.getConextClassLoader() in the testlet 
returns the correct loader, even if called from another thread, 
constructed inside the Testlet.test.

I would suggest to think twice before using Class.forName in the core 
class. Class.forName there means "use the loader of the current class" = 
"use system class loader". And the system class loader only knowns about 
GNU Classpath classes and about nothing else.

Sun's CORBA somehow manages to find classes that are not visible by both 
system and context class loaders, but are present in the execution 
stack. I was only able to implement the same with the help of 
VMStackWalker, as it was suggested by Jeroen.

Tom Tromey wrote:

> > > > > > "Audrius" == Meskauskas Audrius <address@hidden> writes:
> > > > > >            
>
> Audrius> getSystemClassLoader returns the different loader that
> Audrius> has loaded the application, same as the default
> Audrius> Thread.getConextClassLoader() that I would use in this case.
>
> We have a few PRs in this area.  What we need are test cases to
> determine whether the system or context class loader ought to be used.
>
> Tom
>
>
>