AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?

[Artem Ananiev]

On 7/9/2013 7:49 PM, Doug Zwick wrote:
> On 2013-07-09, at 8:51 AM, Artem Ananiev wrote:
>
>> On 7/8/2013 7:52 PM, Doug Zwick wrote:
>>> Andrew Thompson wrote:
>>>
>>>> But I can deploy trusted code by signing an applet or a
>>>> webstart application and it can create a Thread in another
>>>> ThreadGroup. Elsewhere in this thread people mention JNI and
>>>> RMI threads and Cocoa's main thread. This is all valid code;
>>>> there's no prohibitions against doing any of these things.
>>>
>>> It may be that the ideal thing for Java to do in this situation
>>> is to have the Thread inherit the AppContext of its creator
>>> thread, rather than that of the ThreadGroup specified in the
>>> Thread c'tor. That may not be practical. Perhaps throwing an
>>> Exception in such a circumstance would be reasonable, or even
>>> just a warning message on System.err.
>>
>> A thread doesn't have an AppContext associated with it. Threads
>> and thread groups are java.lang classes that should not be aware of
>> anything from UI world, e.g. AppContext. So I don't quite
>> understand what you mean by AppContext inheriting here.
>
> I'm not sure how the objects are actually related, but it certainly
> appears from experimentation (in terms of what EDT invokeLater sends
> things to) that a given Thread is associated (directly or indirectly)
> with a particular AppContext, and that that association is fixed for
> the life of the Thread. From the discussion, it appears that when a

Yes, that's correct.

> new Thread is created it becomes associated with the AppContext of
> the ThreadGroup it is assigned to, regardless of the AppContext that
> was associated with the creating Thread. I was thinking it might make
> more sense for the new Thread to be associated with the AppContext of
> the creating Thread, regardless of the AppContext of the ThreadGroup
> it is placed in. Either that, or forbid such "cross-AppContext"

Note that all the AppContexts are created from the same code in Java 
Plugin or Java Web Start... So yes, what you propose indeed can be 
implemented, but it would be an incompatible change.

AppContext association is the same as thread <-> thread group 
relationship. Right now we allow creating threads in arbitrary thread 
groups, while your proposal is to always create new threads in the 
thread group of the calling thread.

> Thread creation operations by throwing an exception. If AppContext is
> involved at all in security functions, then permitting code to create
> a Thread associated with some other AppContext would be a violation
> of the security model, and a potential exploitation path. Even if it
> is just UI, it is still incorrect for one app/applet to interact with
> another app/applet's UI, and should be either impossible or
> forbidden. Just telling developers "don't do that", although
> necessary, is not sufficient. The JRE needs to enforce it, or at the
> very least let developers know they've done something wrong (e.g. a
> console message).

You're absolutely right, applets should not interact with each other 
(unless they share the same codebase), and the latest fixes in 
AppContext management were exactly to enforce that.

>>> The work-around I came up with was to create my own Thread, in
>>> the right context, that services a queue of Runnables. Then code
>>> running on the AppKit Thread, an RMI Thread, etc. can queue a
>>> Runnable to be run on that Thread (similar to
>>> SwingUtilities.invokeLater). It gets cumbersome to defer things
>>> to the Swing thread from such a "bad" context, as you need to
>>> queue a Runnable to the work-around Thread that then queues yet
>>> another Runnable for the Swing Thread. But it does work. I do not
>>> know if invoke-and-wait semantics would be reasonable, as
>>> blocking the AppKit Thread can lead to trouble (i.e. deadlocks),
>>> but may be OK in the RMI case.

If your code is allowed to deal with multiple event dispatch threads 
from different AppContext, you can then use SunToolkit's methods to find 
the right EDT/AppContext for a given component. This is not something I 
would propose as a generic solution, it's code from sun.* after all, but 
as a temporary workaround, it may work.

>> As I wrote in my previous email, RMI should be fixed in JDK, not
>> workarounded by application developers.
>
> Absolutely. However, for those of us with applications in the field
> today that are crashing, hanging or otherwise misbehaving, we need to
> get a fix out to our customers now, and not wait for the next JRE
> release. A work-around is still needed to cover the
> immediate-to-short term. Rolling back to a previous version of Java
> is not an option for some of our customers.

This is understood...

Thanks,

Artem

> This email and any attachments may contain confidential and
> proprietary information of Blackboard that is for the sole use of the
> intended recipient. If you are not the intended recipient,
> disclosure, copying, re-distribution or other use of any of this
> information is strictly prohibited. Please immediately notify the
> sender and delete this transmission if you received this email in
> error.
>