Jean-Philippe Lesot wrote:
>
> Hi,
>
> CT> The class-repository stuff is only used for "system" classes - those
> CT> loader by the primordial classloader. any subclass of Classloader is
> CT> supposed to maintain its own hashtable.
>
> According B. Venners in 'Inside the JAVA Virtual Machine' (p. 89) :
>
[ snip ]
> Here is my understanding of the Japhar source. Please, tell me if I am
> wrong. When a class need to resolve another class, it call
> resolveClass, which call find_class. Whatever the class is, or not, a
> "system" classes (exept for java/lang/String, java/lang/Class and
> java/lang/Object), find_class call the find_class_in_repository, which
> call find_class_list_in_repository, which make the compirison only on
> the name (!strcmp(name, getClassName(env, cl->cf))) and not the class
> loader. Nowhere there is a call to the 'user' ClassLoader.
ah, now this is a problem.
> In Kaffe source, for exemple, the lookupClassEntry function (from
> classMethod.c) make the comparison on the name _AND_ the class loader
> (equalUtf8Consts(name, entry->name) && loader == entry->loader).
If the classes are actually going to make it into the class repository,
then a similar check to kaffe's should be used. they don't necessarily
have to, though -- each ClazzFile* has a classloader slot - when
resolving a class we could just call into its classloader (if it's set)
and call find_class (if it's not.)
xtoph
