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

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?

@MДΓΓБДLL That's what I was thinking, but I wanted to see if there was an actual reason. — Jeffrey, Jan 19 '12 at 21:10

kleopatra · Answer 1 · 2012-01-20T13:02:05.867

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.

trashgod · Accepted Answer · 2018-01-25T23:13:30.507

5

Is there a good reason that they limited the progress to [0,100]?

To the extent that this question has a constructive answer, the notion of what constitutes progress is probably best known to whatever is being modeled in the background thread. Scaling limits the amount of detail that must be exposed.

At the same time, SwingWorker is intended to be sub-classed. Nothing precludes adding a setProgress(int progress, in min, int max) method and the attendant property change support, but it's hard to see any advantage—the recipient would just have to scale it for display.

edited Jan 25 '18 at 23:13

answered Jan 20 '12 at 01:28

trashgod

203,806
29
246
1,045

aaaach, time to sleep +1 – mKorbel Jan 20 '12 at 01:42
3

setProgress is _not_ a method intended for overrides (trivially, as it's final :-) nor is bypassing the contract of the property "progress" – kleopatra Jan 20 '12 at 12:00

score 2 · Answer 3 · answered Jan 19 '12 at 21:54

2

1) SwingWorker#setProgress ---> I take that as percentual amount, basically is there range betweens 0 and 100, agreed that algebra knows negative % or 1M at %, but same way you can calculating fourth/fifth dimension, little bit hardier could be with Drake equation, but possible

2) JProgressBar ---> hasn't this limitations/restiction, because you can wrote nice code, where is possible to switch (JComboBox) betweens value in %, Mb, remain .... for progress

answered Jan 19 '12 at 21:54

mKorbel

109,525
20
134
319

Yes, the worker should scale the result before calling `setProgress()`, as shown [here](http://stackoverflow.com/a/4637725/230513). – trashgod Jan 19 '12 at 23:33
Is there a good reason that they limited the progress to [0,100] or was it just a (bad) design choice? – Jeffrey Jan 20 '12 at 00:32
no isn't real reason for limitation, maybe someone who built this API can answering your question, but API says implemented BoundProperty http://java.sun.com/developer/onlineTraining/Beans/Beans4/bound.html for PropertyChangeListener http://docs.oracle.com/javase/tutorial/uiswing/events/propertychangelistener.html, however this implementations for Future in Swing have got long history full of showstopers, fixed in Java1.6_019 or 20 – mKorbel Jan 20 '12 at 01:03
@Jeffrey: more [here](http://stackoverflow.com/a/8935726/230513). – trashgod Jan 20 '12 at 01:29

score 2 · Answer 4 · edited May 23 '17 at 12:21

2

It depends on your use-case, but you can also use the publish method to publish progress and update a progress bar in the publish method. See my answer on another SO question for an example

edited May 23 '17 at 12:21

Community

1
1

answered Jan 19 '12 at 22:48

Robin

36,233
5
47
99

I thought about using this, but it won't work for my use case. I'm using a `SwingWorker` to get information for a `JTable` based on which row indices are selected on that table. For every index selected, the `SwingWorker` gets the necessary information for that row (`1` to `x` pieces of information) and uses `publish` and `process` to update the `JTable`'s model once an entire row of information is available. However, I want the `JProgressBar` to update once a single piece of information is available (instead of once an entire row is available). – Jeffrey Jan 19 '12 at 22:55

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

4 Answers4