ModuleReader does not have a method for getting size hint for a named resource

[Luke Hutchison]

The current ModuleReader API has methods list(), open(String name), and
read(String name). However, there is no way to get the length (file size)
of a resource short of opening or reading the whole resource, then
examining the number of bytes read or mapped. This can lead to unnecessary
resizing of arrays, and therefore unnecessary array copying.

Internally, the resource size is available in
ImageLocation#getUncompressedSize(). Can this be exposed as a size hint in
the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String
name) ?

[Alan Bateman]

Post by Luke Hutchison
The current ModuleReader API has methods list(), open(String name), and
read(String name). However, there is no way to get the length (file size)
of a resource short of opening or reading the whole resource, then
examining the number of bytes read or mapped. This can lead to unnecessary
resizing of arrays, and therefore unnecessary array copying.
Internally, the resource size is available in
ImageLocation#getUncompressedSize(). Can this be exposed as a size hint in
the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String
name) ?

The issue of exposing the resource size, in the context of the Module
API, was issue #ResourceExistenceAndSize in JSR 376. It was decided to
defer it as it wasn't critical for a first version.

If you are using the ModuleReader API then I assume you are doing
something that is scanning the module path (although your other mail
seems to be about resources in run-time image with compression so you
might be doing something else). If you need the size then one way to do
this is with:

    int size = reader.read(name)
                    .map(bb -> {
                        int rem = bb.remaining();
                        reader.release(bb);
                        return rem;
                    }).orElseThrow(() -> new RuntimeException("not
found"));

When not using compression then this should be backed by a region from
the underlying file mapping. Yes, the compressed case is more expensive
but

[Luke Hutchison]

Yes, I'm scanning the modules in the system. Thanks for the pointer to the
relevant section of JSR 376.

Although your code example would work for either compressed or uncompressed
resources, reading the entirety of compressed resources to determine their
size is not optimal -- hence this email, requesting an API call to get the
size hint from the corresponding ZipEntry.

Did you have comments on any of the observations in my other message that
the size of a ZipEntry cannot be trusted, or can be -1?

Post by Luke Hutchison

Post by Luke Hutchison
The current ModuleReader API has methods list(), open(String name), and
read(String name). However, there is no way to get the length (file size)
of a resource short of opening or reading the whole resource, then
examining the number of bytes read or mapped. This can lead to

unnecessary

Post by Luke Hutchison
resizing of arrays, and therefore unnecessary array copying.
Internally, the resource size is available in
ImageLocation#getUncompressedSize(). Can this be exposed as a size hint

in

Post by Luke Hutchison
the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String
name) ?

The issue of exposing the resource size, in the context of the Module
API, was issue #ResourceExistenceAndSize in JSR 376. It was decided to
defer it as it wasn't critical for a first version.
If you are using the ModuleReader API then I assume you are doing
something that is scanning the module path (although your other mail
seems to be about resources in run-time image with compression so you
might be doing something else). If you need the size then one way to do
int size = reader.read(name)
.map(bb -> {
int rem = bb.remaining();
reader.release(bb);
return rem;
}).orElseThrow(() -> new RuntimeException("not
found"));
When not using compression then this should be backed by a region from
the underlying file mapping. Yes, the compressed case is more expensive
but it's not the default.
-Alan