[OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7

[Jim Graham]

Their complaint is that the resulting image is empty - most likely 
because the error gets passed through and clears the image buffer.  It 
appears that the sequence of events is:

We send SINGLEFRAMEDONE.
- the image is displayable
We send STATICIMAGEDONE.
- filter throws NPE
- image is probably still displayable
We send ERROR
- if it gets passed through to the toolkit image consumer then we'll 
clear the image buffer
- image is no longer displayable

It's hard to say for sure without having an instance of their filter 
in-house for testing, but previously we weren't sending the STATICDONE 
notice and the program was working just fine.  Since the NPE comes from 
their code when we send it, it shouldn't have affected any down-stream 
consumers, so we should be OK with just continuing on and the image 
should still be displayable just as if we hadn't sent the STATICDONE 
notice in the first place.

Now, *during debugging*, they were thwarted by the fact that we ate the 
exception, true, but the original issue is that the image wasn't 
displayable at all.  We might want to do both:

- not send ERROR for STATICDONE when we used to not send STATICDONE at all
- show the exception so that someone realizes that there is a problem, 
even though we've made it not hurt their functionality.

Does that make sense?

			...jim

On 5/25/2016 1:36 PM, Sergey Bylokhov wrote:
> On 25.05.16 23:33, Jim Graham wrote:
>> How about option 3 -
>>
>> NPE before imageComplete sends an ERROR as it does now.
>>
>> NPE during imageComplete is ignored, both for backwards compatibility
>> and because it is more of a "hint" than an operation that requires
>> action from the consumer.
>
> I guess the case is that when we ignore this NPE(w/o any notification)
> the users complains that the bug is in jdk.
>
>>
>>             ...jim
>>
>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote:
>>> Hi
>>>
>>>
>>>
>>> Bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8139192
>>>
>>> Custom ImageFilters return blank images in Java 8(.45) while working
>>> in 7
>>>
>>>
>>>
>>>
>>>
>>> Root cause :
>>>
>>> private method produce() in OffScreenImageSource.java consumes a
>>> NullPointerException that originates from a custom ImageConsumer (a 3^rd
>>> party image library class - com.jhlabs.image.WaterFilter)
>>>
>>>
>>>
>>>
>>>
>>> Analysis:
>>>
>>> 1. How the behavior changed between JDK7 and JK8 :
>>>
>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was added in
>>> addition to imageComplete(ImageConsumer. STATICIMAGEDONE)  as a fix for
>>> JDK-7143612.
>>>
>>>
>>>
>>> 2. What debugging revealed:
>>>
>>> A NullPointerException is being thrown from the library during the call
>>> to imageComplete(ImageConsumer.STATICIMAGEDONE)
>>>
>>>
>>>
>>> 3. It looks like the fix of JDK-7143612 is valid and successive calls to
>>> imageComplete() are allowed.
>>>
>>>
>>>
>>> 4. The 3rd party library behavior appears incorrect (if it can not
>>> handle subsequent calls to imageComplete(), it should de-register
>>> itself).
>>>
>>> The 3rd-party library code should be fixed.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Possible modifications in JDK  :
>>>
>>>
>>>
>>> Currently, OffScreenImageSource::produce() consumes the
>>> NullPointerException - this is incorrect and results in silent failure
>>> of this particular image filter.
>>>
>>> We need to let the image filter library know that exception has occurred
>>> in its code and not in JDK. We have two options -
>>>
>>>
>>>
>>> Option 1 : Rethrow the NullPointerException   --- It is the clearest way
>>> to let 3^rd party library know that their code is erroneous with latest
>>> JDK. This will change the 3^rd party image filter behavior that
>>> generates blank image.
>>>
>>> Option 2 : Add a stack trace where the exception is being consumed ---
>>> Adding stack trace provides more information regarding failure of 3^rd
>>> party image filter with retaining the current behavior that generates
>>> blank image.
>>>
>>>
>>>
>>> I have implemented both the options:
>>>
>>> Option 1: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/
>>>
>>> Option 2:  http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/
>>>
>>>
>>>
>>> Request you to review both the webrevs and provide your preference.
>>>
>>> I will add a test to the selected webrev.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ajit
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>