Issue: Modules can only open resources as streams

David M. Lloyd david.lloyd at
Tue Mar 22 13:02:54 UTC 2016

URI is definitely better than URL.  However it doesn't really solve the 
points I listed below.  It would really be useful for a resource to be a 
handle with size, stream, and origin class loader/module fields.

On 03/21/2016 07:39 PM, Remi Forax wrote:
> Hi David,
> usually, instead of using an URL, you can use an URI and if you want the info then create an URL from the URI.
> Does adding a new method getResourceAsURI() is not enough ?
> Rémi
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at>
>> À: jpms-spec-experts at
>> Envoyé: Lundi 21 Mars 2016 15:14:15
>> Objet: Re: Issue: Modules can only open resources as streams
>> On 03/03/2016 09:42 AM, David M. Lloyd wrote:
>>> Module.getResourceAsStream() is the only way a resource can be loaded
>>> from a module.  This makes it impossible to do either of the following:
>>> • Determine the size of a resource in advance of loading it
>>> • Determine the existence of a resource without opening it
>>> Loading resources as allowed these things to be done
>>> (among other things), however it is also disadvantageous due to the
>>> heavyweight nature of that class.
>>> I had earlier come up with a simple patch [1], initially as a way to
>>> address JDK-6865375 [2], which introduced the idea of a Resource class
>>> that is associated with a ClassLoader, with a name, URL, size, and
>>> stream factory method, which would also be a clean solution here (though
>>> with the addition of a Module property as well since in Jigsaw they're
>>> separate).
>>> The idea is to put resources on a similar footing to classes, whereby
>>> you can (if suitably permitted) acquire their class loaders just like
>>> Class.getClassLoader() allows you to do for classes.  This also allows
>>> things like ServiceLoader to load classes directly from the module which
>>> contained the corresponding service descriptor.
>>> [1]
>>> [2]
>> Without any further discussion I'm going to assume complete agreement
>> with the definition and acceptance of the problem and (at least the
>> general gist of) the proposed solution.  If any of you disagree with
>> this issue on any basis, PLEASE speak up ASAP otherwise I will assume
>> that the group is in agreement!
>> --
>> - DML


More information about the jpms-spec-experts mailing list