AppContext issue in Apple Java 6 -- same issue in Oracle Java 7? (original) (raw)

Artem Ananiev artem.ananiev at oracle.com
Fri Jul 12 08:36:15 PDT 2013

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.

More information about the macosx-port-dev mailing list