Here is the use case I care most about for interoperability.

I want a Fan class to be able to implement a Java interface and for the Fan code to be loaded as just another jar file within a larger Java application.

Why is this use case significant? Because it allows a new component within a larger system to be written entirely in Fan. ie. start large Java web app, and handle one piece of functionality via an interface which happens to call Fan code.

This keeps managers happy (if the new-fangled Fan technology doesn't work, then its easy to swap back in Java code - in fact two competing pieces of code could be written and compared). It also keeps deployers happy, as they still just deploy jar files. It also keeps developers happy (they might not even tell the managers and deployers about the new-fangled Fan... ;-)

Now none of this is easy! This still requires handling arrays and primitives on input. It definitely involves handling overloading from the implemented interface.

More significant is the ability to run Fan as a jar within a Java app. Currently, that isn't how Fan runs - I don't know how much of a challenge that would be. Hopefully not too much.

Calling out to Java code is going to be the fairly easy part. Mostly it is just a matter of deciding how to map arrays to lists.

Extending classes and interfaces isn't too bad - the only super tricky part is methods overloaded by parameter (and the array problem).

Shipping Fan code as a normal Jar pretty much already happens today - that is how we compile native implements against the Fan classes. But if you don't emit fcode to bytecode at runtime, then you will run into the fragile base class issue with mixins - I'm not sure you can get around that. If you can live with that issue, then you can precompile to bytecode as a normal jar. But you will still need Fan's reflection info and the Fan runtime library.

I think Fan consuming Java libraries will work well. I'm not sure Java consuming Fan libraries will work out that great. But maybe if all you are doing in your Fan code is private implementations of Java classes/interfaces that would probably work fine.

But if you don't emit fcode to bytecode at runtime, then you will run into the fragile base class issue with mixins - I'm not sure you can get around that. If you can live with that issue, then you can precompile to bytecode as a normal jar. But you will still need Fan's reflection info and the Fan runtime library.

The standard mechanism of running Fan is by late bytecode compilation IIUC. I believe that is fine and meets the use case, because all the main Java codebase knows about is the interface (coded in Java).

The tricky part is how to load the implementation if the Fan class in such a way that it can be treated as an implementation of the Java interface. Perhaps a dedicated Fan classloader is what is needed here.

public interface MyJavaInterface { .. }

class MyFanClass : MyJavaInterface { ... }

public void myJavaMethod() {
  MyJavaInterface obj = ????

  // a couple of ideas...
  MyJavaInterface obj = new MyFanClass();
  MyJavaInterface obj = Fan.load("mypod.MyFanClass");
}

The tricky part is how to load the implementation if the Fan class in such a way that it can be treated as an implementation of the Java interface.

In the case you are talking about, that would work fine today. The FanClassLoader uses the normal system classloader to load classes external to Fan. Then it checks for precompiled bytecode in the .pod file and if found uses that (used for native methods). Last resort is to generate bytecode from the fcode.

We'll have to precompile though when Java code wants to compile directly against Fan APIs or we have a more complicated classloading scenario. At the JVM summit it was recommended that I use a URL classloader which might be more flexible (I haven't investigated yet though).