[kaffe] CVS kaffe (guilhem): Invocation API fixes + Static lock initializer fixes + Kaffe main cleanup.
guilhem at kaffe.org
Wed Jun 16 23:55:03 PDT 2004
Helmer Krämer wrote:
> On Tue, 15 Jun 2004 10:48:07 -0700
> Kaffe CVS <cvs-commits at kaffe.org> wrote:
>> * 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.
> 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.
More information about the kaffe