5

CodenameOne supports compiling Java code down to native iOS binaries. Does it support other JVM based languages such as Clojure or Jruby ?

Ivar
  • 5,102
  • 2
  • 31
  • 43
  • 1
    Hm, from the link you give: "[..] translates Java bytecode to C code." I'd assume that they mean *JVM bytecode*, which in turn would mean it supports all languages that compile to bytecode. Though I'm unsure about how things like runtime compilation (clojure) would be handled. Since it's open source: Why don't you just try? (Note: I have absolutely no experience regarding codenameOne) – Daniel Jour Dec 29 '15 at 01:39
  • 1
    Ivar, @DanielJour, it's not hard to pre-compile Clojure, e.g. using Leiningen's `uberjar` parameter along with an `:aot` option in a Leiningen project.clj file. However, after *very quickly* glancing at the linked page and some others, I would be surprised if using a lot of idiomatic Clojure code with CodenameOne was easy. It might be that if you use Clojure's Java interop features to generate Java classes, it would work fairly easily (although fully using Clojure's Java interop isn't always easy). – Mars Dec 29 '15 at 03:31
  • @Mars I know, I was more thinking about interactive development in the REPL. From the answer below I'd guess this would be very hard to achieve (see `*warn-on-reflection*`) – Daniel Jour Dec 29 '15 at 06:58
  • For REPL you could write code that avoids reflection while providing similar functionality with a known "fixed" subset of the REPL. E.g. if language X supports function calls A, B & C you can have a big string switch case that invokes A, B & C (etc.). This particular piece of code can be generated dynamically as part of your build process. Notice that its also possible to change the VM itself to support reflection & if a good patch like that exists we'll probably accept it. It should be reasonably easy to add. – Shai Almog Dec 30 '15 at 03:45

1 Answers1

4

Not out of the box but its indeed possible. In the past Steve ported Mirah which is a Ruby subset to run on Codename One. This was when we were using the old VM but should work with the new VM too.

A community member was also able to port Haxe a while back but I'm unsure where that ended.

The main point of contention when porting a JVM language is that Codename One doesn't support reflection and so a duck typed language implementation that generates reflective code would be "problematic".

The reason for avoiding reflection is quite simple, the code size would grow tremendously effectively negating a lot of the advantages of the smaller handcoded VM. Its also quite hard to optimize reflection code in an AOT environment so it will perform badly when compared with a JIT.

A lot of the usage of reflection can be replaced with bytecode manipulation ahead of time so the VM can work as if its standard Java code even when it isn't.

We generally like the idea of running other languages on top of Codename One and would like to help if you run into issues. The main reason we don't invest time in these things ourselves is to keep our focus in place.

Shai Almog
  • 51,749
  • 5
  • 35
  • 65