Yes, I think we're getting close now :^)
(By "privileged reflection", you mean having permission to call
AccessibleObject.setAccessible(true), right? If so, then we're back to
the grant issue!)
I still think we can provide "private", (i.e. non-exported) resources
which *are* available to the module classes, but to no class outside of it.
Without using permissions.
Remember this?
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
If a resource is found, and is not-exported, a module class loader can
use this (or similar) to get the immediate caller's class (at a fixed
index).
If the caller class' Module does not match that for the loader, we don't
return the resource.
Which is what I did in the prototype.
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Suppose we say that resources like (a) should be exported while
resources like (b) should remain private (and we'll use the security
permission approach to allow module to access its own private
resources), do you think you can live with this?
It isn't just me that can't live with it :^). You are correct that
private *property-based* resources could be retrieved this way, but
incorrect about *list-based* resources.
"List-based" resources are... *Class* instances. Specifically, they are
subclasses of ListResourceBundle. They must be loaded and instantiated
by ResourceBundle.
Oops... I missed that. ;-)
If ListResourceBundle subclasses are module private,
ResourceBundle.getBundle() will fail. And we have no mechanism to grant
access.
If some class needs access to non-public/exported details of another
class, you can always use privileged reflection. That is the solution
today and I expect it will be available with superpackages too. In other
words, it is possible for ResourceBundle.getBundle() to succeed. Of
course, it is still debatable whether changing ResourceBundle to use
privileged reflection to access ListResourceBundle in a module is the
right thing to do.
I think I begin to see your point. To elaborate on what you said, if
ListResourceBundle must be made exported, then it probably makes sense
to require property-based resources to be exported from the module as
well. If we go down this path, then all resources that are accessible by
the module itself or other modules should be made exported, and it won't
require the security permission approach to support it. Actually,
calling it "exported resource" would be misleading; what it really means
is "public resource" or "accessible resource" which can be accessed by
anyone, but nobody could access the "private resource" including the
module itself.
- Stanley
