Looking at this and your other message, I think I see what you're trying  
to do - you believe that by somehow modifying the memory allocated to  
instances you'll be able to modify methods. Perhaps you're thinking of  
implementing dynamic invocation along the lines of Smalltalk and Ruby?

I think I've as open a mind as anyone with this kind of stuff, but take it  
from me that's just not possible given the architecture of the JVM. The  
memory you're hoping to modify has nothing to do (directly) with the  
methods, and the separation between classes and instances is almost total.  
It's not possible, with the current architecture, to do anything more than  
emulate this kind of thing (a-la Groovy, in which nearly every call is  
reflective, and it shows, or Nice which I believe uses tableswitch to do  
it), and then it can't be integrated directly with the Java language.

As I said in my reply to your other message on c.l.j.help, the tools are  
available, but even with all the flexibility in the world I doubt you'll  
get what you're after. "Changing software without stopping it" does have  
some attractive points, as you say, but this isn't how it's going be done  
I think, at least in Java.

(Which is also to say: If you do achieve it, I'd be very interested in how  

The way you do that is to use custom class loaders.  Then you can have
two different object layouts with different sets of methods, with the
same name living simultaneously in the same JVM. Once you convert your
old objects to new, or they all die a natural death, you can delete
the corresponding class loader and recover all the old method space
too.

see http://mindprod.com/jgloss/classloader.html

If the reason you want to do this is to experiment, to learn, and to play with
new concepts then go ahead: have lots of fun!  You might even get a research
paper out of it (although dynamic modification of class definitions is not
itself new -- it has been around since at least the 1980's).

The rest of this reply is on the assumption that that's /not/ the case.  If you
/need/ to do this -- i.e. you have a design for "real" code (code that will be
used in a production environment by real people to help with real problems)
then I don't think that's the right way to approach it.  You will never be able
to make it work reliably if you base it on a production-grade JVM, and you
can't use a less-than-production-grade JVM as the basis for a production
system.

The "correct" way to allow classes to change definition are:

1) Use classloaders.  This will allow several versions of the "same"
(same name) class to exist -- at the same time if necessary.  The big problem
is that you can't change the definition of the class of an existing object --
you can create a new definition of a class, but all the instances of the old
class remain just that: instances of the old class (which does not change).

2) The other way is not (IMO) suitable for production code, which is to use the
debugging API to change the definition of the running code.  That is severely
limited, and in any case not supported by all JVMs.  But within (mostly
undocumented) limits you can modify classes in a running application.

3) The last way is simply to give up on Java.  Its designers and the creators
of its JVM definition (and the canonical implementation) -- Sun -- simply do
not "get" dynamic languages.  So there is no real support for dynamic
operations.  You either have to use a complete layer of interpretation above
the JVM stuff (which amounts to using a different language) or you use an
explicitly different language which doesn't have a crippled semantics.
Personally I prefer Smalltalk, but that is by no means the only languages with
the ability to handle dynamic constructs, for instance Ruby and Python are both
dynamic.

   -- chris