Dynamic switching of classes

Newbie & Debugging Questions
#1

Hi all,
I have heard in some place that I can dynamically switch classes during runtime using some sort of API. Does anyone know what im talking about? or am i just imagining stuff?

I.e. I have this class, and basically, with a command to hotspot, i can change its instance to another class…

Basically, im making this real-time game editor and in which you see the code, you can alter the code, then janino kicks in and it dynamically compiles that code. Thats working fine, i just need a way to change the instance of the class to use the new one…

DP

#2

Yes, there are two solutions, but they take soem explaining.

The first is that Hostpot 1.5 contains a new API to switch method code on the fly. Ive never sued it so can’t tell you much about it ewxcept its ONLY for repalcing the code of a method with other code-- you cannot add or remove methods nor can you chnage fields.

However there is an older technique called class unloading that lets you do all of that. The way it works is this:

A Class is a just an object like any other object in Java. If there are no references to that class, it can get garbage collected and then the next time that class is refernced it will be reloaded.

However, once a class is laoded by a ClassLoader , the class loader keeps a reference to that class. Therefor in order for their to be no rererences to the class, there first have to be no refernces to the ClassLoader that loaded it.

All instances of classes keep a reference to the class loader that loaded the calss their are an instacne of. So all of thsoe instance objects have to go de-referenced first.

THEREFOR to truly unload a class, you need to delete all the instacnes of ALL the calsses that were laoded by the class loader that laoded that class. It turns out in order to do this you need to use a custom class loader to load the classes you want unlaoed as the classpath class loader and the boot class loader by definition always have class instances that are “live” and refernced as long as the VM is running.

Additionally classes are relative to the class laoder theya re laoded by. Class “foo” loaded by class laoder A is a different class then class “foo” loaded by class laoder B. So in order to re-load a class, you need to create a new class loader and load the class through it, then use that class loader to create your instances.

If all you want to do is create a new object that is an instacen of the new version of the class then thats really all yo uhave to do. If however you want to “update” an objectand rpeserve its calues then you need to get fancier, Basically you need to store the valeusin some form that cnba then be laoded into the new instance of the object. The simpelst way is to serialize the obejct into memory and the de-serialize it using the new vclass laoder.

if al lthis seems abit complex, frnakly, it is. Class loaders are one of Java’s most powerful features but they arent for thsoe just trying to figure otu how to program basic code. Theya re an advanced feature that take even experienced programmers some tiem to really learn to use well.

Anyway I hope that helps some.

#3

The basic structure we’re using in… uh… fluffware (there isn’t a real name yet) is like this:

while(run_render_loop)
{
   get the graphics object
   if(reloadscript)
   {
      try
      {
         reload the script
         setup stuff
         scripterror=false
      }
      catch(shithappens)
      {
         set errormessage
         scripterror=true
      }
   }
   if(scripterror)
   {
      render errormessage
   }
   else
   {
      try
      {
         pass variables to interpreter
         call tick() through interpreter
      }
      catch(shithappens)
      {
         set errormessage
         scripterror=true
      }
   }
   dispose the graphics object
   frame throttle
   show the frame
}

It can eat beanshell scripts, jython or classes.

The class reloading bit just looks like this:

URL url=getClass().getResource(MODULE_PATH+"/"+script_name+"/");
URLClassLoader cl=URLClassLoader.newInstance(new URL[]{url});
playable=(Playable)cl.loadClass(main).newInstance();

(Playable is the name of the interface with init(), tick(), render() etc, which we are going to call later on)

[Oh and you might want to use Janino’s JavaSourceClassLoader instead.]

I think it’s pretty neat this way. You can do agile developing with beanshell and just make it a class at the end for getting a nice speed boost. It’s like eating the cake and having it, too :wink:

Another option I’ve seen somewhere is a compiling classloader, which performs a date check and compiles it before loading if the source date is newer.

Either way… you need to get rid of the old classes if you really want to see the latest changes in action. In the example above it’s easy… there is only one Playable object, which gets first nullfied and then (hopefully) overwritten. If init() of that Playable object is called it tries to load the media through the managers… if that stuff has been loaded before the cached reference(s) gets returned otherwise it’s loaded for real. And if you want to reload the media (eg you made a new texture for something) you need to clear the managers, reload the script… init.

So, you need a “restart hook”. Several infact if you want some granularity. In the example above it’s only “logic” and “logic+media”. That is more than enough for prototype-ish and/or small games.

Well, I pretty much gave up using Janino. The error messages are irritating and it has problems with bigger source files (eg 500lines of code with quite a lot of operators won’t compile).

#4

Dont you mean making the cake and eating it too? :wink:

Anyways, i’l explain what im doing, its a game editor. The editor has little buttons for adding/removing/modifying stuff in the scene…blah blah blah, the usual. However, with this editor, you can grab the sourcecode of the generated game, modify it on the fly, compile and load. However, the game is running at the same time, so i just need a way to change the class instances. The only reason for wanting to do such a thing is for custom AI routines, specialist game things, like controllers and whatnot…so thats why i need the code.

I thought of one way, and that was to generate the code for the game upon exporting, and then let them do the rest through their favourite IDE, but it just doesn’t feel right. So now im thinking of actually allowing the user to ADD things ontop of the code via Beanshell instead of actually modifying the current code, and that would mean doing something like onyx suggested…

I’l think of something! thanks for all your help guys, really appreciate it.

Btw onyx, so you dont recomend Janino anymore?

DP

#5

Dont you mean making the cake and eating it too?

No. It’s a bastardized phrase. “You can’t eat the cake and have it, too”… that is because if you eat it it isn’t there anymore.

Btw onyx, so you dont recomend Janino anymore?

Well, Janino isn’t ment to be used as a development tool and you’re really going to notice that if you use it as one. As long as it works it’s really fast and sweet… and things will grow to a point where janino just blows up for no apparent reason. Some of the most cryptic bugs have been already fixed, but some things aren’t going to be fun for the foreseeable future… like those non helpfull error messages.

With beanshell it’s more fun, but it’s interpreted and therefore slower (much slower). But it isn’t a big deal if you replace those scripts with compiled classes at the end.

If it’s ment to stay scripted I would pick a faster scripting language. Here is some kind of benchmark. I’m not sure how accurate it is, but it should give you an idea.

#6

Hmm, its definetly an interesting benchmark. From your previous suggestion, i did start to use Beanshell. However, looking at this benchmark, it seems Groovy is a better option.

Ive always been interested in playing with Groovy, i guess its time has come :slight_smile:

DP