4.3. Subversive Behaviour

The author recommends that the user run this stuff as an applet, within an internet-browser, never as an application. Not even with appletviewer, which in my view, provides insufficient protection. Although I tend to write safe software, I am nonetheless soliciting contributions from others, and might incorporate those classes (Trojan-horses and all) into the distribution.

It is easy, to write a Strategy which fouls up the game. One can code an infinite loop, or allocate memory until the JVM collapses.

Prolonged execution (whether accidental or deliberate) can be dealt with effectively. (Although it isn't, now.) Let the Strategy run in its own thread, and stop or destroy the thread if it runs too long. The conductor will provide a default choice, if one is needed. Alas, that could wreck the internal state of the Strategy.

Out-of-memory problems are more difficult to handle. (At present they are treated like any other exception thrown by a Strategy.) The condition isn't necessarily caused by the Strategy which throws the first OutOfMemoryError: some other Strategy may have brought the JVM to the edge, but not over. And once the condition has occurred, it is likely to recur. Either the Applet itself will succumb, or perhaps each Strategy in turn will succumb. The game goes on, but each Strategy becomes mute, falling back on the conductor's choices.

It would be best if the contributing programmers exercise caution and discretion.

It should be possible to forge counterfeit Route and Segment objects. After all, their constructors are public. (Building the required constructor-parameters might be a challenge, though.) Once built, one can return them from Strategy.youMustSell and other methods. The StrategyWrapper class deals with this possibility.

There may be other things that the author hasn't thought of. Write if you discover one.