it seems there is a misunderstanding problem between kaffe's class loader
mechanism and classpath's serialization. Here is the current state:
* ObjectInputStream builds class decriptors from input stream, or if it
is not described build them from classes directly. To do so it resolves
classes using Class.forName(name)
* It needs to build each inner fields: it it is a "natural" type (int, ...) it is
constructed directly but if it is an object it uses
gnu.java.lang.reflect.TypeSignature.getClassForEncoding to build it.
This method calls Class.forName(name) to get the corresponding class.
The second step is the most problematic (the first may also cause problems
but they are marginal and if we can solve the second it will also be solved):
gnu.java.lang.reflect.TypeSignature has been loaded using the native class loader
(or more precisely the bootstrap class loader). But this class loader does not have
access to locally defined classes and this causes the regression test Alias.java
to halt (as pointed out by Dalibor ;) ). Kaffe's former implementation seems
to have solved this problem by resolving classes using the first non-null
class loader in the calling stack. Apparently, JDK use a similar mechanism
because its serialization code is capable of not taking ObjectInputStream's
class loader (which is null) but Alias's class loader (which sun's app class loader).
Would it be possible to add in classpath this sort of mechanism ? I mean dumping
the calling class stack so we can fetch the right class loader.
Cheers, Guilhem.
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
