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.r...@oracle.com
<mailto:philip.r...@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
>
>
