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

[Artem Ananiev]

On 7/13/2013 6:18 PM, Andrew Thompson wrote:
>
> On Jul 9, 2013, at 10:43 AM, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>
>>
>> On 7/7/2013 8:50 PM, 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.
>>
>> Even if an applet is signed and has all permissions, I don't think it should create new threads in, say, Java Plugin thread group, right? Note that AppContext is a little bit more complex than a plain Map <-> ThreadGroup mapping. A single AppContext can occupy multiple thread groups, so if you create a thread in a nested thread group, you will be fine.
>>
>> RMI and other issues mentioned in this thread should be fixed, indeed.
>
> Good to see we agree on this. Yes, creating Threads in random ThreadGroups has always felt wrong to me - I've always taken the view if I do that I deserve to have problems. So while I agree with you it's a bad idea  I don't think I've ever seen a document which says explicitly what is and isn't legal:
>
> 1/ Clearly a sandboxed application that isn't signed is going to have a lot of restrictions - it should expect to be limited to nested ThreadGroups.

That's correct.

> 2/ A standalone Java application running without a SecurityManager can do whatever it pleases - if it can get a reference to a ThreadGroup it can use it, but fortunately AppContext doesn't apply there.

In standalone mode, there is one AppContext for the root thread group 
(and all the nested groups, unless application explicitly creates more 
AppContexts).

> 3/ The case which seems fuzzy to me is what can a signed and fully permissioned Webstart/Applet application do? Is it like 1/ or 2/ or something in between? I don't believe I've ever found that documented.

In this case, application is able to access all the thread groups and do 
whatever it needs. However, it should be ready to handle cases, when 
there is no AppContext (no UI) in a thread group, or AppContext is 
different than application's own AppContext. This is not what we want to 
clearly document or add specification for, because it's supposed to be 
completely transparent for applications (unfortunately, sometimes it is 
not).

> I think the important point is actually the RMI/JIN/Cocoa stuff but the question above isn't entirely academic as folks are often required to use 3rd party libraries whose source isn't available to them to modify which may do questionable thing. But in the grand scheme of things if the common cases all work defining the precise rules for 3/ is less important.

Thanks,

Artem

> AndyT (lordpixel - the cat who walks through walls)
> A little bigger on the inside
>
> 	(see you later space cowboy, you can't take the sky from me)
>