[Review request] Image loader API

[Lubomir Nerad]

Hi All,

I would like to revive discussion about image loading error handling. It 
was originally posted to this mailing list under the "Image loading 
error reporting / handling" heading.

The discussion included the following emails:

* 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002617.html 
- Lubomir Nerad
     * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002618.html 
- steve.x.northover at oracle.com
     * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002619.html 
- David Hill
     * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002622.html 
- Martin Desruisseaux
         * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002623.html 
- John Smith
             * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002642.html 
- Lubomir Nerad
                 * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-July/002668.html 
- Richard Bair
                     * 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-July/002718.html 
- Lubomir Nerad

My proposal was to handle image loading errors through a separate 
ImageLoader class as described in 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002617.html. I 
got positive feedback from Steve, David and Martin. Objections were 
raised by John and Richard. They wanted to handle Image loading errors 
through Image.getLoadWorker which would return javafx.concurrent.Worker 
instance. In the last email I wrote that the Worker solution is not 
sufficient and has its own problems in this case.

To move the discussion forward I'll try to summarize my arguments 
against the Image.getLoadWorker solution:

* Doesn't address the request to directly throw exceptions for 
synchronously loaded images 
(http://javafx-jira.kenai.com/browse/RT-17645). This is addressed by the 
proposed ImageLoader.load methods.

* Makes it harder to define uniform error handling for multiple 
background loaded images (requires separate property change listener 
registration for each loaded image). ImageLoader allows to register a 
single onLoadingFailed handler for all its loaded images.

* Adds duplicate information/functionality to the Image class:

Image.progress vs Image.loadWorker.progress
Image.cancel vs Image.loadWorker.cancel
Image.error vs Image.loadWorker.state

* Adds unwanted overhead to images which are constructed directly from 
application provided pixel data.

* I don't think it is easier to use from FXML. Maybe if the information 
provided by the Worker interface needs to be displayed, but definitely 
not if some additional code needs to be executed in response to failed 
image loading. As to ImageLoader, I already mentioned the possibilities 
to add additional Image constructors with ImageLoader parameter or to 
add an imageLoader field to the FXMLLoader class. Even if we don't do 
that, I found out that FXML uses its own internal builder for Image 
instances. It will be easy to add support for an optional imageLoader 
field to this builder.

Thanks,
Lubo