Nature of ClassLoading, special circumstance(?)

Question

Let me start with some skeletal code:
class MyCustom extends Thread{
BufferedReader br; PrintWriter pw; Socket sock;
public MyCustom(Socket s)
/*set stuff here*/
public MyCustom(Socket s, BufferedReader b, PrintWriter p)
sock=s; br=b; pw=p;
public void run(){*do something*/}
public BufferedReader get_br(){return br;}
public PrintWriter get_pw(){return pw;}
public Socket get_sock(){return sock;}
Given the above, let's say that a new version of MyCustom.class is to be downloaded, but the Socket should remain open.... I have a second class that does not change in this manner, so...
class MyPlaceHolder extends Thread{
Socket sock; BufferedReader br; PrintWriter pw;
public MyPlaceHolder(Socket s, BufferedReader b, PrintWriter p)
sock=s; br=b; pw=p;
public void run()
/*do some sending and receiving*/
public Socket get_sock(){return sock;}
public BufferedReader get_br(){return br;}
public PrintWriter get_pw(){return pw;}
Ok... Here is the scenario... When it is ready to update that MyCustom.class file, it does this:
(given a MyCustom mc already existing):
some_method(){
MyPlaceHolder mph = new MyPlaceHolder(mc.get_sock(),mc.get_br(),mc.get_pw());
new Thread(mph).start();
mc = null;
System.gc();
/*download new .class file for MyCustom, replace old one, and then*/
mc = new MyCustom(mph.get_sock(),mph.get_br(),mph.get_pw());
new Thread(mc).start();
Maybe I am convoluted in my stating of what I want to do... The crux of my question is this:
1- When I go to create a new 'MyCustom', does it load dynamically, or does it cache the older object code for MyCustom.class?
2- When does the class load...?
In the following class:
class Yoyo{
TextField tf; TextArea ta; Panel p; Frame f; Vector v;
public Yoyo()
tf=new TextField(20); ta=new TextArea("",10,20); p=new Panel(); f=new Frame("Frame"); v=new Vector();
When are the java.awt.TextField, java.awt.Panel, java.awt.TextArea, java.awt.Frame and java.util.Vector actually loaded? At the 'import' statement?
OK... what about custom classes?
Are they loaded at the declaration, or at the constructor?
Thanks,
Dave

Answer 1

Well, no, not quite...close though.
You can download the MyClass.class as many times as
you want, but the class definition is only loaded into
the primordial class loader the first time. Each and
every time you want to change its definition, you have
to supply a new ClassLoader and tell it to load the
class; the JVM doesn't do that for you.
All classes not already loaded into or available to
the primordial class loader that are referenced by
MyClass.class are then loaded by the same custom class
loader automatically. For that reason, you should
avoid loading MyClass.class with the primordial class
loader. This since you can never get rid of it once
it's loaded into the primordial class loader, and
custom class loaders defer the search of classes to
the primordial one before searching for new ones
themselves.Thats true if your new class loader uses the findClass method (class loader delegation model) but if the loadClass method was derived then if you don;t call super.loadClass then the system class loader is never called for this class, so you can stop classes from getting loaded from the system class loader this way.
With the java hotstop some classes are automatically loaded from the system class loader like [B, which is the class name for a byte[] (which does have a class of its own), even if you derive the loadClass method.
The classic vm still calls the loadClass method for classes like this.
>
A bit convoluted, perhaps? :)
It's not altogether easy, I admit.
Here's an example:
You have a class A that hasn't been loaded. A
uses JPanel, JFrame, etc. You simply type new
A(), and it's loaded by the primordial class
loader.
Then you create your own custom ClassLoader C,
and tells it to define A. Now it won't, since A is
already defined in the primordial class loader, and C
asks the primordial class loader "do you know what
this is, or can you find it"? Only if the answer is No
to both those questions does C go about defining the
class.
You can go around that by not having C asking
the primordial classloader first, but then you have to
redefine every class, recursively, that A refers to,
inside C...that, you don't want to do. Some are not
even allowed, such as those beginning with "java.".
You could delegate the java. classes with the super.loadClass method described earlier but
There is a sneaky way of defining classes which start with java.
by (using introspection and setting accessibility to true) call a function call define0 which is private to ClassLoader.
Now... if you had told C to define A instead of using
"new A()", then only those classes that don't already
exist or can't be found by the primordial class loader
would be loaded and defined by C. Meaning JPanel et al
definitions would still come from the primordial class
loader, since it can find them in its class path.
if you told C to define A and still did "new A()" then the class would be
loaded in C and the System class loader because C is higher in the class loader tree and would be asked..
Using the class loader delegation model.
D     E     a call to new A() in a class defined by both of these
| |     class loaders would load the class in both only if C
+========+     and the system class loader didn't have it loaded first.
|
C     a call to new A() in a class defined by this class loader would
|      load the class in C only if the system class loader didn't have it      |     first
|
System a call to new A() in a class defined by the system class loader           would load A in the system class loader even if loaded in C           first.
Back to the original problem,
tomcat does this with its ServletLoader class, if the jar file which loaded the servlet changes then the ServletClassLoader is thrown away and a new classloader is created and the classes are reloaded, this is open so you can see the source for this at www.apache.org