Disclaimer: I'm a newbie to Fan. And I did some searching on fandev.org as well as google, but couldn't find any direct answers, hence this question.

Is there a straightforward way to compile Fan code to java .class or to .NET dll?

Relatedly, what is the best way to integrate Fan code into an existing Java project or an existing .NET project? Is .class/.dll the best way or are there better approaches?

Fan is deployed using an intermediate byte code format called fcode (which is whats in a pod file). And the Fcode is emitted to Java bytecode or IL at runtime.

So far, the primary work on "native" integration has been Fan calling out to Java/C# (which is still an open issue).

I think going the other direction is going to be just as important for Fan's adoption, but we really haven't done much in that area yet. I think we want to keep Fan deployment based on pod files, so we probably just need a easy way to hook into the FanClassLoader or FanAssemblyResolver to dynamically emit fcode from the other side.

If you just want to turn a Fan pod into a jar file you can use this command:

jstub <podname>

Likewise you can turn a Fan pod into a .NET DLL using this command:

nstub <podname>

BTW Andy the nstub code looks to asssume a hardcoded path - can you take a look at that.

But you'd still need the pod files, because those carry all the Fan reflective information. So jstub is useful for creating "stubs" which allow you to compile Java code against Fan, but not necessarily a good deployment mechanism.

Your real question is on lang interop I think - calling Java/C# code from Fan and vise versa. This is still a problem we're working on (and the JVM community at large). We've some interesting discussions on the problem, but haven't started coding up any solutions yet.

Wow, there are so many angles to this topic.

Andy, I had read the "native" integration discussion and saw that no decision has been reached yet. Is that right?

Brian, we can write Java or .NET code that uses these generated jar/dlls respectively. Is that right?

We have a current solution to that problem that works today, but yes - nothing was decided from that thread. We're still trying to figure out how to make it easier.

Swaroopch, is your use case having Java code call into Fan libraries? That is actually the flip side of the use case we've been discussing on the forum which is Fan calling into Java and C# libraries. Actually I think your use case is much easier to solve then Fan-to-Java.

The jars generated are just normal classfiles, so you can write Java code which uses those jars. However the current Java runtime still needs the pod files for reflection, so you need both the pods and the jars. We could eventually move that stuff into attributes of the classfile or bundle with the jar if you wanted to use Fan in that way. Then you could deploy Fan as normal jars. The default loading mechanism is also to use a custom classloader, but there are hooks so that it just uses the system classloader if found in the classpath - that should let the Java code link against the Fan code (I haven't used that in a while, so might be rusty). Of course the other issues it that all your Fan APIs are going to use Str, Int, Bool, instead of String, int, and boolean. So it would be nice to generate more Java or C# friendly wrappers.

This is all part of the larger lang interop discussion we need to have. I'm out in Santa Clara at the JVM Summit right now, and I've been getting lots of great ideas talking to other language implementators. I'm planning to write up a summary tonight.

There is "jstub.exe" but no "jstub" shell script.

How do I run "jstub" on UNIX?

This should work:

#!/bin/bash
. "${0%/*}/fanlaunch" 
fanlaunch Jstub "$@"

Thanks, it works. I'm trying to compile a Fan script using GCJ... Here is an interesting error I've got for "echo (DateTime.nowUtc)":

ERROR: Cannot init current timezone
sys::ParseErr: TimeZone not found: MSK-3MSD,M3.5.0,M10.5.0/3
 at fan.sys.ParseErr.<init>(Unknown Source)
 at fan.sys.ParseErr.make(Unknown Source)
 at fan.sys.ParseErr.make(Unknown Source)
 at fan.sys.TimeZone.fromStr(Unknown Source)
 at fan.sys.TimeZone.fromStr(Unknown Source)
 at fan.sys.TimeZone.fromJava(Unknown Source)
 at fan.sys.TimeZone.<clinit>(Unknown Source)
 at java.lang.Class.initializeClass(Unknown Source)
 at fan.sys.DateTime.<clinit>(Unknown Source)
 at java.lang.Class.initializeClass(Unknown Source)
 at fan.sys.DateTime.boot(Unknown Source)

(I think it's an UNIX timezone returned by the GCJ (or the ClassPath)).

Yeah timezones on Unix don't get mapped into the JVM well.

See this issue. I've never seen something that weird!

In the mean-time you can update "lib/sys.props" to set your timezone explicitly

fan.timezone=New_York

Hi,

I'm just getting started with Fantom, after attending the BOF at Devoxx. I've written a little desktop app and would like to run it on a few different machines.

Do I need to convert the pod to a jar? If so, is Jstub still the way to convert a pod to a jar? I can't get the given bash script to work (ClassNotFoundException on Jstub).

Thanks!

Nope, you run directly from the pod:

c:\>fan myPod

See docs for more details.

A little background how Fan code makes its way to bytecode can be found here

Hi mwanji, if I recall correctly you can use BuildJava to converts pod to jar.

c:\>fan myPod That means that users need to install Fantom first? I was hoping to avoid that.

It's not entirely clear to me what the application deployment section is saying. Should I package the runtime distribution myself, bundle the app with it and have the user install that?

Well, yeah, how else would you use Fantom? All you have to do is to download Fantom, extract it to your preffered folder and set up enviroment. Not much different from Java in that respect. See Setup for more details.

Once everything is set then you start enjoying Fantom or use one of the IDE plugins. Currently there is IDEA plugin and a FantomIDE.

BTW don't forget to set your Fantom's directory in the aforementioned IDEs

@DanielFath

I got the impression BuildJava was to compile Java classes within a pod. Which settings/methods would allow you to jar a pod?

That means that users need to install Fantom first?

In order to take advantage of all those juicy features and nice APIs, you will need at least some pieces of the Fantom runtime. There are varying degrees of what can be done for sub-setting the runtime and precompiling Fantom source directly into JVM bytecode, but not a lot of work has been done in that area yet.

Although since it sounds like you've written a FWT app (which in turns uses SWT), it would be difficult to deploy as a simple jar no matter what.

Should I package the runtime distribution myself, bundle the app with it and have the user install that?

If you want to deploy an stand alone app, I would just figure out what pods you need, then create a complete image of bin, lib, and etc using the subset of the stuff you need.

@mwanji: It appears I have made a mistake, my fault. Though I think there should be some thing that compiles everything to jar.

If you want to deploy an stand alone app, I would just figure out what pods you need, then create a complete image of bin, lib, and etc using the subset of the stuff you need.

Thanks, I'll try that. I initially thought I could run Fantom like I could run Groovy or Scala, just by having the jar on the classpath.

@mwanji: It appears I have made a mistake, my fault. Though I think there should be some thing that compiles everything to jar.

Brian seems to be saying that's not really possible.

Is there a topic discussing the possibility of dropping a pod into Tomcat or another Java app server? If that's not possible, it would be a pretty big barrier to adoption, I think.

Brian seems to be saying that's not really possible.

It is possible using jstub. It just isn't documented or well supported yet.

Is there a topic discussing the possibility of dropping a pod into Tomcat or another Java app server? If that's not possible, it would be a pretty big barrier to adoption, I think.

Moving towards this goal is in large part why I just made all those changes to the web APIs - so that we can develop WebMods which can be dropped into existing app servers. Cheeser did some work to run Fantom on GlassFish - see #619.

Although one thing to keep in mind, is that unlike Groovy or Scala, Fantom is much more of an entire platform than just a language. For example Fantom has its own module system, type database, etc configuration mechanisms, an so on. This makes the Fantom runtime more than just a simple jar (assuming you want all those features).