Discussion: #ResourceExistenceAndSize

David M. Lloyd david.lloyd at redhat.com
Tue Sep 6 14:24:54 UTC 2016

On 07/19/2016 04:08 PM, mark.reinhold at oracle.com wrote:
> 2016/7/13 9:22:43 -0700, david.lloyd at redhat.com:
>> On 07/13/2016 09:29 AM, mark.reinhold at oracle.com wrote:
>>> Reference: http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceExistenceAndSize
>>> ...
>>> At any rate, I don't see anything here that's inherently part of the
>>> design of the module system, so I intend to close this issue as
>>> unrelated.
>> The relation comes in because Class and ClassLoader have a way to open a
>> resource with a URL, but Module does not, providing only a
>> getResourceAsStream() method.  Adding a getResource() method would be
>> one solution, but the underlying requirement is really that the resource
>> existence and size (and origin) could/should be queriable as well, so
>> that was the issue I registered, especially as URL is really not a great
>> solution to this problem.
> So would a simple Module::getResourceSize(String name) method, which
> returns a long value to indicate the size of the named resource, or
> else -1 if it doesn't exist, be sufficient?
> We could consider adding a similar method alongside the other existing
> getResource* methods in java.lang.Class and ClassLoader.

This would be minimally acceptable.  I think having some kind of handle 
to a resource is "better" for various reasons - particularly where class 
loaders are involved, given the arbitrary nature of class loader 
delegation, so that when one resource references another, the loading 
party can ensure that the intent of that reference is made clear by 
initiating related loads from the same "vector", be it a module or a 
class loader.  URL is clearly an inadequate tool for this purpose for 
reasons which are well-understood I think, hence my proposal for a 
"resource" concept.  This would solve the size/existence problem as well 
as the initial vector problem, and should be feasible to implement.

More information about the jpms-spec-experts mailing list