<AWT Dev> [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

[Sergey Bylokhov]

On 18.04.16 18:36, Alexander Scherbatiy wrote:
> On 4/15/2016 10:55 PM, Sergey Bylokhov wrote:
>> On 15.04.16 21:49, Phil Race wrote:
>>> I think that even if no exception is thrown we ought to document what
>>> happens.
>>> Which of course means that we need to be sure that it does happen :-)
>>> And the difference depending on SM may be hard to defend.
>>> And I am referring to both methods, not just the URL one.
>>
>> The spec of checkImage/prepareImage both return incorrect status in
>> case of null, seems both should throw NPE also. otherwise they report
>> null as a valid fully loaded image.
>
>     Could you give more details why do you think that
> checkImage/prepareImage methods return incorrect status in case of null
> file path/URL?
>     The checkImage just returns a status of an image construction
> "Information on the flags returned by this method can be found with the
> discussion of the ImageObserver interface." and the prepareImage()
> redirects all results to the ImageObserver.

Because the checkImage() return ALLBITS loaded for the null image which 
means that "all image data is currently available".
prepareImage() will return true for null, which means that "the image 
has already been fully prepared"and ready for rendering, note that an 
observer is not called that there are some errors. At lest this two 
methods should be investigated.

>
>    For example the call of Toolkit.getImage(file) method with path which
> does not point to a file does not lead to the FileNotFoundException. The
> ToolkitImage is created and just wait for the time when it is loaded.
> Only during loading the ImageObserver is called with ABORT info flag.

There is a difference between incorrect parameters and some loading 
errors. For example createImage(byte[] imagedata,...) throws an 
exception because there is no sense to load the image from null array, 
the same for URL/File. ImageIO uses the same scheme(throws an exception 
if it is obvious that load of the image data will fail). Passing a null 
value to this api is a bug in the program, and it will be good to report 
it early.

>
>     The case with null path or URL should follow the same ToolkitImage
> errors handling rule.


>
>    Thanks,
>    Alexandr.
>
>
>>
>>>
>>> -phil.
>>>
>>> On 04/15/2016 11:47 AM, Alexander Scherbatiy wrote:
>>>> On 15/04/16 22:11, Phil Race wrote:
>>>>> And it prints the stack trace ??
>>>>>
>>>>> This gets even messier.
>>>>>
>>>>> Is there anything we can do to have sensible specification of
>>>>> what happens with null that isn't likely to cause (much) harm ?
>>>>
>>>>  I see only two options. Do not throw the NPE as it was before and
>>>> throw the NPE.
>>>>  The second one can break some old applications which do not expect
>>>> that the exception can be thrown in this case.
>>>>
>>>>  If the second option is acceptable probably the Toolkit.getImage()
>>>> javadoc can be updated.
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 04/15/2016 11:10 AM, Alexander Scherbatiy wrote:
>>>>>> On 15/04/16 20:30, Sergey Bylokhov wrote:
>>>>>>> How the object of URLImageSource(null) will be useful? I guess we
>>>>>>> will get some unspecified NPE exceptions if will try to call its
>>>>>>> methods?
>>>>>>   I know nothing about the URLImageSource(null) usefulness but
>>>>>> ImageFetcher swallows the NPE during the image loading in the
>>>>>> fetchloop() method:
>>>>>> -------
>>>>>>             try {
>>>>>>                 src.doFetch();
>>>>>>             } catch (Exception e) {
>>>>>>                 System.err.println("Uncaught error fetching image:");
>>>>>>                 e.printStackTrace();
>>>>>>             }
>>>>>> -------
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 15.04.16 18:02, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix:
>>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8132706
>>>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8132706/webrev.00
>>>>>>>>
>>>>>>>>    The fix makes the Toolkit.getDefaultToolkit().getImage(URL)
>>>>>>>> return a
>>>>>>>> ToolkitImage based on URLImageSource with null url as it was
>>>>>>>> before the
>>>>>>>> fix JDK-8011059.
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.