Why is SwingWorker#setProgress limited to [0, 100]? [closed]

Question

SwingWorker#setProgress throws an IllegalArgumentException if the argument isn't from 0 to 100. I thought the main purpose of the setProgress method was to update a JProgressBar (as it was in this tutorial). If that's the case, why limit the SwingWorker's progress to [0, 100] when JProgressBar's progress is not limited?

Answer 1

Discussing api design is quite entertaining, but prone to guessing :-)

Some random thoughts at the end of the week:

• the basic process model of a SwingWorker is to allow doing something in the background and support reporting both intermediate and end result/s back to the EDT.

• it's intented for subclassing (as @trashgod already emphasized), at the same time it tries to minimize the effort required doing so: state and progress are fully defined and implemented convenience properties, meant to be used as-is.

• being so, the api doc rules - which clearly states the valid values of the bound property process being in the range of 0 ... 100, incusively. No ambiguity, nothing allowed to be changed in custom implementations. Showing progress as a percentage is the most common use case, supporting that out off the box is a reasonable thing to do.

• for reporting intermediate results in coordinates different from percentage, the intenteded path is to implement process(..). It's up to the custom implmentation what exactly it does, could be firing a custom defined property or filling a view model directly or ... whatever

• lastly, the tutorial example is just that, an example. Plus, it's inconsistent in itself: the description mentioning a method task.getLenghtOfTask which isn't implemented in the custom swingworker. My (wild) guess is, that the example text is still based on an older version which might have supported arbitrary values.

To answer the question (my 0.02Euro cents :-) - nothing bad in the design, it's a well-balanced base implmentation which handles the common use cases out off the box and at the same time is flexible enough to make more advanced requirement simple to implement.

to update once a single piece of information is available

you can't completely control the reporting granularity: all you can do, is to define the unit of the smallest chunk and then must expect to receive one or several of those smallest coins.