ERR: Internal compiler error
sys::UnknownTypeErr: sys::FanObj
fan.sys.Pod.type (Pod.java:284)
compiler::ReflectPod.resolveType (ReflectPod.fan:48)
...
compiler::CallResolver.resolve (CallResolver.fan:62)
...

Somewhere in this stack I wish it had reformatted the error to give a better clue what is going on (i.e. the offending line of code). So I patched the compiler to give a better clue: https://gist.github.com/2005093

Now the error looks like:

F:\projects\fantom\coroutine\faio\fan\BufInterop.fan(8,13): Unknown type sys::FanObj while resolving bufImpl.pipeTo(byteBuffer, src.remaining())

I reduced my code down to this test case which triggers the error:

using [java]java.nio::ByteBuffer
using [java]fan.sys::Buf as BufImpl

class BufInterop {
  static ByteBuffer bufToByteBuffer(Buf src) {
    ByteBuffer byteBuffer := ByteBuffer.allocate(src.remaining)
    BufImpl bufImpl := src
    bufImpl.pipeTo(byteBuffer, src.remaining)
    return byteBuffer
  }
}

Not totally sure what is going on there, but removing the call to pipeTo() seems to get me past the error.

I'm also able to get the same error if I do:

using [java]fan.inet::IpAddr as IpAddrImpl

...
connect(IpAddr addr)
{
  InetAddress javaAddr := ((IpAddrImpl)addr).peer.java
}

Some issue caused by trying to use the native counterparts of these classes directly?

Unknown type sys::FanObj while resolving (([java]fan.inet::IpAddr)addr).peer

For now I can workaround it like this:

socketAddress := InetSocketAddress(addr.toStr, port)

But ideally I could re-use that already created InetAddress somehow.

How are you even able to access those packages in FFI, what you should be getting is this:

E:\stuff\play\play.fan(1,1): Java package 'fan.inet' not found

The way I have it wired up right now, native code peer classes are hidden to the Java FFI

Hmmm I don't recall doing anything special to access them.

Any suggestion on how to get the same effect without directly accessing those classes? Do I need to make my own java class for this?

Any suggestion on how to get the same effect without directly accessing those classes? Do I need to make my own java class for this?

The current design doesn't allow external pods to access the peer classes of another pod. I sort of think that is a good thing, but might be cases where that is too restricting. The ideal situation is to just make all your public access via Fantom APIs, and maybe if you need a special hook use trap operator or use some custom Java classes.

I guess I meant specifically, how could I best get my hands on the InetAddress attached to an IpAddr, so I can pass it to java.nio methods?

Typically the best way to handle that is in Java code, not Fantom code by accessing the peer. But we could also stick a trap hook in there to get the Java (I often use that technique). I will take a look.