No subject

Class.forName() paper--they were correcting a few misconceptions on my
part), I discovered that the JVM maintains what they call a "LCC"--a "Loaded
Class Cache"--that stores what classes have been loaded. This is the "cache"
that ClassLoaders used to have to maintain on their own. (It's also what
guarantees that a ClassLoader will only be asked to load a class once by the
VM.)

The short answer: DON'T play with the ClassLoader cache. Just throw away the
ClassLoader instance and start with a new one. (Bury this inside another
ClassLoader--a Decorator, to use the patterns lingo--if you must.)

Ted Neward
Java Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward

-----Original Message-----
From: Stu Halloway [mailto:stu at develop.com]
Sent: Tuesday, September 12, 2000 10:27 AM
To: Advanced-Java; Gokul Singh
Subject: RE: Cust. Classloader


> Thanks for the reply.
>
> I did go through both Teds paper and the AdaptiveClassLoader.java of the
> Tomcat implementation. But I found out that they all talk about
> discarding
> the current classloader and making a new classloader everytime there is
> a
> change in the code.
>
> Is it possible to load the same class again in the *same* classloader
> instance?

No.  At least not safely, reliably, or portably.  If I remember correctly,
from JDK 1.2 on class cacheing is automatic, and VM implementors can assume
that ClassLoaders will never reload a class.  You do not want to violate
that assumption.

That said, it is _trivial_ to just use a new ClassLoader to get the behavior
you want.  And you don't need to write your own implementation, you can just
use a new URLClassLoader pointing to the same old location.  The new
ClassLoader will reload the file for you.  Is there a compelling reason you
cannot do this?

Stuart Halloway
DevelopMentor
http://staff.develop.com/halloway



---
To unsubscribe, mail advanced-java-unsubscribe at xcf.berkeley.edu
To get help, mail advanced-java-help at xcf.berkeley.edu


---
To unsubscribe, mail advanced-java-unsubscribe at xcf.berkeley.edu
To get help, mail advanced-java-help at xcf.berkeley.edu