Exported resources

[Bryan Atsatt]

Hey Stanley,

Sorry to be generating so much traffic while you're traveling! I'm not
in any rush here, so feel free to take your time responding...

Stanley M. Ho wrote:
> Hi Bryan,
>
> A module can use the ResourceBundle API to retrieve resources from other
> resource modules, but it can also use the ResourceBundle API to retrieve
> resources from the (target) module itself. In the latter case, the
> resources are currently not required to be exported from the target module.
>
> I don't think we want to force a module to export its own private
> resources simply because it wants to use the ResourceBundle API in this
> case, would you agree?

No, I don't agree. That's what I said before :^). I *really* don't like
the idea that I'm going to have to explicitly grant permission to some
module to access my resource. This *significantly* complicates
deployment. How will the grant occur, especially given that each
environment can use an entirely different permission storage mechanism?

Or are you thinking that the loaders in the module system will construct
ProtectionDomains pre-wired with permissions? If so, exactly which
entities will be blessed? Just the JRE code? What about all the existing
non-JRE frameworks in use?

> Regarding there are differences in the access models between classes and
> resources, I also prefer symmetry if possible. However, the access model
> for classes and resources have always been different, and there are
> built-in JVM support for classes while there is none for resources, so
> it is unclear if we can completely eliminate this asymmetry after all.

Sure, resources have never had JVM access control applied to them. But I
don't think we should go to the other extreme (permissions) just so that
I can give "friend" access to private resources. I'd much prefer that
such resources simply be exported.

And I don't see this as a particular problem, either. We've gotten along
just fine without private resources so far (or maybe there is some big
demand for this that I'm missing?).

And what about the mismatch issue I brought up? Lots of existing
frameworks use the "services" pattern, in which:

1. A well known resource name is used in a getResource() call.
2. The resource contains a string naming a provider class.
3. The provider class is loaded using Class.forName().

This is a simple but very powerful pattern, but it requires that *both*
the resource and the named class be accessible to the framework. If we
require a permission grant for the resource, but not for the class, it
will be very easy to get access to one and not the other. Is it really
worth opening up this potential headache to enable a friend model for
resources?

// Bryan

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