Incremental updates from Tasks

[Richard Bair]

Hi Roman,

>> OK, here is the next issue I ran into while documenting the Task for the last issue. We don't really have a good way for the Task to do incremental updates to the Task value. Instead, it is only set at the conclusion of the call method, and only when the Task isn't cancelled. This is fairly limiting. Instead, it would be nice to allow Task subclasses to set the value whenever they like -- before execution (such as in the constructor), multiple times during execution, or even after it has been cancelled.
>> 
>> This is the issue: http://javafx-jira.kenai.com/browse/RT-18820
> 
> I was thinking about the same when you asked about how to get the state
> (thread safe) into a cancelled() callback method. An API to do partial
> updates would be helpful.
> 
> What about an API similar to how it's done in SwingWorker? There we
> define a 2nd type parameter T and publish() partial results. This would
> be called from the call() method whenever we have a partial result:
> 
> protected void publish(T chunk)
> 
> Which in turn results into a call (on the JavaFX thread) to:
> 
> protected void process(List<T> chunks...)
> 
> Which allows to process one or more chunks that have been published
> before using publish().
> 
> I like that API and it solves the question how to handle atomic vs. list
> types simply by introducing a new generic type. It also has the
> advantage that Swing refugees feel familiar with it :-)
> 
> Anything wrong with that approach?

There are two things I don't like about that approach. The first is that it introduces overhead in cases where we are only interested in the "most recent intermediate value". That "chunks" list might be 10,000 elements long, and we only care about the very last item in it.

The second thing I don't like about it is that for cases where you are computing an atomic value, it is more complicated. You have to call publish and implement process. With the proposed updateValue, you simply call updateValue from your Task implementation and the rest is just handled for you.

The Swing solution here I think is quite flexible -- and that is both its strength and weakness. Although this might very well be what I should use for the observable list case.

I guess it comes down to a trade-off. Do we have a single class that handles incremental updates to atomic & collection values (reduced number of classes, less "cluttered" namespace, worse performance for updates to atomic values that are frequently updated), or do we split this up into multiple classes (more classes, better performance, more situation-specific API)?

I do remember feeling that publish / process was awkward to use back when I was learning it, and I didn't spend enough years with it for it to become natural I guess :-)

Richard