Dynamical class reload in Java 
Author Message
 Dynamical class reload in Java

Quote:

>one need not. the important difference between the Smalltalk scheme and
>the java scheme is that the newly loaded class does _not_ replace the
>old one, it is simply loaded additionally. instances of the old class
>will still refer to the old class, and when you instantiate the new
>class, those instances refer to the new one.

I beg to differ.  For example, in the case of GemStone, instances of a class
remain instances of that particular class when a new 'replacing' class is
installed.  There are migration options that will allow the instances of the
old class to mutate into instances of the new class.

And at least with respect to VisualWorks, the system could easily be
adjusted to handle this 'multi-class' approach as its default behavior (I'm
thinking of parcels here).  Since 'everything is an object', including
classes (where each class is in fact an instance of its metaclass), there is
no technical reason why you couldn't load a new version of an existing class
and choose not to mutate existing instances.  The only thing that would be
'slammed' in the system would be the reference in the appropriate name space
(traditionally this is the Smalltalk dictionary).

You can even do it yourself - pick a class with instances, file it out, move
the reference to the class in the Smalltalk dictionary to some new name,
file it in.  Ta da - two versions of the same class resident at the same
time.

So now one must ponder the reasons for and against this type approach, at
which point I gracefully exit...

t
--

Arbor Intelligent Systems -- http://www.*-*-*.com/
  "I have not heard of poultry that hadn't wings.  Wings is the SIGN of
     poultry; it is what you tell poultry by.  Look at the mosquito."



Wed, 18 Jun 1902 08:00:00 GMT  
 Dynamical class reload in Java

Quote:


> >one need not. the important difference between the smalltalk scheme and
> >the java scheme is that the newly loaded class does _not_ replace the
> >old one, it is simply loaded additionally. instances of the old class
> >will still refer to the old class, and when you instantiate the new
> >class, those instances refer to the new one.

> I beg to differ.  For example, in the case of GemStone, instances of a class
> remain instances of that particular class when a new 'replacing' class is
> installed.  There are migration options that will allow the instances of the
> old class to mutate into instances of the new class.

the problem with java is that in the most general case (which the java
security system is designed to deal with) you have to assume that the
new class is hostile. it might, e.g. be not trusted, as opposed to the
original class, and thus the original might have accumulated state that
the new one was never supposed to touch (private data, e.g.).

not to speak of the possibility that the new class might be completely
different altogether. in fact, the only thing that you can be sure about
in two like-name classes is that their name is the same. otherwise, they
may occupy different places in the class hierarchy (in fact, class A
might have a subclass B, which is the super class of A', which replaces
A, and other crazy situations.), have entirely different signatures,
might have completely differently structured states etc. there is no way
to relate two such classes anywhere close to generally, and since you
cannot trust the newcomer to do that for you in any meaningful way, the
java design was made for the more secure, albeit less dynamic way. in
any case, strategy patterns together with type-safe loading of classes
still provide quite a bit of flexibility.

Quote:
> And at least with respect to VisualWorks, the system could easily be
> adjusted to handle this 'multi-class' approach as its default behavior (I'm
> thinking of parcels here).  Since 'everything is an object', including
> classes (where each class is in fact an instance of its metaclass), there is
> no technical reason why you couldn't load a new version of an existing class
> and choose not to mutate existing instances.

classes are objects in java, too. and the reasons are not exactly
technical (although in the java context at least, the mess you would get
yourself into if you wanted to deal with general cases and untrusted
classes, is quite considerable) but have to do with java security
guarantees. i see no way of maintaining them if you mutate instances to
new classes.

Quote:
>  The only thing that would be
> 'slammed' in the system would be the reference in the appropriate name space
> (traditionally this is the Smalltalk dictionary).

> You can even do it yourself - pick a class with instances, file it out, move
> the reference to the class in the Smalltalk dictionary to some new name,
> file it in.  Ta da - two versions of the same class resident at the same
> time.

this is in fact the standard case in java when loading classes in the
way i suggested. except that you are not free to change class names at
will.

i am _not_ advocating any particular solution, i'd just like to give the
rationale for java's way of doing it, as far as i understand it.

best regards,

--   J?rn W. Janneck

------------------------------------------------------------------------
J?rn W. Janneck       Computer Engineering and Networks Laboratory (TIK)
Gloriastrasse 35                                              ETH Zrich
CH-8092 Zrich                                               Switzerland

------------------------------------------------------------------------



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. GUI class reloading testrunner for TestUnit?

2. How to change class instances behavior via reload?

3. reload causes unbound methods to fail for old class instances

4. Java Object Not Returned/Java Class Not Preserved

5. Java class path and remote classes on server

6. Smalltalk Collection Classes to Java JGL Classes Mapping

7. The Dynamical Systems and Technology Project at Boston University

8. Dynamical function creation ?

9. Call a dynamical VI doesn't work

10. Dynamical Loading of Data Types

11. Trying to grasp possibilities of dynamical Ruby

12. Dynamical Proto

 

 
Powered by phpBB® Forum Software