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
