Issue: Modules can only open resources as streams
Remi Forax
forax at univ-mlv.fr
Tue Mar 22 00:39:28 UTC 2016
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
>
More information about the jpms-spec-experts
mailing list