No, that doesn't put a kink in anything, surely?
1. The OBJECTS created from different classes can all still interact without problems. In fact, the only problems you will see are that newly instantiated objects will fail the "instanceof" check, and that typecasts to the class will typecast to the new version even if the instance is of the old version.
Ok, that they can interact is a relief.
Now to ask for some clarification (taking part of this from cylab's post as well):
I'm going to be using this system (assuming I can get it to work
) as a way to load different versions of plugins. All plugins implement one interface, and depending on what functionality they provide, they implement one or more sub-interfaces (that extend the base plugin interface).
Assuming I load the interfaces with the bootstrap classloader, would different instances of the plugin class (loaded by custom classloaders, different instances for each version) still be castable to the plugin interface (and the relevant sub interfaces)? Or would that cause a ClassCastException?
NB: this is one of my suspicions about autoboxing - surely inserting typecasts in code is not a good idea, generally speaking, in a language where typecasts themselves refer to something dynamic?
2. Just make sure all the classes that you AREN'T changing are visible in both classloaders. This is actually *trivial* because java's default behaviour is to have a chain of classlaoders so that you implement the custom loading for one class and you automaticallly inherit the loading of all other classes without having to write any code for it.
Yes, I was already planning on a custom classloader, so I don't see this being hard to implement.
Or ... I think, maybe (not sure here): you can create a custom classloader that returns a different class object at different times. This requires some mangling of the classloader chain as well, from memory - you need to make sure that the new class you're sending doesn't get cached when you want to replace it with a newer one.
(he says, from distant memories of how he did this last time).
I've certainly done it before, I just can't 100% remember how right now.
Well, if I understand the article correctly, when I want to unload a class, I need to de-reference all instances of classes loaded by a specific classloader, then de-reference the class loader itself.
Then (assuming the JVM actually unloads the classes and doesn't cache), I need wait for the class loader to be GC'd (to prevent caching of the classes), then create a new instance of the class loader and load up a different version of the class file.
This is for a chat automaton I'm writing, it's going to be serving as a raid control "bot", so it needs maximum up-time. I'd rather take the time to implement a complex solution like this, than listen to people whine at me for hours on end for a new version of a plugin crashing the bot and it not being able to work right, rather then being able to revert to an older plugin version
:edit: fixed some abysmal spelling :/edit: