That’s What Would You Do. I’d write WWJD in the title but I don’t want to offend…
I’ve been struggling to retrofit some pretty deeply nested Java code that was originally written implicitly as a Notes agent into the multithreaded environment of an Eclipse plugin. Specifically, I have a pretty long running thread that I’d like to be able to monitor the progress of in the UI as well as cancel interactively. Ordinarily, I’d write a Job that breaks the work up into units, emits a Status at the end of each unit and reschedules itself for more work. I would then be able to write a handler to respond to the status changed event and update the UI accordingly. It occured to me that this is not an optimal use of time as constantly completing and rescheduling an ongoing task that does some heavy lifting may take its toll on the overall speed of the task’s execution. More importantly, I’m not particularly interested in reworking the heavily object oriented and deeply nested code that performs the actual work. How would you approach the problem? (Read: chime in in the comments)
My solution was to keep a parent progress tracking object persistent in the Eclipse Activator OSGi object and create a Job Family. The family contains two jobs: the one that performs the work, updates the tracker object and listens for cancel flags in the tracker as part of its work loop and a job that monitors the tracker object every second or so (I tailor the interval in a
.properties file) and updates the progress bar in the UI when a change is detected. I also have a generic logging interface that was easily extendable to update the UI as well. When the job is done –either via completion or cancellation, i can simply cancel the job family to release the job threads’ resources. Now that I’m working in a plugin, I’ve taken care to collect all my Notes objects in a vector for eventual
dispose()-ing as per best practices for a GUI that may persist for some time.
My biggest concern is that repeatedly calling
Display.getDefault().syncExec(Runnable) each time a GUI event is fired is tedious, but I don’t see an alternative. Can anyone show me otherwise?