AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
Leonid Romanov
leonid.romanov at oracle.com
Wed Jul 3 15:03:07 PDT 2013
On Jul 3, 2013, at 8:21 PM, Doug Zwick <Doug.Zwick at blackboard.com> wrote:
> Artem Ananiev wrote:
>
>
>> 2. In applet/webstart modes, there may be multiple AppContexts in the
>> JVM. All the application code is supposed to run in a single AppContext,
>> including all the helper threads running native code. If you create a
>> new thread group, it will inherit the current AppContext. If you create
>> a new thread group using another (not current) thread group as a
>> parent... Well, you should not do that, and, actually, untrusted code is
>> not allowed to do that.
>
> Unfortunately this can happen by accident. If a native method running on the AppKit thread (or Toolkit thread) calls back into Java, and that Java method creates a Thread (or if the native code uses JNI to create a new Thread) without specifying the ThreadGroup, it will inherit the ThreadGroup of the AppKit (Toolkit) thread, which will be in some other context. We actually ran into this with a third-party library we are using. It created a Executor thread pool in the "main" ThreadGroup, presumably in a WebKit callback on the AppKit thread. That pool was used for sending callbacks from the 3rd party library into our code, which attempted to update our Swing UI. Or app would reliably deadlock within a few seconds of the WebKit component being shown.
>
This issue is not limited to the OS X/JNI case. According to the FAQ Doug posted in the previous email (http://lopica.sourceforge.net/faq.html#two-event-queues), RMI callbacks get called within "wrong" thread group. By "wrong" I mean that you can't do UI stuff in RMI callbacks. Basically, it looks like it's the same situation as with OS X/JNI.
Leonid.
More information about the macosx-port-dev
mailing list