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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
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.
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Markov
Hi Sergey,

The fix looks good to me.
I think you can make the test generic once JDK-8204142 is fixed.

Thanks,
Dmitry

> On 24 Oct 2018, at 22:31, Sergey Bylokhov <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Laurent Bourgès
In reply to this post by Sergey Bylokhov
Hi Sergey,

(I am not a Reviewer).

Thanks for both the bug report and the fix, it looks good for me.

Laurent

Le mer. 24 oct. 2018 à 23:32, Sergey Bylokhov <[hidden email]> a écrit :
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

Laurent
Reply | Threaded
Open this post in threaded view
|

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

Krishna Addepalli
Looks good to me.

On 25-Oct-2018, at 5:41 PM, Laurent Bourgès <[hidden email]> wrote:

Hi Sergey,

(I am not a Reviewer).

Thanks for both the bug report and the fix, it looks good for me.

Laurent

Le mer. 24 oct. 2018 à 23:32, Sergey Bylokhov <[hidden email]> a écrit :
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

Laurent 

Reply | Threaded
Open this post in threaded view
|

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

Denis Fokin
Hi Sergey,

the fix conceals other scenarios. Now if another fix breaks the activeWindow field logic it can be unnoticed. Do not you think it is worth to distinguish the field update on  per-AppContext basis instead?

Thank you,
   Denis


On Fri, Oct 26, 2018 at 3:33 AM Krishna Addepalli <[hidden email]> wrote:
Looks good to me.


On 25-Oct-2018, at 5:41 PM, Laurent Bourgès <[hidden email]> wrote:

Hi Sergey,

(I am not a Reviewer).

Thanks for both the bug report and the fix, it looks good for me.

Laurent

Le mer. 24 oct. 2018 à 23:32, Sergey Bylokhov <[hidden email]> a écrit :
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

Laurent 

Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
Hi, Denis.
Thank you for review, see my comments inline.

> the fix conceals other scenarios. Now if another fix breaks the activeWindow field logic it can be unnoticed. Do not you think it is worth to distinguish the field update on  per-AppContext basis instead?
The activeWindow field logic is a global thing, only one window can be active even if we have multiple appcontexts. We have two accessors to this field:
  - KeyboardFocusManager.getActiveWindow(): which returns the active window if it has the same context as a caller.
  - KeyboardFocusManager.getGlobalActiveWindow(): which returns the active window as is.

In the current fix, the "getGlobalActiveWindow" is used intentionally. If one window in one appcontext:
  - became an active, or
  - lose the focus to nowhere,
then it should try to send WINDOW_DEACTIVATED to the previous active window, even if the previous window is located in another appcontext.

Note that WINDOW_DEACTIVATED does not mean that current active window will change, because in the moment this event will be posted/dispatched the current active window might be changed by another EDT, for this case we have a check [1], we will reset the field only if the active window was not changed.

[1] http://hg.openjdk.java.net/jdk/jdk/file/ad9077f044be/src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java#l736


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

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

Phil Race
In reply to this post by Sergey Bylokhov
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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Laurent Bourgès
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
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 <[hidden email] <mailto:[hidden email]>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: <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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>      >
>>      >
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <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 <[hidden email] <mailto:[hidden email]>> 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.