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

[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?


On Wed, Aug 8, 2018 at 1:40 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 08/08/2018 06:16, Luke Hutchison wrote:
> > 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 it's not the default.
>
> -Alan
>