RandomAccessFile or equivalent?

[hackm...@gmail.com]

I'd like to download a zip/jar file as a means for packaging up a bunch of related assets. The zip/jar will not be compressed, which would lend itself to directly reading assets, rather than unpacking. The ideal thing for this would be something close to the nio memory mapping stuff, which obviously won't exist, but might it be possible to build something that roughly mirrors the fopen/fread/fwrite/fclose kind of functionality? J2ME is probably out of the question, but how about Android/iOS?

[Shai Almog]

We currently don't have anything like that and I don't really understand the use case.
I understand the desire to download one file, but why not unpack it on download to the storage area?
The storage area is seamless to users who normally can't see the files stored there so there shouldn't really be a problem there.

We support GZip if you want to keep the files small and there was a recent contribution containing tar support although its currently not slated to go into the core:
http://code.google.com/p/codenameone/issues/detail?id=754

[hackm...@gmail.com]

Well, someone mentioned an e-reader before, and that would be a perfect use case. An .epub is a zip file with the artifacts, and the assets don't necessarily need to be compressed. You could leave the assets in the .epub, rather than unpacking them.... but it would be easier to manage the single file rather than potentially hundreds of files.

Something like DataInputStream would be usable except that typically, it buffers the whole input in memory and the data size here might be quite large.

[Shai Almog]

It would be a pain to manage multiple files but it would be more efficient. Also you can effectively hide this completely from your code by encapsulating the file management into a single class, after all using a random access file and seeking is also very painful and error prone.

Having said that we might be able to add RandomAccessFile in the future or even NIO but it will only be for smartphones for obvious reasons. Right now we don't have any short term plans to do that though.
If you want to take that up, we'd be happy for a contribution.

[hackm...@gmail.com]

What's the general policy for something like this? I could mirror the API of RandomAccessFile (or somesuch) by using a page cache and opening/reopening streams as necessary... I guess the package should be something other than java.io? I could also tweak DataInput so it uses a page cache... or perhaps wrap an InputStream in a PagedInputStream so that it would support mark...

[Shai Almog]

That seems somewhat backwards. You want to use RandomAccessFile to mimic multiple files in a single file that maps to actual multiple files?

Just create a getFile API that will return a stream to a specific file, if it will use something like seek (in platforms where RandomAccessFile makes sense) or something else is up to you.

Anyway, I would always avoid placing anything in the java* packages as well as the com.codename1* packages since we might change/add to those and your code might break. I suggest always working with your own packages.

[maaar...@gmail.com]

Any news on RandomAccessFile or memory mapped IO? I need to work with legacy home-brew database files (from a desktop application) and that's where ByteBuffer would be perfect. It obviously won't work in browser, but Android and iOS suffice.

The files should get synchronized with desktop which is another problem, I could use an advice on.

[Shai Almog]

Not right now. We didn't have much demand for that other than this post from 2013 so it just didn't happen.
Technically most of NIO's buffers should be trivial to port. If you just want to do this for iOS and Android you can probably just implement it with a native interface as our GC doesn't compact it should work reasonably well. You can also implement something basic in the Codename One packages and submit it as a pull request.