How come 'FileChannel.map()' returns a DirectByteBufferR ?...

[Spendius]

.... that has no underlying ("backing" as they say in the doc)
array ? And how come this java.nio.DirectByteBufferR class
is not documented (does not appear in the doc, but can be
found in the src.zip file) ?!?

It's pretty annoying actually, I'd really like to be able to
play with the underlying array of a reference returned by
FileChannel.map() and be able to play with its whole contents...

Thanks for you enlightenments...
Regards,
Spendius

 

[John C. Bollinger]

... that has no underlying ("backing" as they say in the doc)
array ?

Why shouldn't it? The spec guarantees that the object you get is a
MappedByteBuffer. Because MappedByteBuffers are always direct, Java
uses the native I/O system to manipulate the buffer data wherever
possible. It is conceivable that an implementation might find a way to
satisfy that requirement while still providing a backing array, but at
the moment I can't think how it might be done.

And how come this java.nio.DirectByteBufferR class
is not documented (does not appear in the doc, but can be
found in the src.zip file) ?!?

Presumably because it is package-private in java.nio. The documentation
does not promise to give you an instance of a class that appears in the
public API. Indeed, you will find many, many cases where the same kind
of thing is done elsewhere in the platform API.

It's pretty annoying actually, I'd really like to be able to
play with the underlying array of a reference returned by
FileChannel.map() and be able to play with its whole contents...

There is no underlying array, at least not in the Java sense. That's
the complaint you began with. I don't understand why you are annoyed;
the behavior you describe complies fully with the API documentation. Do
not make assumptions about the platform API that are not backed by the
API docs, otherwise your software is likely to break, somewhere, sometime.

If you can't do what you want with the facilities that Java provides
then use a lower-level language. If you are adventuresome and also just
can't live without Java then delve into JNI.


John Bollinger
(e-mail address removed)

 

[Harald Hein]

... that has no underlying ("backing" as they say in the doc)
array ?

That's the whole idea of memory-mapped IO. Data from the disk is
directly mapped into the system's virtual memory via the MMU, and
transfered via the low-level disk driver and DMA to/from physical
memory when needed (when the MMU detects a page-miss). This reduces the
overhead for reading/writing disk data as much as possible.

HH

 

[Spendius]

Anyway I found out a way to get a *copy* (if I'm not
mistaken) of the underlying array with the following:
# ByteBuffer rMap = rCh.map(FileChannel.MapMode.READ_ONLY, 0, x);
# byte[] rArray = new byte[(int)x];
# rMap.get(rArray);
now 'rArray' is filled with the contents of my file and
I can process it as I like it...

 

[Harald Hein]

Anyway I found out a way to get a *copy* (if I'm not
mistaken)

So you throw away all the advantage of memory-mapped I/O. What you are
doing doesn't make much sense.

HH