Just an idea:
I would create a subclass of Hashtable, rewriting serialization code so it won't call
Hashtable code. I mean something like this:
private void writeObject(ObjectOutputStream out) throws IOException {
out.writeInt(this.size());
for (Enumeration keys = this.keys(); keys.hasMoreElements(); ) {
Object key = keys.nextElement();
Object value = this.get(key);
out.writeObject(key);
out.writeObject(value);
}
}
and the opposite for the readObject method.
This way, there is no object creation out of your webapp, while keeping the Hashtable
interface (just take care in hashtable creation and deserialization code. The rest
remains the same)
It seems to me that copying JRE libs into the webapp will cause a very big memory
overhead, as *ALL* core classes will be loaded twice in the JVM.
Hope it helps :)
Rodrigo
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 06, 2002 9:15 AM
Subject: RE: RE: RE: Problems with class loader
> Hi Charlie,
>
> thanks for your mail. After some heavy thinking (gee, this topic lasted
> longer than expected! :-) ), we came to the following conclusion:
>
> We will copy the HashTable.class to the application library. We believe
> this is the best we can do because
>
> (1) we maintain the concept of storing all classes, libraries and
> information as close as possible to the application itself,
> (2) even if HashTable.class changes between different JDKs, we have to
> watch only this happen (i.e., the change of the JDK). Now, this will
> happen, say, once every other year ;-)
> (3) the other alternatives we were discussing are not applicable because
> the expose too much code to too many classloaders.
>
> The good thing is: we can be somewhat sure that the only class other than
> our own classes is HashMap.class. Also, if necessary, we can copy the JRE
> libs to the application.
>
> I think this concludes this discussion. Thanks a lot for the discussion we
> had. I enjoyed it very much!
>
> Jürgen
>
