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

[Doug Zwick]

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 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" 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).

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