Exported resources

[Bryan Atsatt]

I've been assuming that Module private resources should not be visible
to *any* class outside of the module. Including ResourceBundle, or any
other existing framework classes that do resource lookups (e.g.
ServiceLoader, JSF, etc). If resources need to be visible to these
existing classes, they must be exported. The very simple check I
proposed (immediate caller) is sufficient to make this assertion.

I believe your point is that if we used the permission model instead, it
would become possible for a module to invoke an external class (e.g.
ResourceBundle.getBundle()) and enable *it* to successfully load a
private resource from the module.

Aside from the permission *grant* mechanism this model would rely on, it
is an entirely different model than that used for classes! (Though we
haven't explicitly defined this in 294, it seems extremely unlikely that
we will rely on permissions--none of the other access modes do so.) Such
asymmetry is very disconcerting to me, and, I believe, just plain wrong...

Consider that you could grant the ServiceLoader, for example, access to
a resource that names a class that it could not instantiate. That class
would have to be exported. I believe the resource should be as well.

// Bryan




Stanley M. Ho wrote:
> Hi Bryan,
>
> Those resource-related methods in ClassLoader can be called by anyone,
> including code that is part of the module, code that is from other
> modules, or code that is part of the platform libraries (e.g.
> ResourceBundle). The approach you described would require walking the
> stack to get the caller's Module, but the real issue is that it is
> difficult to determine who the actual caller is from the stack.
>
> Treating the immediate caller on the stack as the actual caller wouldn't
> be sufficient because the immediate caller could be called by someone
> else who is the one actually making the call. On the other hand,
> treating the originated caller on the stack as the actual caller would
> be the right semantic, but this is basically the same as the security
> permission approach.
>
> - Stanley
>
>
> Bryan Atsatt wrote:
>> Both solutions require stack walking (unless there is some new
>> implementation of the java security model I've not yet seen!).
>>
>> The permission check does much more work than is necessary here. Take a
>> look at AccessController.checkPermission() to see what I mean.
>>
>> And actually there is a very simple API to get the stack, which I've
>> used for years:
>>
>>   private static class StackAccessor extends SecurityManager {
>>       public Class[] getStack() {
>>           return getClassContext();
>>       }
>>   }
>>
>>   private static final STACK_ACCESSOR = new StackAccessor();
>>
>> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
>>
>> // Bryan
>>
>>
>>
>> Stanley M. Ho wrote:
>>> Hi Bryan,
>>>
>>> Bryan Atsatt wrote:
>>>> 1. Definitely agree that resource search order should be identical to
>>>> class search order.
>>>
>>> Glad to hear!
>>>
>>>> 2. Using permissions to limit access to private resources seems like
>>>> overkill to me. The prototype implemented this in a very simple
>>>> fashion:
>>>>
>>>> a. If resource is exported, return it, else
>>>> a. Get the caller's Module (get class from stack, get module from it)
>>>> b. If callerModule == this, return resource, else return null.
>>>
>>> The issue is that this approach still requires stack walking and there
>>> is no public API in the SE platform that let you implement this.
>>>
>>> If stack walking is required for the check anyway, I think the security
>>> permission approach is better that it is implementable with the existing
>>> API in the SE platform.
>>>
>>> - Stanley
>>>
>