Exported resources

[Bryan Atsatt]

I don't think I'm missing anything, just looking at it from perhaps a
different perspective :^)

First, 294 will determine accessibility for non-exported classes. The
assumption at the moment is that they will not be accessible to *any*
class outside of the module.

I do understand the value of a "friend" semantic; it would certainly be
nice to grant certain frameworks special access. But, so far, that is
not on the table for classes.

And if we don't have it for classes, I can't see why we should have it
for resources.

// Bryan

Glyn Normington wrote:
>
> Some feedback from an observer which may help:
>
>  > Bryan misses the need for extender model to load internal impl
> classes ala
>  > Bundle.loadClass in OSGi.
>  >
>  > You do not want to have to export the service impl class from a module.
>  > You want to hide the class from others' casual loading. However an
>  > extender bundle (e.g. ServiceLoader) will need to be able to load that
>  > class to make it instances of it available to others under the service
>  > interface class.
>
> Glyn
>
> *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 30/05/2007 21:21:36:
>
>  > 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
>  >
>  >
>  >
>  >
>  > Stanley M. Ho wrote:
>  > > Hi Bryan,
>  > >
>  > > Those resource-related methods in ClassLoader can be called by anyone,
>  > > including code that is part of the module, code that is from other
>  > > modules, or code that is part of the platform libraries (e.g.
>  > > ResourceBundle). The approach you described would require walking the
>  > > stack to get the caller's Module, but the real issue is that it is
>  > > difficult to determine who the actual caller is from the stack.
>  > >
>  > > Treating the immediate caller on the stack as the actual caller
> wouldn't
>  > > be sufficient because the immediate caller could be called by someone
>  > > else who is the one actually making the call. On the other hand,
>  > > treating the originated caller on the stack as the actual caller would
>  > > be the right semantic, but this is basically the same as the security
>  > > permission approach.
>  > >
>  > > - Stanley
>  > >
>  > >
>  > > Bryan Atsatt wrote:
>  > >> Both solutions require stack walking (unless there is some new
>  > >> implementation of the java security model I've not yet seen!).
>  > >>
>  > >> The permission check does much more work than is necessary here.
> Take a
>  > >> look at AccessController.checkPermission() to see what I mean.
>  > >>
>  > >> And actually there is a very simple API to get the stack, which I've
>  > >> used for years:
>  > >>
>  > >>   private static class StackAccessor extends SecurityManager {
>  > >>       public Class[] getStack() {
>  > >>           return getClassContext();
>  > >>       }
>  > >>   }
>  > >>
>  > >>   private static final STACK_ACCESSOR = new StackAccessor();
>  > >>
>  > >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
>  > >>
>  > >> // Bryan
>  > >>
>  > >>
>  > >>
>  > >> Stanley M. Ho wrote:
>  > >>> Hi Bryan,
>  > >>>
>  > >>> Bryan Atsatt wrote:
>  > >>>> 1. Definitely agree that resource search order should be
> identical to
>  > >>>> class search order.
>  > >>>
>  > >>> Glad to hear!
>  > >>>
>  > >>>> 2. Using permissions to limit access to private resources seems like
>  > >>>> overkill to me. The prototype implemented this in a very simple
>  > >>>> fashion:
>  > >>>>
>  > >>>> a. If resource is exported, return it, else
>  > >>>> a. Get the caller's Module (get class from stack, get module
> from it)
>  > >>>> b. If callerModule == this, return resource, else return null.
>  > >>>
>  > >>> The issue is that this approach still requires stack walking and
> there
>  > >>> is no public API in the SE platform that let you implement this.
>  > >>>
>  > >>> If stack walking is required for the check anyway, I think the
> security
>  > >>> permission approach is better that it is implementable with the
> existing
>  > >>> API in the SE platform.
>  > >>>
>  > >>> - Stanley
>  > >>>
>  > >
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>