API Review: BufferedImage import/export utilities

[Jim Graham]

Hi Matthieu,

I'm not sure I understand your concern.  Why would the caller need to 
worry about whether the return value is different or not?  Typically 
this is used with a form of:

	obj = getSomeData(obj);

where the returned reference replaced the original anyway so they 
wouldn't even have a way to test if the return value was different.  In 
a way, yes, they are "just using the return object".  If the method can 
reuse the space, it does.  If it can't, where is the harm?

			...jim

On 5/21/2012 12:13 AM, Matthieu BROUILLARD wrote:
> Hello,
>
> Are you sure that we need in this class the optional parameters in both
> methods? As a end user of the API even if you expect the methods to write
> to the provided objects, you will have to check the return parameter to be
> sure that your provided object has been correctly filled.
> Won't it be easier to just use the return object? Won't it make the API
> simpler and the client code more readable?
>
> Or if it is important that an already prepared image object is used to copy
> the image into what about splitting in 4 methods and make this usage
> explicit:
>     public static WritableImage toFXImage(BufferedImage bimg);   // creates
> a WritableImage
>     public static void toFXImage(WritableImage wimg) throws Exception;   //
> reuse the provided image or fail with expection
>     public static BufferedImage fromFXImage(Image img);    // creates a
> BufferedImage
>     public static void fromFXImage(BufferedImage bimg) throws Exception;    //
> reuse the provided image or fail with expection
>
> Matthieu