Resource encapsulation

[mark.reinhold at oracle.com]

(combining several questions into one topic thread)

2015/9/28 10:02 -0700, peter.kriens at aqute.biz:
> The javadoc for getResource* says: 
> 
> 	‘This method does not find resources in named modules’.
> 
> Literally this implies that a class in a named module cannot read its
> own resources. I assume that this is an oversight in the description?

There is a plethora of resource-lookup methods.  The current state of
affairs is:

  - A class in a named module can read its own resources via the
    Class::getResourceAsStream method, which returns an InputStream.  It
    can get a URL to one of its own resources via the Class::getResource
    method [1].  These methods will not locate resources in other named
    modules.

  - The ClassLoader::getResource* methods do not locate resources in any
    named modules.

  - All existing resource-lookup methods in Class and ClassLoader work as
    they do today for resources on the class path.

  - The new java.lang.reflect.Module::getResourceAsStream method can be
    used to read the resources of any named module, without restriction.

These choices are a first attempt to strike a balance between satisfying
the "resource encapsulation" [2] and "readable artifact" requirements [3]
while making it reasonably easy to migrate existing components into
modules, but I don't think we're quite there yet.  At the very least, the
Module::getResourceAsStream method needs to be restricted somehow so that
only "suitably-privileged" code (for some definition of that term) can
access resources in a named module other than its own.

2015/9/28 10:03 -0700, peter.kriens at aqute.biz:
> In Java Persistence Architecture (JPA) the persistence.xml resource
> provides information about the persistence unit. This resource must be
> read by the Persistence Provider which then does a lot of magic.
> 
> However, if nobody can read resources from a named module then how can
> JPA perform its duties?

JPA will work exactly as it does today for code on the class path.

A future version of JPA that supports modules will, I assume, itself be
a "suitably-privileged" module.  It can use the various reflection APIs
(java.lang.reflect.Module, etc.) to locate run-time module objects and
read their resources.

In the longer term, a better way for a module to publish configuration
information for a framework such as JPA would be for it to supply a
provider of a service type defined by the framework.  JPA could, e.g.,
export and use a javax.persistence.Configuration service type, and then a
client module could provide an instance of that type in order to convey
its configuration information.

2015/9/28 10:04 -0700, peter.kriens at aqute.biz:
> Since resource loading is very restrictive I would expect that class
> loading is also not possible unless a class is exported. Is this true?

The module system, as proposed, does not change the run-time visibility
mechanism.  Methods such as Class::forName and ClassLoader::loadClass
will work as they to today.  If a class loader queried by these methods
finds a definition for the specified class then a Class object will be
returned regardless of whether that class's package is exported by its
defining module.  (Whether you can access members of the resulting class,
or instances thereof, is a question of access control and hence is, now,
dependent upon the module system.)

- Mark


[1] This was enabled just last week: http://j.mp/1NgIVg7
[2] http://openjdk.java.net/projects/jigsaw/spec/reqs/#resource-encapsulation
[3] http://openjdk.java.net/projects/jigsaw/spec/reqs/#readable-artifacts