mark.reinhold at oracle.com
mark.reinhold at oracle.com
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
- 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 . These methods will not locate resources in other named
- The ClassLoader::getResource* methods do not locate resources in any
- 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"  and "readable artifact" requirements 
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.)
 This was enabled just last week: http://j.mp/1NgIVg7
More information about the jpms-spec-experts