Critique of My Stereoscopic Animated Hypercube Source Code
The Stereoscopic Animated Hypercube was my first Java applet.
Its source code is the only Java source code that I have published.
This document lists the things I think are wrong with the code.
I make no apologies that it hasn't been upgraded from Java 1.0. It works fine in all
Java versions, and I don't want to "break" it for people who are using old
In Java 1.0, there were no "jar" files so each class file
had to be a separate request from the web server. This was a strong motivation to minimize
the number of distinct Java classes, at the expense of modularity. The Hypercube applet
has only 3 classes. Actually in Java 1.1, it could have been done with only 2 classes because the
Java 1.1 event-listener mechanism would have made it unnecessary to subclass the Frame.
The reason that I didn't use a ScrollBar for the "Projection" and "Speed" controls is that
scrollbars didn't work right.
That's all I can think of at the moment.
- It's not "thread aware". There's nothing to keep the animation thread from
changing the transformation matrices at the same time that the event thread is
using them in the paint() function. All I can say is that the effect is (by pure luck)
not very noticeable.
- It calls stop() on the animation thread. The JDK documentation says the stop() function is
now considered dangerous.
Instead, you're supposed to arrange for the thread to exit its run() function.
- It calls Thread.sleep(). I have read that sleep() is incorrectly implemented in the
major browsers and using it can cause the applet to be unresponsive to UI events.
I can easily believe this because
I have had complaints from people that the applet is sluggish
in responding to button clicks, particularly in Windows 95 (though it seemed fine on
my 200Mhz Pentium). Anyway, an alternative would be to use the wait() function.
Call some object's wait(msec) function inside a block of code that is synchronized on that
object. Disclaimer: I haven't actually done a performance comparison of the wait vs the sleep.
Maybe this is all just a Java urban legend.
- The code that sets the GridBagConstraints is not good. The constraints object is
re-used without resetting all its properties each time. This makes it hard to
read and error-prone because you have to look back through the code to determine exactly
what is being set. It would have been better to have a function to set all the properties of a
GridBagConstraints on a single function call. Each time a component is added, that function
would be called to prepare its constraints. Later Java versions have a GridBagConstraints
constructor that sets all its properties at once.
- The timing in the animation thread could be made more precise. As it is, the calculation
time gets added to the sleep time. It would be better to time the calculation and deduct
its time from the sleep time.
Looking back over the code, my overall impression is that it looks kind of primitive.
Things aren't done quite the way I would do them now. When I wrote this I didn't
have much of a concept of object-oriented programming, and I didn't understand
threads very well. I'm slightly embarassed to put this out there as the only example
of my source code. However my experience with publishing source code has been
rather negative. I know of instances where other people have taken this code and called it their own.
<Dogfeathers Home Page>
<Mark's Home Page>
<Mark's Java Stuff>
<The Source Code>
This page URL: