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