Discussion: #ResourceExistenceAndSize

[mark.reinhold at oracle.com]

Reference: http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceExistenceAndSize

2016/3/3 7:42:47 -0800, david.lloyd at redhat.com:
> 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.

What are some use cases that require determining the existence or size of
a resource without loading it?

> 
> I had earlier come up with a simple patch [1],

(I'm not going to read your patch on GitHub since the comment on your
 repo clearly states that it is not a contribution to this JSR nor to
 OpenJDK.  If you wish the EG to consider it then please either post
 it here or contribute it explicitly to OpenJDK via some other means.)

>                                                initially as a way to 
> address JDK-6865375, 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 issues laid out in JDK-6865375 [1] are entirely different from those
of resource existence and size, though I do see how a common solution
could address all these problems.

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

I'm reluctant to introduce a brand-new general "Resource" abstraction,
along with all the complexity that would entail.  There is, among other
things, a tricky compatibility issue here, as one of the comments to
JDK-6865375 points out: Any custom class loader that today overrides the
various getResource* methods would have to be retrofitted to override all
new "Resource"-returning methods.

At any rate, I don't see anything here that's inherently part of the
design of the module system, so I intend to close this issue as
unrelated.

- Mark


[1] https://bugs.openjdk.java.net/browse/JDK-6865375