As part of the pluggable Env rework, I've added a nice feature to bundle up a set of Fantom pods into a single JAR for distribution.
I haven't done a lot of testing, but I was able to package up sys, compiler, and fansh into a single "fansh.jar" and run it completely stand alone with a command line such as:
java -jar fansh.jar
Reflection is fully enabled (both the classfiles and fcode are packaged up into the JAR). There is definitely room for optimization to strip out the method bodies in fcode for better compression. The type database is not available.
Right now the biggest problem is DateTime and TimeZone since I don't really want to include the full timezone database in the JAR. It is 33KB and I use random access to lazily load timezone definitions. The Java timezone API doesn't actually give you access to the DST start/end. So I'm not sure how to handle that yet.
The new build::JarDist task is used to build a JAR from a set of pod names. I stubbed out an example script in "examples/java/buildjardist.fan":
All Env directories (home, work, temp) just default to current directory, and none of the etc file overrides will work in the JarDistEnv. The type database is not available either.
But everything else should work pretty well. Using fansh is a good stress test because it requires full support of the compiler and emitting bytecode at runtime.
The overhead for a basic hello world Fantom JAR is ~550KB, most all of that is the Java bytecode from "sys.jar". Personally I think that is pretty good considering all the crunchy goodness you get including non-sucky I/O and Date/Time APIs and an Actor library. Just something like Apache lang commons is ~250KB.
brian Mon 1 Feb 2010
As part of the pluggable Env rework, I've added a nice feature to bundle up a set of Fantom pods into a single JAR for distribution.
I haven't done a lot of testing, but I was able to package up sys, compiler, and fansh into a single "fansh.jar" and run it completely stand alone with a command line such as:
Reflection is fully enabled (both the classfiles and fcode are packaged up into the JAR). There is definitely room for optimization to strip out the method bodies in fcode for better compression. The type database is not available.
Right now the biggest problem is DateTime and TimeZone since I don't really want to include the full timezone database in the JAR. It is 33KB and I use random access to lazily load timezone definitions. The Java timezone API doesn't actually give you access to the DST start/end. So I'm not sure how to handle that yet.
The new
build::JarDist
task is used to build a JAR from a set of pod names. I stubbed out an example script in "examples/java/buildjardist.fan":I'm probably doing a new build tomorrow with all the new Env changes (I would discourage anybody working from hg tip right).
qualidafial Tue 2 Feb 2010
Sweet!
tompalmer Tue 2 Feb 2010
Very nice. How big is fansh.jar at the moment?
brian Tue 2 Feb 2010
Promoted to ticket #952 and assigned to brian
brian Tue 2 Feb 2010
Ticket resolved in 1.0.50
OK, I think this feature is actually ready for people to try out. Probably has some rough spots we'll iron out over time.
The JarDist build task now includes key sys configuration files:
sys::MimeType.forExt
will worksys::DateTime
andsys::TimeZone
functionality is availablesys::Unit
is fully functionalAll Env directories (home, work, temp) just default to current directory, and none of the etc file overrides will work in the JarDistEnv. The type database is not available either.
But everything else should work pretty well. Using
fansh
is a good stress test because it requires full support of the compiler and emitting bytecode at runtime.The overhead for a basic hello world Fantom JAR is ~550KB, most all of that is the Java bytecode from "sys.jar". Personally I think that is pretty good considering all the crunchy goodness you get including non-sucky I/O and Date/Time APIs and an Actor library. Just something like Apache lang commons is ~250KB.