Hacker News Reader

Comment by ivarv | Hacker News Reader

This looks very promising and could be huge if it supported JVM languages besides Java. I've been digging through the docs and have yet to find anything to this end. (Going so far as to post a SO question about it at http://stackoverflow.com/questions/34502625/can-i-use-codena... )

View on HN

The compiler processes byte-code as input, not Java source code. Therefore any language which can emit JVM byte-code ahead-of-time (AOT) should theoretically work.

Clojure, for example, permits AOT byte-code delivery of your project. So with a AOT compiled clojure.main jar on the class path, Clojure should theoretically work if you could interpret the byte-code at runtime as a fallback. In the absence of an interpreter, Clojure should also work if you do not rely on `eval` or any other functions which depend on the byte-code compiler at runtime.

This of course assumes their compilation model is compliant with whatever version of the JVM specification the Clojure compiler targets. IIRC it should be compatible back to Java 6, so Clojure might not work without some tweaks to this project's compiler.

(Disclaimer: I am not involved with the project.)

https://robovm.com supports Java, Scala, Kotlin and Clojure on iOS, with apps on the app store. PaparVM has J2ME class library support only, so it's going to be tough to get anything big running. RoboVM is based on Android's runtime class library.

That's not true. ParparVM supports a subset of Java 8 not J2ME class libraries.

True that RoboVM does carry over a lot of Android's bloat and quite a few cross platform bugs and broken implementations. E.g. SQLite thread safety, broken java.net stack etc.

Oh and its also closed source now ;-)

Reply on news.ycombinator.com