Issue: Modules can only open resources as streams

David M. Lloyd david.lloyd at redhat.com
Tue Mar 22 22:27:07 UTC 2016


On 03/22/2016 04:40 PM, forax at univ-mlv.fr wrote:
>
>
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: forax at univ-mlv.fr
>> Cc: jpms-spec-experts at openjdk.java.net
>> Envoyé: Mardi 22 Mars 2016 22:02:38
>> Objet: Re: Issue: Modules can only open resources as streams
>>
>> On 03/22/2016 12:13 PM, forax at univ-mlv.fr wrote:
>>> ----- Mail original -----
>>>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>>>> À: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: jpms-spec-experts at openjdk.java.net
>>>> Envoyé: Mardi 22 Mars 2016 14:02:54
>>>> Objet: Re: Issue: Modules can only open resources as streams
>>>>
>>>> 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.
>>>
>>> from an URI, you can call toURL() and get access to the size, the stream
>>> etc.
>>>
>>> thinking a little more on this, you can already have access to the URI of a
>>> resource of a module by using the ModuleReader, from the ModuleReference,
>>> from the Configuration, from the Layer ...
>>>
>>>     try(ModuleReader reader =
>>>     module.getLayer().configuration().findModule(module.getName()).get().reference().open())
>>>     {
>>>       Optional<URI> uri = reader.find(resourseName);
>>>       ...
>>>     }
>>>
>>> obviously, directly exposing the ModuleReader might be a good idea :)
>>
>> Knowing which module your resource came from is definitely a key
>> requirement.  I'm not sure what URI actually will benefit in this case
>> though.  Not only do you have to switch it to URL to actually use it to
>> load anything, but by returning URI, modules lose the ability to send
>> back URLs with custom behaviors.  Also it means that every resource
>> needs an absolute location, which is an unnecessary constraint as far as
>> I can see.
>
> not an absolute location per se, like an URI of a resource inside a jar,
> the URI is composed of the name of the module and the name of the resource.

An absolute module name is only useful in the context of the default 
layer.  To support multiple layers, especially if we move to a 
non-hierarchical model, every layer would need its own URI scheme (and 
probably a corresponding registered URL protocol handler) or else some 
kind of global registration, which might or might not make sense and 
might be unnecessarily complex (especially if your resource is just 
coming from, say, a JAR file, and would be served just as well using a 
classical jar: URL).  To support module-specific naming schemes, the URI 
might end up having to be awkwardly encoded.  Better to keep the module 
name out of the URL altogether.

-- 
- DML


More information about the jpms-spec-experts mailing list