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

[Sergey Bylokhov]

On 30/10/2018 12:58, Phil Race wrote:
> 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 ?

If I remember this correctly then:
The plugin could run a few applets in the same vm, so we have to split these applets from each other and the plugin code itself.
The webstart could run only one application, but we have to split the applet and webstart code as well.

> 
> 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
>>>      >
>>>      >
>>>
>>
>>
> 


-- 
Best regards, Sergey.