Dynamic Class Reloading

[Michael McMahon]

Robert Marcano wrote:
> On Sat, Jul 4, 2009 at 12:54 PM, Andrew Wiley<debio264 at gmail.com> wrote:
>   
>> I'm looking for something more general than that... let me just describe the
>> functionality I'm trying to achieve.
>> I'm writing a MUD (it's basically a text-based RPG), and I'm trying to come
>> up with some equivalent for the "copyover" or "hot boot" functionality that
>> MUDs written in C and C+ have. Basically, they write the state of the game
>> out to a file, have the MUD execute itself, and then load the game back up.
>> In this way, a MUD can reboot without disconnecting any of the players. The
>> socket descriptors aren't closed during the reboot, which I believe cannot
>> be replicated in Java.
>> In Java, I was hoping I would just be able to reload classes without
>> rebooting the MUD to come close to duplicating this functionality.
>>     
>
> I think that still can be done with an standard JVM, use you own
> classloader, be careful making you class serialization works when the
> classes definitions change, the only problem you will have is that
> released JVMs does not have a way to free the classloader you are
> discarding, something that is being resolved with OpenJDK 7, so each
> time you "reboot" you will not free the memory used by the previous
> classloader (class definitions not instances data)
>
>   
In jdk7, the standard URLClassLoader now has a close() method, which 
allows a class loader instance
to be disposed of. So a new instance can be created, with (potentially) 
new implementations of any classes.

If you want to keep sockets open, then the Socket objects would have to 
be managed by a layer above
the class loader though.

Michael.