On 2018-02-04T20:41:48 +0000 Alan Bateman <alan.bate...@oracle.com> wrote: > > The only support for random access is in the ModuleReader API where the > read method returns a ByteBuffer containing the resource. This is very > efficient for resources in modules that are linked into the runtime > image as it's essentially a slice of a memory mapped region. It's not > efficient for modules that are packaged as JAR files as random access > poses challenges there (esp. when entries in JAR file are compressed).
OK, thanks, that's what I suspected. I decided I could probably get away with simply being able to restart streams rather than seeking backwards. Implementing this turned out to be as trivial as opening the resource twice yielding streams A and B, playing from stream A until EOF, and then playing from stream B (whilst opening stream C in the background to act as the new stream A when B reaches EOF). It uses a constant amount of storage (the fixed-size read buffer per-stream) and doesn't seem to consume any extra file descriptors (because the JVM is obviously just reading bytes from a ZipEntry that it already has open behind the scenes). -- Mark Raynsford | http://www.io7m.com
