I'm playing around with the NIO.2 async I/O libraries and I'm wondering whether it would make sense to convert to/from their ByteBuffer class. Buf and ByteBuffer are very, very similar classes but alas not actually the same class so I can't pass a Buf to the NIO methods nor have ByteBuffer return the right types for use by Fantom code.

I suspect I'll end up writing my own Fantom-friendly wrapper for ByteBuffer but I was wondering if there's some way to "pierce the veil" on Buf and somehow share an underlying buffer between ByteBuffer and Buf.

Actually looking closer I suspect I could make a java subclass of Buf or MemBuf and it would let me implement things however I want to, just have to do the work in java instead of Fantom. Not the end of the world.

Take a look at MmapBuf.java which is a Buf implementation that uses NIO already.

Hmmm I do get an interesting error trying to subclass Buf in my own package:

This class must implement the inherited abstract method Buf.pos(long), but cannot override it since it is not visible from NioBuf. Either make the type abstract or make the inherited method visible

So, I declared a new class NioBuf and put it in fan.sys. I also made a version of MmapBuf that subclasses that (it only differs in the implementation of flush() and typeOf()).

Feel free to integrate this back into the core:

https://gist.github.com/1998118

I think that makes sense to rework MmapBuf as a reusable NioBuf base class. A Mercurial patch would be a bit nicer :-) But let me review your changes.

Hi brian,

Here's a patch version:

https://gist.github.com/2005051

This patch also adds the needed bits to the Sys class and Buf.fan

Not sure if there was somewhere I would have submitted this as a "pull request" ala github, is that something you're doing now?

Not sure if there was somewhere I would have submitted this as a "pull request" ala github, is that something you're doing now?

Not yet. We're looking at moving the repo to BitBucket at some point - no time frame though.

I've pushed a set of changes to basically just rename MmapBuf to NioBuf. I didn't see any need to have two classes, since the only difference is mmap.force on flush which I just handled with a cast.

I also added an Interop method to make it easily accessible:

public static Buf toFan(java.nio.ByteBuffer buf)

Ah cool, thanks.

How about the reverse Interop operation?

public static java.nio.ByteBuffer toJava(Buf buf)

Only problem I see with this one is that if the give buf is not an NioBuf you might have to wrap it in your own ByteBuffer implementation that proxies operations through to the underlying Buf. Otherwise the semantics wouldn't be preserved.

Let me know if you'd be interested in such a proxy class and I can try to make one.

I think you can only do that for some Bufs like NioBuf or MemBuf, but those are probably all you typically need, so I can add that.

I did up a version of Buf -> ByteBuffer, take a look:

https://gist.github.com/2043065

I briefly considered trying to implement FileBuf -> ByteBuffer using memory mapping but I realized that if someone wants memory mapping they should explicitly say so in the first place, otherwise it might create some surpsising problems.

Thanks, I took your patch although I reworked it a bit to use to versus as which is more our convention.

Cool, thanks!