[kaffe] CVS kaffe (guilhem): Invocation API fixes + Static lock initializer fixes + Kaffe main cleanup.

[Guilhem Lavaux]

Helmer Krämer wrote:
> On Tue, 15 Jun 2004 10:48:07 -0700
> Kaffe CVS <cvs-commits at kaffe.org> wrote:
> 
> Hi,
> 
> 
>>        * kaffe/kaffevm/jni.c
>>        (tryClassForName): New function to be able to catch exceptions.
>>        (Kaffe_FindClass): Initialize a user class loader and use it to load
>>        a class if it has not been found by the default classloader.
> 
> 

Hi Helmer,

> have you tried modifying ThreadStack.getCallersClassLoader() to return
> the AppClassLoader singleton when the stack of the thread contains only
> two or three methods? I think that would be a little simpler and would
> work for every method that requires a classloader, not just FindClass.
> 

There is a problem with this solution: we do not test whether the class 
is in the bootclasspath first. For example, kaffe/lang/AppClassLoader is 
in rt.jar in bootclasspath and not in classpath. If we put a "magic" 
stack size value in getCallersClassLoader, I expect some strange 
problems to arise soon. I have spoken with Julian about replacing 
getSingleton() by a static variable properly initialized with 
AppClassLoader, but this will not work either as we need it to return 
either null or the right class loader depending on the context (and not 
of the stack size) as either we have to look for the user class or the 
class loader (or any of the internal kaffe's classes).

Besides, the problem should arise only when the application is started 
using the invocation API. For the other cases, it is handled "naturally" 
by getCallersClassLoader() by looking at the context.

Regards,

Guilhem.