Exported resources

[Bryan Atsatt]

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
>