Discussion: #ResourceExistenceAndSize

[David M. Lloyd]

On 07/13/2016 09:29 AM, mark.reinhold at oracle.com wrote:
> 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?

You may need to pre-size data structures like arrays, or files on the 
filesystem, or you may need the information to produce a 
"Content-Length" style header before reading any data, or to know if you 
are able to fulfill a request if the request has a minimum or maximum 
size requirement.

Testing for the existence of a resource is useful for making decisions 
about (for example) how to handle a deployment, as some specs require, 
though opening, testing, and (if not null) closing the resource does 
suffice to solve this problem, as long as doing so doesn't incur any 
kind of undue overhead (and in the modular system, it *probably* won't).

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

Yeah, I think that publishing the origin of the resource is an important 
part of resource management as well, and I probably should have made it 
all one; I suppose I left it off because the of the prior existence of 
the JDK issue.

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

Yeah the workaround for this in my patch is to provide default 
implementations which use URL to back the Resource object, which allows 
the current status quo to be maintained (though the usual issues with 
adding methods to a base class do apply).

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

The relation comes in because Class and ClassLoader have a way to open a 
resource with a URL, but Module does not, providing only a 
getResourceAsStream() method.  Adding a getResource() method would be 
one solution, but the underlying requirement is really that the resource 
existence and size (and origin) could/should be queriable as well, so 
that was the issue I registered, especially as URL is really not a great 
solution to this problem.

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

-- 
- DML