[rfc][icedtea-web] awt threads cant stop with console enabled

[Andrew Azores]

On 11/07/2013 04:33 AM, Jiri Vanek wrote:
> After console ressurection, the console window was never disposed, so 
> jvm never terminated without system. exit(). This patch is handling it.
> Backport to  1.4 should not be necessary as in 1.4 console is shown 
> only for plugin, and plugin.terminate is killing jvm quite 
> successfully. However backport is possible if reviewer thinks 
> differently.
>
> 2013-11-07  Jiri Vanek  <jvanek at redhat.com>
>
>     Fixed deadlock in awt threads. JavaConsole window is no disposed 
> instead of hidden.
>     * netx/net/sourceforge/jnlp/util/logging/JavaConsole.java: 
> (lastSize) new
>     global variable to remember last size of window.(contentPanel) 
> moved from
>     local to global scope. (initializeWindow) extracted from 
> (initialize), is
>     handling creation and filling of window. (showConsole) is now 
> initializing
>     window, and (hideConsole) is disposing it.
>     * netx/net/sourceforge/jnlp/util/logging/OutputController.java: 
> messageQueConsumer
>     thread is now named, and its wait, have timeout.

Since contentPanel is now global, perhaps you don't need to pass it as a 
parameter? I can't see why initializeWindow would need to be passed any 
other JPanel instance other than that one.

Also, I know this isn't part of this patch, but maybe the parameter for 
showConsole could be given a more informative name, eg "modal" - "b" is 
really not informative at all unless you go look at the source.

I don't know if this "hanging VM" problem is quite a "deadlock" per se, 
so maybe word that comment a little differently as well, just so in the 
future someone maintaining this code doesn't think there was actually 
some issue with competing threads involved with this code. Unless I'm 
just missing the point and this really is resolving competition for 
resources :)

Otherwise, I think this looks okay.

Thanks,

-- 
Andrew A