non-abstract extension of <nio.FileChannel>

[kvnsmnsn]

I'm a grad student at BYU who needs to write a hash table to disk
at times and at other times read it back from disk. My advisor thinks
that the <nio> package might help me with that. Class <FileChannel>
of that package looks promising; in fact it looks like its
<read( ByteBuffer dst, long position)> and
<write( ByteBuffer src, long position)> methods are precisely what I
need. But they're both declared <abstract>, which means I have to
write a class that extends <FileChannel> and actually implements those
two methods, doesn't it?

I couldn't see any classes listed as extensions of <FileChannel>
at the top of the API for that class. Does anybody out there know of
any extensions that I can use? Or failing that, how I can write my
own extension of <FileChannel>?

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[Chris Smith]

I'm a grad student at BYU who needs to write a hash table to disk
at times and at other times read it back from disk. My advisor thinks
that the <nio> package might help me with that. Class <FileChannel>
of that package looks promising; in fact it looks like its
<read( ByteBuffer dst, long position)> and
<write( ByteBuffer src, long position)> methods are precisely what I
need. But they're both declared <abstract>, which means I have to
write a class that extends <FileChannel> and actually implements those
two methods, doesn't it?

No. The standard API does it for you. The classes that implement those
methods are not public, so they don't appear in the API documentation.
You get the channel by calling getChannel on an object of one of the
following three classes: FileInputStream, FileOutputStream, or
RandomAccessFile.

In general, the "Use" link at the top opf the API docs is useful for
answering this kind of question.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

But they're both declared <abstract>, which means I have to
write a class that extends <FileChannel> and actually implements those
two methods, doesn't it?

In Java when something is abstract it is rare you have to extend the
class yourself . Nearly always there is a factory method hiding
somewhere. Check the USE button in JavaDoc and look for concrete
implemenations of the abstract class.

see http://mindprod.com/jgloss/bytebuffer.html
for sample code.

I think the idea to keep the hash keys in RAM and the records on DISK.

See http://mindprod.com/jgloss/hermitcrab.html
for a somewhat elaborate version of what you are doing.

 

[kvnsmnsn]

=> I'm a grad student at BYU who needs to write a hash table to
disk
=> at times and at other times read it back from disk. My advisor
thinks
=> that the <nio> package might help me with that. Class <FileChannel>
=> of that package looks promising; in fact it looks like its
=> <read( ByteBuffer dst, long position)> and
=> <write( ByteBuffer src, long position)> methods are precisely what I
=> need. But they're both declared <abstract>, which means I have to
=> write a class that extends <FileChannel> and actually implements
those
=> two methods, doesn't it?
=
=No. The standard API does it for you. The classes that implement
those
=methods are not public, so they don't appear in the API documentation.
=You get the channel by calling getChannel on an object of one of the
=following three classes: FileInputStream, FileOutputStream, or
=RandomAccessFile.

Chris, thanks, this worked just fine. I was able to put a value
into a <ByteBuffer>, write it to a file, read it back from the file,
and verify that the value I originally put in actually came back in-
tact.

Now I've got a different problem. My advisor seems to think that
I should be able to take an arbitrary data structure (in my particular
case a complicated hash table), convert it to a <ByteBuffer>, and then
store that <ByteBuffer> to disk, in such a way that I can read the
data structure back later whenever I needed it.

I tried to do this by converting a data structure to an <Object>
and then that <Object> to a <ByteBuffer> like so:

sourceBb = (ByteBuffer) (Object) source;

But when I run this it throws a <ClassCastException> exception right
at this point in my code. Am I taking the wrong approach? Does any-
body know a way to convert an arbitrary data structure to a
<ByteBuffer>? Any information you can give me on this would be great-
ly appreciated.

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[Roedy Green]

I tried to do this by converting a data structure to an <Object>
and then that <Object> to a <ByteBuffer> like so:

sourceBb = (ByteBuffer) (Object) source

That should give an exception. What he meant was serialising the
objects. See http://mindprod.com/jgloss/serialization.html

 

[Chris Uppal]

Now I've got a different problem. My advisor seems to think that
I should be able to take an arbitrary data structure (in my particular
case a complicated hash table), convert it to a <ByteBuffer>, and then
store that <ByteBuffer> to disk, in such a way that I can read the
data structure back later whenever I needed it.

The only two ways that you can do this, afaik, are (1) to serialise the data
structure, or (2) to design the data structure explicitly so that the whole
thing is (at some level accessible to your code) viewed as a single array of
bytes.

(1) Is only possible under certain circumstances. It requires that all the
data in the data structure (as well as the DS itself) be serialisable -- that
can be /made/ true, but is unlikely to happen by accident. Also note that
serialisation is inherently a stream-oriented operation (can be done in a
single pass over both the object network and the bytes written/read), so there
is no obvious reason for using an nio ByeBuffer in preference to an ordinary
binary stream.

(2) Clearly requires a very specific design /and/ implementation, and will not
be applicable to "an arbitrary data structure".

So I suggest that you may have misunderstood your advisor.

-- chris