Frank said:
B) each time you need to jump to a location, open a new InputStream and
use it's .skip method (the default implementation actually reads through n
bytes, but for a .jar file, I think this method is overloaded to roughly
jump to the correct position in a single operation).
I wouldn't bet on that, not without testing it and/or reading the source (to
the JVM and library that your code will run on).
The JAR file format is basically the same as the ZIP file format, and random
access within a ZIP file entry is not necessarily constant-time since
compressed formats don't naturally support jumping around. It /may/ be fast if
the .WAV entry is not compressed (which would make sense, but I'm not sure
it'll happen by default), /and/ the implementor thought it worthwhile
recognising and handling that case, but there's no reason to suppose it /must/
be. (People don't generally do random access in ZIP files, so why bother
writing code to optimise a case that is unlikely to occur ?)
That said, if you aren't doing /lots/ of random access (only when the user asks
for it, say) then starting again at the beginning each time may well be plenty
fast enough, even if the ZIP code doesn't do real random access underneath.
-- chris