Dynamic Class Reloading

[Andrew Wiley-2]

I'm fairly new to OpenJDK, and I'm wondering if there's any way to reload a
class while an application is in operation. There's JavaRebel and Apache JCI
to do this with the Sun JDK, but I don't know if there's an equivalent for
OpenJDK.
I have a server application that I want to be able to update without
rebooting it. I would like to at least be able to reload classes when the
signature doesn't change. These would be classes on the classpath that are
used normally (directly, not through reflection) in the application. Is this
possible?
On a side note, I'm fairly sure this has been done, but does OpenJDK run on
ARM systems?

[Peter B. Kessler]

Andrew Wiley wrote:
> I'm fairly new to OpenJDK, and I'm wondering if there's any way to reload a
> class while an application is in operation. There's JavaRebel and Apache JCI
> to do this with the Sun JDK, but I don't know if there's an equivalent for
> OpenJDK.
> I have a server application that I want to be able to update without
> rebooting it. I would like to at least be able to reload classes when the
> signature doesn't change. These would be classes on the classpath that are
> used normally (directly, not through reflection) in the application. Is this
> possible?

If you can describe the part you want to reload as an interface, you can change the implementation behind the interface at any time by having your own classloader.  Nothing JDK-specific is required, nor is anything needed beyond what's already in the JVM.

                        ... peter

[Andrew Wiley-2]

On Sat, Jul 4, 2009 at 1:47 AM, Peter B. Kessler <Peter.Kessler@...>wrote:
>
>
> If you can describe the part you want to reload as an interface, you can
> change the implementation behind the interface at any time by having your
> own classloader.  Nothing JDK-specific is required, nor is anything needed
> beyond what's already in the JVM.
>
>                        ... peter
>

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.

Andrew

[Robert Marcano]

On Sat, Jul 4, 2009 at 12:54 PM, Andrew Wiley<debio264@...> 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)

--
Robert Marcano

[michael.mcmahon]

Robert Marcano wrote:

> On Sat, Jul 4, 2009 at 12:54 PM, Andrew Wiley<debio264@...> 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.

[Peter B. Kessler]

Robert Marcano wrote:

> On Sat, Jul 4, 2009 at 12:54 PM, Andrew Wiley<debio264@...> 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)

The ClassLoaders and the Classes they load will be garbage collected when there are no more instances of *any* Classes loaded by that ClassLoader.  Each Object instance has a reference to its Class, and each Class has a reference to its ClassLoader, and each ClassLoader has a list of all the Classes it has loaded.  When there are no more instances of any of the Classes, there are no reachable references to the ClassLoader.  It's sometimes tricky to make sure your application drops all references to the instances.  That's among the reasons you want to write your own ClassLoader, so that Classes you have replaced can be collected.  And among the reasons you want your ClassLoader to load as few classes as possible, so extraneous objects don't end up hanging on to the ClassLoader and all the other Classes it loaded.

                        ... peter