|
|
Bouncing
Reactive Balls
|
|
The
Alteridem
site proposes a funny small bouncing balls applet in which two balls
are bouncing in a small area, making some noises when they collide.
Click here to see it.
One particularity of this applet is that it uses Java threads, one
for each ball (the code of the applet is available on Alteridem
site). The use of threads is certainly a good idea for modularity:
the applet naturally decomposes into two threads, each one
corresponding to one ball. However, threads have several drawbacks:
- they are not easily portable; the semantics highly depends on
the execution strategy of the underlying platform (if it is
preemptive or cooperative);
- it is difficult to get a fine control over threads (in
particular, from jdk1.2, without the three deprecated methods
Thread.stop, Thread.resume, and Thread.destroy of the class
Thread).
- threads are low-level; the programmer must very often code its
own higher-level communication or synchronisation primitives,
because the basic wait/notify mechanism is not sufficient.
According to this, it seems rather difficult to extend the
existing bouncing balls applet, for example by considering more than
two balls or by giving balls more complex behaviours. If you are not
convinced by this affirmation, just try to add a third ball to the
applet!
The Reactive
Approach provides a new solution for concurrent, event based
programming. It is implemented in Java by
SugarCubes
which is a set of Java classes for reactive programming. A key point
is that SugarCubes provides thread-free concurrent programming
in Java. To put the Reactive Technology into the bouncing balls
applet is certainly a good way to show how this approach can solve
problems raise by threads. So, let's go for coding bouncing reactive
balls !
Five Applet Examples
The first example consists in coding (more or less) the same applet,
but replacing Java threads by reactive instructions.
Here is the first reactive
applet.
The new applet is clearly speed-up compared to the initial one.
This comes from the fact that Thread.sleep calls are no more used.
They were present in the initial applet to let the threads be
scheduled in turn. Note that reducing the sleeping delays to speed-up
the applet is not a portable solution as, on some browser, the
graphical thread would not get enough time.
Analysing the code shows that the balls behaviours are now well
delimited and concentrated in two Lisp-like reactive instructions of
the class Rbounce. Reactive instructions are instances of the class
Instruction from the junior package. Actually, Junior is a
lightweight variant of SugarCubes, which is used here only for
convenience reasons; switching to SugarCubes would be very easy.
In the second example, one dynamically creates new balls.
The second applet is here.
Note that the meanings of the two buttons, happy and mad, have
changed: now, they are used to create new balls, and not to give them
a little twist, as previously. All changes from the previous version
are actually concentrated in the file RDbounce.java (R stands for
Reactive, and D stands for Dynamic).
A third example consists in changing the behaviour of the balls by
suppressing the collision checks. Now, one can add a large number of
balls without slowing-down the applet. Just one question: what would
be the limit if each ball would use its own private thread ?
Here is the third
applet.
Changes are concentrated in file RDNoCollision.java.
In the fourth example, one changes the behaviours of the balls: mad
is added a tracking behaviour and happy a go-away behaviour. Now, the
balls are fighting and mad balls can kill happy ones (but balls of
both kinds can also destroyed themselves during collisions).
The fourth applet is here.
The fifth and final example is a variant of the fourth one in which
collision checks are suppressed (mad balls thus never disappear). In
the initial situation, there are 10 happy balls and one mad one. The
bouncing balls applet has became a prey-predator one!
Here is the fifth
applet.
Conclusion
Several advantages come from using the Reactive Approach:
- Applets become fully portable as they are actually pure
sequential code.
- One gets efficient solutions: applets have not
to be slow-down by calls to Thread.sleep, in order to run on
different platforms.
- Semantics is clear and do not depend on the scheduling
strategy used.
- Programmers have full control over reactive
instructions; in particular, the Until reactive instruction
provides a preemption operator (corresponding in a sense to
Thread.stop).
- Applet behaviours are expressed using reactive instructions in
a natural and modular way.
SugarCubes and related softwares are free software distributed on
the Web. Please, feel free to use them to program your own applets!
Contacts:
Frederic.Boussinot@sophia.inria.fr,
Jean-Ferdinand.Susini@sophia.inria.fr