>>>>> "John" == John Olsson <[EMAIL PROTECTED]> writes:
>> [ Diversion:- Incidentally this shows that a class in the JVM is
>> not the same thing as a java type. Im working on this because I
>> think it means I can load a new class def into a still running
>> jvm without removing the old.
>>
John> Each class loaded by the JVM has one class loader associated
John> with it. You can not remove an already loaded class from a
John> class loader since the ClassLoader class keeps a private
John> reference (I think it uese a HashTable, but I might be wrong)
John> to each loaded class.
Its a vector. The class loader keeps the package name in
a hashmap. Why the difference? I dont know!.
John> But you can have multiple class loaders, and that
John> is what for instance a JVM in a browser have. The nice partt
John> of this is that the same class loaded by two different class
John> loaders are considered to be *different* by the JVM. They
John> don't even share static data with each other.
John> Thus the only way to load a new class definition into a JVM is
John> to use a new class loader.
My plan exactly.
I have a nice test case of this working, where I load a class
(as it happens from two different places) twice. The two class
definitions produce different Class objects and can even be different
themselves. I havent tried the "type-spoofing" trickyness of passing
an object of a class to a second class loaded with a second class
loader yet. Sun were supposed to have fixed this, but I dont
understand the fix, and its fun trying to get the JVM to core dump.
Anyway the point is that by writing an appropriate class
loader and a few changes to the jde Java code it should be possible to
recognise changed classes and load them without killing the beanshell
in between.
The only problem is that because of the totally different
class loading schemes I doubt that the same solution would work in
1.1, and 1.2.
John> There are some other problems with class loaders which I think
John> is a buggy implementation, but I don't know if SUN agrees with
John> me. When using JNI and native libraries, you can *not* load
John> the same native library with two different class loaders if
John> they use exactly the same path to the native library. If they
John> use different paths it works as it should.
This doesnt sound good at all to me. Is it fooled by symlinks?
I havent read the JNI specs nor ever written any native libraries so I
have no idea whether it comes up the spec or not, but it doesnt sound
good.
Phil
