Critique of My Stereoscopic Animated Hypercube Source 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 versions.

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.

My Criticisms:

• 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.

--Mark Newbold