<AWT Dev> [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded

[Petr Pchelko]

[Added David]

Sorry, I forgot to actually add David last time.

With best regards. Petr.

On 02.04.2014, at 15:18, Petr Pchelko <petr.pchelko at oracle.com> wrote:

> Hello, Dmitry.
> 
> You are changing the contract of the getSystemEventQueueImplPP method in such a way that it could mask real bugs and security issues. 
> Now we are relying on such NPEs to spot existent problems in our code, but with your fix the problems could be unnoticed, just the code 
> would be run on a wrong thread which is VERY hard to find. I understand that this looks like an only solution, but I think it's better to live with
> the JColorChooser bug than to hide AppContext problems.
> 
> I suggest closing this bug as Not an Issue, because the client code is buggy - the static initializer is called not on the EDT, so the swing 
> component in created off EDT. This violates the swing threading contract. 
> 
> I've added David DeHaven to this review as he could provide us some expertise in the deploy side of the issue.
> David, could you please clarify why the applet class is not reloaded by the VM when the applet page is restarted?
> Isn't it a bug? Shouldn't the refreshed applet be run from scratch, like a whole different application?
> 
> With best regards. Petr.
> 
> On 02.04.2014, at 10:36, dmitry markov <dmitry.markov at oracle.com> wrote:
> 
>> Hi, Sergey,
>> 
>> Please find my answer inline.
>> 
>> Thanks,
>> Dmitry
>> On 01/04/2014 15:17, Sergey Bylokhov wrote:
>>> Hi, Dmitry.
>>> This means that the wrong EDT will be used for some components.
>>> The situation is strange. We have appcontext and probably some components, which belongs to it, but there is no appropriate EDT. Why? Should we recreate it?
>> This situation is typical for the applets which have some AWT or Swing components as a static fields (see simple example in https://bugs.openjdk.java.net/browse/JDK-8036112 ). The static field is created only once when the applet's code is loaded.  All works well for the first execution. However, if the web page is refreshed, (i.e. F5 is pressed), the Java Plugin destroys the applet and starts it again. The static fields stay untouched since they should be the same for all instances of the applet's class. So the static AWT/Swing component has AppContext which points to not existed EventQueue object, since it has gone during applet's relaunch.
>> Of course we can try to re-create AppContext during applet's relaunch, but I do not think that's a good idea. In this case we have to go through all static fields and find out the components whose AppContext should be changed. But it may take a lot of time and significantly increase the applet's relaunch time, since the structure of static field may be quite complex. 
>>> And i think appContext.getAppContext() can be null too.
>>> 
>>> 
>>> On 4/1/14 3:02 PM, dmitry markov wrote:
>>>> Hello, 
>>>> 
>>>> Could you review the fix for jdk9, please? 
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8036112 
>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8036112/jdk9/webrev.00/ 
>>>> 
>>>> Problem description: the EventQueue object stored in AppContext for static fields of an applet becomes null after the refresh of the web page. This may cause a NPE in swing/awt code. 
>>>> 
>>>> Fix: The method SunToolkit.getSystEmeventQueueImplPP(AppContext appContext) should be modified. If the EventQueue from the passed AppContext is null, the method will retrieve the EventQueue from the default AppContext. 
>>>> 
>>>> Thanks, 
>>>> Dmitry 
>>>> 
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey. 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140402/fb859bc3/attachment.html>