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

[Phil Race]

I don't think AppContexts ever mattered for webstart.
Whilst webstart apps may run sandboxed with limited permissions,
they were never run in the same VM like applets were.
Each JNLP application has its own JRE, doesn't it ?

So I was imagining that somehow a "sophisticated" application was trying to
do some partitioning in the same JRE for reasons that maybe aren't even 
to do with
running untrusted code. They could have leveraged AppContext indirectly, but
since it is not an advertised behaviour they'd have to know there were 
taking a chance in using it.

-phil.

On 10/30/18 12:47 PM, Sergey Bylokhov wrote:
> 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
>>      >
>>      >
>>
>
>