One of the core contributors here. The trick is that Avian doesn't do JIT compilation on iOS - instead, we run everything through the "JIT" compiler ahead of time, as we're building the app. This is the only possible technique, outside of interpretation (which Avian can also do, but slowly), and compiling to Javascript to run with JavascriptCore. It's also what I've seen most other VMs do for iOS (including, for instance, the Unity game engine, which used to embed Mono).
One of the core contributors here. I don't have any numbers, but I can reasonably guess it'll only beat the most naive JITs (i.e., JITs that only copy predefined templates that implement each instruction). Avian's JIT does no optimizations beyond a simple linear-time register allocator and a very basic instruction selector. Avian can run a simple Hello World somewhat faster than HotSpot, but that's about all. In any real-world scenarios, HotSpot and Dalvik/ART will kick the pants off it.
However, that's not what Avian is designed for. We (ReadyTalk) don't have the resources to compete in that sort of market, as fun as that might be. We designed Avian to run a relatively light-weight client application, so we can deploy the same code across all our platforms. We're not running a game or a server, so we don't care a lot frame rate or requests per second.
> However, that's not what Avian is designed for. We (ReadyTalk) don't have the resources to compete in that sort of market, as fun as that might be. We designed Avian to run a relatively light-weight client application, so we can deploy the same code across all our platforms. We're not running a game or a server, so we don't care a lot frame rate or requests per second.
I still don't see how it's better than Java in that scenario, which also runs on all platforms?
It really stems from the need to deliver commercial software to enterprise customers on a variety of platforms. At least some (if not many) enterprise customers don't want to roll out Java across all of their clients machines. Additionally, not all enterprise customers have the privileges required to install Java themselves. The bundling of the application into a single executable file is advantageous in this scenario.
I don't understand what this is for. Could someone suggest some use cases?
Is the idea that you can write an app in a language which is a subset of Java, then deploy it onto multiple different platforms? Given that you can already do that with actual Java, what's the advantage? Is it just that you can deploy on iOS, where there's no JVM?
In general, one of the challenges of delivering commercial software is dealing with the various ecosystems of your customers. Customers may have different versions of Java installed or none at all. Avian allows one to bundle everything required to run a Java application into a single executable and simplifies the problem such that many of the unknowns related to delivering the Java application disappear.
Also, keep in mind that Avian predates at least some of the other solutions to this problem. You could use something like https://github.com/libgdx/packr as well.
Is it possible for Avian to support the java.awt.Robot class? (http://docs.oracle.com/javase/6/docs/api/java/awt/Robot.html)
Would be superb in terms of cross platform automation use, currently the only other cross OS compatible solutions are to use Lazarus/Free Pascal or full blown Java VM.
You can use Avian with the OpenJDK class library to produce a standalone executable, in which case java.awt.Robot should work. ProGuard could help to keep the size down.
It would also be possible to implement java.awt.Robot from scratch and add it to Avian's class library. That would give you a smaller executable but require significant effort and a lot of platform-specific code.
The best choice depends on what aspect(s) of a "full blown Java VM" you're trying to avoid: e.g. size, installation complexity, licensing issues, etc.
BSD license as opposed to commercial pay-only license key required for building in RoboVM. It's a pretty clear choice for anybody wanting to use this well into the future..
Technically we don't support running the Avian VM on Android, although it should work with minimal porting. However, we support using the VM with any of three class libraries: Android's, OpenJDK's, or Avian's. So, ironically, you can use Android's class library with Avian on every platform you listed except Android :)
If there's interest in porting Avian on Android, we could do it, but since it already has Dalvik/ART, I'm not sure there's much of a point.
Specifically, it supports native first class continuations, including both call/cc-style and delimited (shift/reset-style), which can form the basis for coroutines, generators, and other fun stuff. It also supports full tail call optimization.
As dkharrat pointed out, you can use the Avian VM with the OpenJDK class library instead of the much more limited default library. However, there's no support for JVMTI, and not everything in the OpenJDK library will work with every combination of platforms and build options.
To be fair, I can't really tell from the website what this is and why I would want it ("doesn't Android already have a JVM?"), and Kotlin could easily be defined as "a lightweight alternative to Java that runs on Android" as well!
