I don't have a lot to say, but this is my little bit.
Wednesday, September 16, 2009
I wrote a little application to show off why EnhancedThread is useful. This app has a button which, when clicked, creates a thread which does a trivial task a lot of times. The thread is monitored by a listener, which updates a progress bar, which is visible in a scroll pane in the window. When the thread completes its task, the system beeps and the progress bar is removed from the window.
Download the application here
Download the XCode project (source code) here
This application is also a visual way to demonstrate that threads do not always execute their tasks with the same speed. Even though all the threads in EnhancedThreadExample are performing exactly the same task, you can see in the picture that some threads perform faster than the thread before or after.
To run this application, download it and double click on the EnhancedThreadExample.jar file, or from the command line issue 'java EnhancedThreadExample.jar'.
In years past this application would have been a test case for a memory leak in Apple's implementation of the Swing classes. They must have fixed the bug, but previously the JProgressBar's UI class would fail to clean up its pointer to the native progress-bar UI, the one that makes the pleasant animated flowing blue bar. The result was that every new progress bar displayed leaked a little memory -- a substantial amount, actually. Over time, an application which used progress bars would slow down then run out of memory. I used a memory mapping tool to watch as this application executes, and there was no noticeable memory leak, even after using hundreds of progress bars. I bet it was no more than one line of missing code on Apple's part.