Resource encapsulation

Mon Oct 5 18:59:23 UTC 2015

(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