[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Class loader and serialization
From: |
Guilhem Lavaux |
Subject: |
Class loader and serialization |
Date: |
Thu, 14 Aug 2003 11:45:45 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 |
Hi,
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.
- Class loader and serialization,
Guilhem Lavaux <=