progress monitoring : Java Glossary


progress monitoring
If you are doing something that will take a while it is polite to let the user know how you are getting along. One way to do this in with progress status messages indicating the stage of work you have reached and another is progress bars, thermometers that indicates percent completed. The tricky problem with progress notification is if you are using the default thread, nothing ever gets painted because the repaint events will only be handled by the default thread only after you finish the lengthy computation or task you are progress monitoring.
Tools Learning More
Purpose of Progress Bars Links
Console Apps


How do you solve this problem? You can use a second thread and send progress notes to the Swing thread via SwingUtilities.invokeLater or EventQueue. invokeLater. This has the advantage of leaving the GUI (Graphic User Interface) fully functional while you perform your lengthy computation.

Another simpler technique is to use the javax.swing.JComponent.paintImmediately method which will immediately repaint the component and its children using the current thread. You could use it to implement a progress bar or a progress status label. There are two versions of paintImmediately: one takes four integers (x, y, width, height) and the other takes a Rectangle instance. You can easily get the Rectangle by calling getBounds on the component and passing that into the paintImmediately method. This technique has the disadvantage of freezing the GUI, except for the progress indicators, during the time you are performing your lengthy computation.

There are two built-in progress classes JProgressBar, and ProgressMonitor. JProgressBar is an always-visible thermometer-like component. It has an indeterminate mode that does not display percent complete, just an animation that hints work is happening in the background. ProgressMonitor only pops up if this particular operation will take substantial time. Since they are both Swing components, they are not thread safe. You must update them from the Swing thread via SwingUtilities.invokeLater or EventQueue. invokeLater. You must do your actual work on some other thread than the Swing thread, or the progress bars will never be updated. You can dynamically change the min and max on the fly as well at the value that represents much has been accomplished. progressBar.setIndeterminate( true ) lets you put up a temporary busy display when you temporarily have no idea how far through the work you are.

ProgressMonitorInputStream is specially designed to monitor the reading of some InputStream. This is not all that useful since InputStreams don’t divulge the total number of bytes to be read to the underlying ProgressMonitor.

To communicate between your background Thread and the Swing GUI, you use PropertyChangeEvents. You generate them with SwingWorker. setProgress. You field them with a PropertyChangeListener on your GUI that does a ProgressBar. setValue. When you use SwingWorker.setProgress, you must scale your progress to percent complete 0.. 100.

If you use SwingWorker.cancel ( false ) your SwingWorker. done() method will run even before the background thread has noticed that SwingWorker.isCancelled () is true and has terminated. The background thread keeps running for a while even after the done dialog.

Purpose of Progress Bars

A progress bar, in theory, has four functions:
  1. Let the user know how long until he will be needed again to do some interaction. The user wants to know, Is this a good time to go for coffee? A bathroom break? a lunch break? go home and come back tomorrow? The user is far more interested in the total time until he is next needed, rather than progress on all the individual steps to get there. He mostly want the ETA so he can plan his own work.
  2. Let the user know that the system is alive and well and busy. It is not really crashed. It should not lie. Don’t cheat like the Microsoft programmer who made the flying papers copy animation keep running at full tilt even when the copy itself had stalled or failed.
  3. Distract the user from noticing how slow the software is with a busy-looking or entertaining display. Of course, the overhead of this actually makes the work take longer. The Telus writhing fern amuses only for a short while. Norton’s defrag display is endlessly hypnotic.
  4. Least important is literal progress monitoring, what percent through a given task is it? This mainly lets the user notice if the program is running much more slowly or quickly than unusual, which may indicate a problem.
  5. Consider using a small state icon that changes depending on what the application is doing, e.g. reading, writing, calculating, waiting… It should change often enough to let the user know the app is alive and kicking. The user gets to know the expected patterns of change.

Sample Code

Here is a filter To come: sample code showing how to hook up a JProgressBar. For now see how I do it in The Replicator.

Console Apps

With console apps you are more limited in what you can pull off in terms of progress monitoring and heartbeat proof the app is still alive.. The key is the use of the \r character to back up and write over the same line you just printed. Here is a class to let you do that:

Learning More

Oracle’s Javadoc on JProgressBar class : available:
Oracle’s Javadoc on ProgressMonitor class : available:
Oracle’s Javadoc on ProgressMonitorInputStream class : available:
Oracle’s Javadoc on SwingWorker class : available:

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number