Exported resources

[Bryan Atsatt]

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
>