need design/pattern/structure help on coding up a java 'world'

Question

I've always wanted to write a simple world in Java, but which I could then run the 'world' and then add new objects (that didn't exist at the time the world started running) at a later date (to simulate/observe different behaviours between future objects).

The problem is that I don't want to ever stop or restart the world once it's started, I want it to run for a week without having to recompile it, but have the ability to drop in objects and redo/rewrite/delete/create/mutate them over time.

The world could be as simple as a 10 x 10 array of x/y 'locations' (think chessboard), but I guess would need some kind of ticktimer process to monitor objects and give each one (if any) a chance to 'act' (if they want to).

Example: I code up World.java on Monday and leave it running. Then on Tuesday I write a new class called Rock.java (that doesn't move). I then drop it (somehow) into this already running world (which just drops it someplace random in the 10x10 array and never moves).

Then on Wednesday I create a new class called Cat.java and drop that into the world, again placed randomly, but this new object can move around the world (over some unit of time), then on Thursday i write a class called Dog.java which also moves around but can 'act' on another object if it's in the neighbour location and vice versa.

Here's the thing. I don't know what kinda of structure/design I would need to code the actual world class to know how to detect/load/track future objects.

So, any ideas on how you would do something like this?

Answer 1

I don't know if there is a pattern/strategy for a problem like this, but this is how I would approach it:

I would have all of these different classes that you are planning to make would have to be objectsof some common class(maybe a WorldObject class) and then put their differentiating features in a separate configuration files.

When your program is running, it would routinely check that configuration folder for new items. If it sees that a new config file exists (say Cat.config), then it would create a new WorldObject object and give it features that it reads from the Cat.config file and drops that new object into the world.

If your program detects that one of these item's configuration file has changed, then it find that object in the World, edit its features and then redisplay it.

When the program looks in the folder and sees that the config file does not exist anymore, then it deletes the object from the World and checks how that affects all the other objects.

Answer 2

I wouldn't bet too much on the JVM itself running forever. There are too many ways this could fail (computer trouble, unexepected out-of-memory, permgen problems due to repeated classloading).

Instead I'd design a system that can reliably persist the state of each object involved (simplest approach: make each object serializable, but that would not really solve versioning problems).

So as the first step, I'd simply implement some nice classloader-magic to allow jars to be "dropped" into the world simulation which will be loaded dynamically. But once you reach a point where that no longer works (because you need to modify the World itself, or need to do incompatible changes to some object), then you could persist the state, switch out the libraries for new versions and reload the state.

Being able to persist the state also allows you to easily produce test scenarios or replay scenarios with different parameters.

Answer 3

Have a look at OSGi - this framework allows installing and removing packages at runtime.

The framework is a container for so called bundles , java libraries with some extra configuration data in the jars manifest file.

You could install a "world" bundle and keep it running. Then, after a while, install a bundle that contributes rocks or sand to the world. If you don't like it anymore, disable it. If you need other rocks, install an updated version of the very same bundle and activate it.

And with OSGi, you can keep the world spinning and moving around the sun.

The reference implementation is equinox

---

BTW: " I don't know what kinda of structure/design " - at least you need to define an interface for a "geolocatable object", otherwise you won't be able to place and display it. But for the "world", it really maybe enough to know, that "there is something at coordinates x/y/z" and for the world viewer, that this "something" has a method to "display itself".

Answer 4

If you only care about adding classes (and not modifying) here is what I'd do:

• there is an interface Entity with all business methods you need ( insertIntoWorld() , isMovable() , getName() , getIcon() etc)
• there is a specific package where entities reside
• there is a scheduled job in your application which every 30 seconds lists the class files of the package
• keep track of the classes and for any new class attempt to load class and cast to Entity
• for any newlly loaded Entity create a new instance and call it's insertIntoWorld() .

You could also skip the scheduler and automatic discovery thing and have a UI control in the World where from you could specify the classname to be loaded.

Some problems:

• you cannot easily update an Entity . You'll most probably need to do some classloader magic
• you cannot extend the Entity interface to add new business bethod, so you are bound to the contract you initially started your application with

Answer 5

Too long explanation for too simple problem. By other words you just want to perform dynamic class loading.

First if you somehow know the class name you can load it using Class.forName() . This is the way to get class itself. Then you can instantiate it using Class.newInstance() . If you class has public default constructor it is enough. For more details read about reflection API.

But how to pass the name of new class to program that is already running? I'd suggest 2 ways.

1. Program may perform polling of predefined file. When you wish to deploy new class you have to register it, ie write its name into this file. Additionally this class has to be available in classpath of your application.
2. application may perform polling of (for example) special directory that contains jar files. Once it detects new jar file it may read its content (see JarInputStream ), then call instantiate new class using ClaasLoader.defineClass() , then call newInstane() etc.

Answer 6

What you're basically creating here is called an application container. Fortunately there's no need to reinvent the wheel, there are already great pieces of software out there that are designed to stay running for long periods of time executing code that can change over time. My advice would be to pick your IDE first, and that will lead you someways to what app container you should use (some are better integrated than others).

You will need a persistence layer, the JVM is reliable but eventually someone will trip over the power cord and wipe your world out. Again with JPA et al. there's no need to reinvent the wheel here either. Hibernate is probably the 'standard', but with your requirements I'd try for something a little more fancy with one of the graph based NoSQL solutions.

Answer 7

what you probably want to have a look at, is the "dynamic object model" pattern/approach. I implemented it some time ago. With it you can create/modify objecttypes at runtime that are kind of templates for objects. Here is a paper that describes the idea:

http://hillside.net/plop/plop2k/proceedings/Riehle/Riehle.pdf

There are more papers but I was not able to post them, because this is my first answer and I dont have enough reputation. But Google is your friend :-)