Discussion: #ResourceExistenceAndSize
David M. Lloyd
david.lloyd at redhat.com
Tue Sep 6 14:24:54 UTC 2016
On 07/19/2016 04:08 PM, mark.reinhold at oracle.com wrote:
> 2016/7/13 9:22:43 -0700, david.lloyd at redhat.com:
>> On 07/13/2016 09:29 AM, mark.reinhold at oracle.com wrote:
>>> Reference: http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceExistenceAndSize
>>>
>>> ...
>>>
>>> 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.
>
> So would a simple Module::getResourceSize(String name) method, which
> returns a long value to indicate the size of the named resource, or
> else -1 if it doesn't exist, be sufficient?
>
> We could consider adding a similar method alongside the other existing
> getResource* methods in java.lang.Class and ClassLoader.
This would be minimally acceptable. I think having some kind of handle
to a resource is "better" for various reasons - particularly where class
loaders are involved, given the arbitrary nature of class loader
delegation, so that when one resource references another, the loading
party can ensure that the intent of that reference is made clear by
initiating related loads from the same "vector", be it a module or a
class loader. URL is clearly an inadequate tool for this purpose for
reasons which are well-understood I think, hence my proposal for a
"resource" concept. This would solve the size/existence problem as well
as the initial vector problem, and should be feasible to implement.
--
- DML
More information about the jpms-spec-experts
mailing list