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

[Artem Ananiev]

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 understand it is intended that this AppContext idea is
>> transparent and ideally it would be. But at the present time it
>> appears that the abstraction leaks [1] and there is no workarounds
>> possible using supported code (rather than sun.* classes). Have I
>> misunderstood something in this thread?
>
> 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. A general rule is that all the 
AppContext machinery should be completely transparent to applications. 
The only exception can be a library that extends AWT/Swing functionality 
and should be ready to run on the AppKit thread and work with multiple 
AppContext. In this case the library will be able to access sun.* APIs, 
including SunToolkit and AppContext. Java Plugin and Java Web Start can 
be considered good examples of such libraries.

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