<AWT Dev> [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Oct 30 19:47:13 UTC 2018

Hi, Laurent.

I think you overestimate the role of appcontext. It was created as way to make a sandbox for the untrusted applets. So such applets were not able to access internals of the webstart itself, for example the application/applet should not had an access(via Frames.getFrames()) to the security dialogs, otherwise the applet could close it. Because of that the usage of "static" data was forbidden in the client libs, and all data had to be stored pre-appcontext basis.
Based on the previous experience it was proved that it is hard to implement such sandboxing only by the client libraries. In some version of deployment the usage of untrusted apps were dropped, and the only signed/trusted applications could be run on it. At this point the multy-appcontexts became useless.

So if IcedTeaWeb will be positioned as a simple deployment framework for the know application(not for some random apps from the internet), then you can use the MainAppcontext(same as in the standalone application). I hope that we will be able to drop the appcontextes completely at some point because it will simplify our code a lot.

On 30/10/2018 11:47, Laurent Bourgès wrote:
> Hi Phil,
> Oracle deprecated Java Web Start but I am now involved in IcedTeaWeb to maintain JNLP support for our science tools at http://www.jmmc.fr !
> I DO need AppContexts, and anything useful to maintain IcedTeaWeb alive ...
> Cheers,
> Laurent
> Le mar. 30 oct. 2018 à 18:20, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> a écrit :
>     Looks good to me.
>     I'll take this opportunity to ask a question to people on this list.
>     Now that we've removed plugin+webstart, do we still need AppContext at all ?
>     Can the entire mechanism be removed from all sources ?
>     Or is there still some useful reason for keeping it ?
>     Even though it is internal, external apps could be using it *indirectly*
>     by using
>     separate ThreadGroups / class loaders but what would be their purpose in
>     this ?
>     -phil.
>     On 10/24/18 2:31 PM, Sergey Bylokhov wrote:
>      > Hello.
>      > Please review the fix for jdk 12.
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8211435
>      > Webrev: http://cr.openjdk.java.net/~serb/8211435/webrev.00
>      >
>      > Bug description:
>      >
>      >   In the DefaultKeyboardFocusManager class we have a special field
>      > "activeWindow", which stores the currently active window. It is used
>      > in two similar cases:
>      >  1. If the java window gets "WINDOW_ACTIVATED" event it will try to
>      > send "WINDOW_DEACTIVATED" to the old active window, which is stored in
>      > the "activeWindow" field.
>      >  2. If the java component lost the focus, and the opposite component
>      > is not a java component, then it will try to send "WINDOW_DEACTIVATED"
>      > to the old active window, which is stored in the "activeWindow" field.
>      >
>      > The difference in these two cases is that in "case 1" we check the old
>      > active window to null[1], and the second case has no such check. The
>      > bug is reproduced in non-standalone mode, when we have a few
>      > Appcontexts and this field might be updated by different EDT in parallel.
>      >
>      > Note that the test is for OSX only, because of another bug:
>      > JDK-8204142[2]
>      >
>      >
>      > [1]
>      > http://hg.openjdk.java.net/jdk/jdk/file/ad9077f044be/src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java#l527
>      > [2] https://bugs.openjdk.java.net/browse/JDK-8204142
>      >
>      >

Best regards, Sergey.

More information about the awt-dev mailing list