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) :
"Because each class loader has its own name-space, a single Java
application can load multiple types with the same fully qualified
name. A type's fully qualified name, therefore, is not always enought
to uniquely identify it inside a Java Virtual Machine instance. If
multiple types of that same name have been loaded into different
name-spaces, the identity of the class loader that loaded the type
[...] will also be needed to uniquely identify that type."
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.
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).
CT> no problem, and thanks for the bug report!
Thank you for your answer. And, the next step for me is to run Japhar
;-)
Bye,
Jp.
