Hi!

I just discovered Fan and I don't seem to find anything about interoperability with Java from Java. Is it supported? If not, is it planned?

The main reason I ask is to see if one could write Eclipse plugins in Fan.

regards, Vlad

See Java FFI

@brian: I think vladdu is asking about interop in the opposite direction. That is, if I write code for an Eclipse plugin in Fan, what package / class names should I put in the bundle manifest to make it work?

@qualidafial: you got it right. More generally, is there any "feature which allows Java code to easily utilize normal Fan libraries"?

A related feature request: It would be nice if we can build a self-contained pod file -- something that people can run with just Java runtime (but not Fan).

Okay, I managed to locate the Jstub tool, that takes a pod and emits a jar file. Is it the way to go?

It still would be useful with an authoritative description of how to put things together, especially how Fan types are seen from Java.

regards, Vlad

The Java FFI doc is useful for bi-directional interoperability because it explains how a given Fan type will be exposed to the Java world. In this case, if you are writing an Eclipse plugin, your real Java-to-Fan interface is probably implementing and extending existing Java interfaces and classes.

When you are calling Java-from-Fan, then Fan just uses the Java class-loader. This was the original use case for the Java FFI.

When you are calling Fan-from-Java it gets trickery, because then Java's class loader has to see all of those Fan classes. This means that Fan's module management won't play well with Java. The jstub tool can be used to emit a Fan pod as a jar file, although it still leaves dependency management up to you. For example if your code uses Fan pods A, B, C, then you have to jstub all of those pods and get them into your Java classpath. In the case of Eclipse this probably involves turning them into OSGi bundles.

Also note that just because you jstub and use Java classloader, you still actually need the pods too. That is because pods contain richer reflection meta-data than Java classfiles. So they are still needed for reflection, type database, etc.

This should be doable, but might be a bit bumpy. If anyone has patches or ideas to make this use case easier, I'll be glad to help.

Thanks for the explanation, Brian.

I gave it a try and, just as you say, it's bumpy.

The main issue I had with the usability was that the Fan compiler does a lot of magic in converting from Java to Fan types. Going the other way lacks this support and one has to handle it oneself. It means a lot more boilerplate code than the use of Fan eliminates.

I'll be thinking about it some more.

regards, Vlad

Going the other way lacks this support and one has to handle it oneself.

Exposing basic classes and interfaces which use other objects and primitives like boolean, long, double, and String will work OK. But if you start to use advanced features like functions, then it will create a sub par API for a Java programmer (you can still do it, you just have to use ugly inner classes on the Java side).

Yes, functions are already too difficult...

But even for simpler cases, it's still too heavy. For example converting a fan.sys::List to a java.util.List. There's a lot of plumbing involved.

It could be very well that the Java/Fan interface should be very narrow which makes it less tedious to write the necessary conversions.

But even for simpler cases, it's still too heavy. For example converting a fan.sys::List to a java.util.List

It would be nice to have sys::List implement java.util.List - the conflict is that size has to return a long for Fan.