MickeyB
JGO Ninja  Posts: 547
my game will work, my game will work!
|
 |
«
on:
2004-01-05 20:42:02 » |
|
think mud server. some have a surface scripting language that allows you to add content real-time. but what about changing core code and recompiling while maintaining state and connections? possible? want to be able to to add a new function or command on the fly during live play.
|
|
|
|
Herkules
JGO Kernel Posts: 1522 Medals: 1
Friendly fire isn't friendly!
|
|
«
Reply #1 on:
2004-01-05 23:11:38 » |
|
Hm, java.lang.Class implements Serializable...
So if you manage to implement you features by using a certain base interface(command pattern?), you'll be able to write a ClassLoader that grabs your new functions from the net and executes them.
|
|
|
|
|
Jeff
|
|
«
Reply #2 on:
2004-01-05 23:29:09 » |
|
Right. java is a late binding language so reload is built into the system.
Up to 1.5 the way to reload has been to use a custom calss loader. In order to make the clas loader dump the calsses all the instances have to be gone. I wrote a "reloadable" libnary awhiel back that did this bit of trickery by tracking all insatnces of Reloadables and, whena reload was requsted, serlializing then all to byte buffera temporarily, making a new class loader and de-serializing them using it.
I believe our 1.5 actually has some preliminary support for dumping and reloading method code indvidually (though not fields yet).
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
blahblahblahh
JGO Kernel Posts: 4575
http://t-machine.org
|
|
«
Reply #3 on:
2004-01-06 04:21:50 » |
|
I believe our 1.5 actually has some preliminary support for dumping and reloading method code indvidually (though not fields yet).
That would be very cool (and if so, we'll be able to make some funky demos to show it off; we've done some detailed work in this area, specifically to reload in a complex environment where you need to have both versions loaded and active simultaneously...). Will be interesting to see whether 1.5 makes this any easier. |
malloc will be first against the wall when the revolution comes...
|
|
|
swpalmer
JGO Kernel Posts: 3438 Medals: 4
Where's the Kaboom?
|
|
«
Reply #4 on:
2004-01-06 06:38:45 » |
|
Even with 1.4 debuggers have a change and continue feature... I thought I read that the same mechanism was intended to support patching a live system.
|
|
|
|
|
Jeff
|
|
«
Reply #5 on:
2004-01-07 00:38:13 » |
|
Ah hokay, i didnt realize it was in 1.4 already. Thanks for the correction.
|
|
|
|
Golthar
Jr. Member Posts: 85
;)
|
|
«
Reply #6 on:
2004-01-07 02:06:44 » |
|
Yeah with Eclipse I can do hot code swapping in debug mode
|
|
|
|
MickeyB
JGO Ninja Posts: 547
my game will work, my game will work!
|
|
«
Reply #7 on:
2004-01-08 09:15:51 » |
|
sounds great. so again, thinking mud server, I could create a scripting language or use somehting like Perl to create "classes" or modify old ones and compile and use the above mentioned methods to keep the game alive and get new functionality into it. Devs, coders, admins could essentially say " firebals do too much damage and come fromthe wrong power reserve, edit the fireball spell class, recompile and somehow get it into the live game world. (or am I missing this completely?)
Would love to see some sample code or demos of this just to poke around with.
|
|
|
|
|
Jeff
|
|
«
Reply #8 on:
2004-01-08 15:29:42 » |
|
Yes.
|
|
|
|
swpalmer
JGO Kernel Posts: 3438 Medals: 4
Where's the Kaboom?
|
|
«
Reply #9 on:
2004-01-08 16:30:00 » |
|
With the debugging live code replacement in Eclipse at least, you can not change the "shape" of a class. That is, you cannot add or remove member data or methods.
I do not know if that is inherent in the 1.4 VM or if it is the same in 1.5...
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
MickeyB
JGO Ninja Posts: 547
my game will work, my game will work!
|
|
«
Reply #10 on:
2004-01-08 16:33:31 » |
|
ok jeff, yes I can do it? or yes, I am missing something?
|
|
|
|
|
Jeff
|
|
«
Reply #11 on:
2004-01-08 18:06:59 » |
|
Sorry. yes you can do it.
Class reloading, while a bit of a pain to implement, will allow you to change fields and methods. the new debugger facility will allow you to change just methods.
I am not sure if connecting to the debugger interface has an impact on our VM's performance. It may.
The facility to re-load classes and late-bind btw is why I maintain that (a) Java is an excellent choice for a scripting language and (b) games that are pure Java need no other scripting language.
|
|
|
|
blahblahblahh
JGO Kernel Posts: 4575
http://t-machine.org
|
|
«
Reply #12 on:
2004-01-09 00:22:53 » |
|
Sorry. yes you can do it.
Class reloading, while a bit of a pain to implement, will allow you to change fields and methods. the new debugger facility will allow you to change just methods.
Mucking about with classloading is how we've been experimenting with similar hot-swapping of classes. The real difficulty comes when you need multiple instances of different versions of the same class simultaneously, and things can get nasty. |
malloc will be first against the wall when the revolution comes...
|
|
|
MickeyB
JGO Ninja Posts: 547
my game will work, my game will work!
|
|
«
Reply #13 on:
2004-01-09 07:21:19 » |
|
This is completely new territory to me. I assume there are tutorials on Sun for this? (I am searching now) If not, anyone have some sample or demo code they can scribble on the white board?
Thanks
|
|
|
|
|
Jeff
|
|
«
Reply #14 on:
2004-01-09 18:28:05 » |
|
Read up on custom class loaders. Yes there is info on java.sun.com as well as in the javadoc for ClassLoader and URLClassLoader. There may be an article on class laoders in the article set that comes with the JFK download, I forget. if so thats a good place to start as well.
FInally the classic books on the JDK APIs shoudl all have info. I know thre is info in lee's The Java Class Libraries volumes and the Java2 appendix book in that set.
Once you unndesrstand class loaders the following will make sense:
(1) Every Class Loader contains references to the Classes it has loaded. When a new instance of the class is created the Class is request from the current class loader.
The goal is to replace the Class objects. To do this you need to replace the class loader. You do this by creating a new class loader and requesting the class from it.
If you have old instances whose data you want to rpeserve you need to seralize them to a buffer or to disk and then unserialize them using the new class loader. (This can be accomplished by de-serializing with an ObjectInputStream by explicitly requesting the ObjectInputStream Class from the new class loader and then instancing it.)
Be warned if you are going to do this then you will likely need to over-ride the SerialversionUID. There is info on THAT in the artical on serializatio nthat coems with the JDK.
So, start reading and experimenting! You'll get it eventually and what you learn abotu Java in the process will open up all kinds of new abilities you never realized the language had.
|
|
|
|
MickeyB
JGO Ninja Posts: 547
my game will work, my game will work!
|
|
«
Reply #15 on:
2004-01-10 10:37:46 » |
|
fantastic ...starting today. I did find some stuff on sun to start with.
Thanks again all,
M
|
|
|
|
|
