Issue: Modules can only open resources as streams

[David M. Lloyd]

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 redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> 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 java.net.URLs 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]
>>> https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JDK-6865375
>>
>> 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
>>

-- 
- DML