For various reasons, I'm not needing a new language right now BUT I do need some cross platform libraries...

If the idea of repurposing the (native parts of) Fantom's standard library for use as a general purpose, common api under java, cs and js code is heresy -just tell me and we can pretend I never asked :-)

OR -is this a less-common but not unheard of use case?

OR -is it just not going to work out?

My assumptions (please correct me where I am wrong)

1. I could only expect to use the native code -because Fantom (in its present form) doesn't support writing libraries to be consumed by non Fantom code.
2. sys -is pure native (and inet? and concurrent?)
3. .Net remains an "advanced prototype" (or am I way out of date here??) -so the native cs code, while well tested is not well used.

Happy to answer the inevitable question: "but why not just use Fantom?" -but I fear THAR BE BIKE-SHEDS...

Any comments appreciated.

Works, pretty easy; just import the Fantom sys.jar and arrange to initialize it on startup (see the JarDist build script for an example of that).

I usually end up not doing that, though, because it means the Fantom runtime environment ({fandir}/etc and {fandir}/lib mainly) need to come along. Using Fantom this way from Java, gives you smoother and more sensible standard libraries; but you still have to deal with interop with whatever other code you're using.

The difficulty (for using (parts of) Fantom as a static library) is that the whole system is built around dynamic loading from pod files, with lazy-load reflection structures and runtime emitting of java bytecode translated from fcode; so you end up needing to either include the whole standard startup system, or you'd have to do some fairly extensive refactoring.

There is definitely a very valuable set of code that provides standardized functionality across different platforms. For example the sys codebase contains a very nice set of I/O and DateTime APIs that will work identically across .NET, Java, and JavaScript. The current code is definitely not packaged to use those APIs as simple libraries. It would take some rework to pull the code out depending on how you wanted to use it.

And as you move up the stack to libraries implemented in Fantom, much of that code assumes a complete Fantom runtime (although it really varies on pod to pod).

so you end up needing to either include the whole standard startup system, or you'd have to do some fairly extensive refactoring.

Having a fantom program encapsulated in a jar is quite useful even if you had to include and AOT-compile everything. JarDist does the job for smaller programs but it's not really usable for more complex things because of its limitations - missing methods like JarDistEnv.findFile.

Pulling the standard library out might be a very nice thing. It could help to clear rough edges around Env providers where key things are hardcoded in the codebase.