Issue: Modules can only open resources as streams

[forax at univ-mlv.fr]

----- 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 :)

Rémi

> 
> 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
>