Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
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!)
Yes. In this case, it's the ResourceBundle API calling it to retrieve
ListResourceBundle, so it'll have the sufficient permissions to do that.
Anyway, I think we should leave this issue aside for now.
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.
I think we should step back to rethink the use cases a bit.
Typically, a module calls some APIs (e.g. ResourceBundle, AWTToolkit,
etc.) and these APIs might then retrieve resources through the module's
ClassLoader.getResource*(). If we are saying that a module is required
to make these resources exported in order for these use cases to work,
then what are the actual use cases we want to support by hiding
resources from getResource*()?
I think there remains a common use case where hiding resources would be
a good thing if developers want to hide all the resources that are not
used by anyone through ClassLoader.getResource*() (e.g. all the .class
files). On the other hand, I think the use case where the code in the
module calls its own ClassLoader.getResource*() to retrieve private
resources directly is not very common; If this is a rare use case, I
don't think it makes sense to introduce this notion of "private
resources". If we are forcing developers to export resources for the
common use cases (like ResourceBundle and ServiceLoader) anyway, then
why not require them to export resources in other cases as well?
It would help if there are some real use cases to support why it is
important to have this notion of "private resources".
One very common use case comes from the EE world: web modules containing
html/gif/xml/jsp files, all of which are implementation details.
I would assume that most any app with a UI would have similar resources.
- Stanley
