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

[Doug Zwick]

On 2013-07-12, at 9:36 AM, Artem Ananiev wrote:

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

I was thinking (wishfully, perhaps) that the association of the Thread with an arbitrary ThreadGroup could be maintained, but that the Thread would be associated with the AppContext of the creating Thread. If the AppContext association is tied to the ThreadGroup, then that won't work. I guess my thought was that the association between AppContext and ThreadGroup was only a correlation, and not an actual reference.

On the other hand, it is good to know that the relationship between AppContext and ThreadGroup is that tightly bound. It gives me greater confidence that the work-around in our code will solve the problem in all cases.

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

It looks like there is a loophole in the implementation, where creating a Thread with a particular ThreadGroup can still allow such interaction to occur. It would be good to plug that hole. Throwing an exception when this occurs would not change the API, and SecurityException is already documented as potentially being thrown by the applicable Thread constructors. If the JRE can't make it "just work" (i.e. associate the thread with the correct AppContext and the specified ThreadGroup), then it should fail hard and fast. There may be other, possibly better, ways of dealing with this. This is just what came to mind as one way to solve the problem.

>>>> 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 a temporary work-around to handle the cases where multiple contexts and EDTs intrude on app code due to either JRE or 3rd party library bugs, I think it is probably better to run through a Thread in my own ThreadGroup. It works reliably, even if it adds additional latency. The SunToolkit API is not publicly documented, and there could be hidden gotchas lurking there. In hacks like this, "Keep It Simple" is good advice. A simple hack is also faster to test and deploy when you have paying customers dead in the water.

I do still have some concern about the case of JNI callbacks on the toolkit (AppKit) thread. Either JNI needs to handle the AppContext internally, or some public API needs to be made available to JNI developers. I would prefer the former, but would take the latter if the former couldn't be done in a timely manner. A native-side API would be adequate, and not be visible from Java.

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.