#862 Java FFI issue: conflicts with type slot

alena Fri 11 Dec 2009

Hi guys,

While working with Java FFI, I've come across an issue: if an original java class has got field/method which name conflicts with any Obj type's slot there's no way to access it through FFI.

Here's an example of code.

Original Java class:

public static class FieldInfo extends ElementInfo {
  public String type;

Inside Fan script:

info := FieldInfo()
info.type = "someType" // Compiler errors on this line:
                       // 1. 'sys::Str' is not assignable to 'sys::Type'
                       // 2. Left hand side is not assignable



DanielFath Fri 11 Dec 2009

Yeah, it seems Fan converts Java classes into a Fan class. Have you tried using


brian Sat 12 Dec 2009

This is sorta a tough problem since there is really just one slot namespace. For methods like toImmutable and isImmutable there likely won't be conflicts. But type is something used all the time in normal code.

We've previously discussed freeing up type not actually be a slot on objects, and using the # syntax to get the type from an instance (I believe Stephen has championed this approach).

I am open to that approach if there is general consensus.

brian Sat 12 Dec 2009

Renamed from Java FFI issue: Name conflict is not being resolved to Java FFI issue: conflicts with type slot

Yuri Strot Tue 15 Dec 2009

+1 for type freeing up. I agree with Stephen: it's really useful name for slot.

tactics Tue 15 Dec 2009

+infinity for freeing up type. I have run across this problem a dozen times in Fantom, naming a slot Foo.type, and then realizing, oh yeah, type is taken.

I think foo# is fine for getting the type of an instance, but it still needs to be backed by a method. The hard part is finding the best name for it ( foo.fanType or something).

andy Wed 16 Dec 2009

I'm not sure how to make this work without swizzling the conflicting Java field/methods. Something like prepending "j":

foo.bar.MyJavaClass#make  =>  [java]foo.bar::MyJavaClass#.jmake

Login or Signup to reply.