Exported resources

[Bryan Atsatt]

Whoops, .jsp files are not candidates for private resources, since the
*container* must have access to them. But I stand by the gif/html/xml
comment :^).

Another candidate is property files (thanks to Stephen McConnell for
reminding me), when used as default configuration.

Bryan Atsatt wrote:
> 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
>>
>