[Added David] Sorry, I forgot to actually add David last time.
With best regards. Petr. On 02.04.2014, at 15:18, Petr Pchelko <[email protected]> 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 <[email protected]> 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. >> >
