For me the most interesting thing here is the rejection of direct compilation to native code via LLVM. This team has concluded that the safest and most practical way to target Apple's platform is using one of Apple's compilers (in this case, clang).
I'm not sure if I agree with that conclusion. After all, RubyMotion and the Elements Compiler (www.elementscompiler.com) have kept up with all the new compiler requirements from Apple, including the requirement to emit bitcode for watchOS and tvOS. So clearly it's possible. And using LLVM directly, rather than using C as an intermediate representation, yields more control over debug information. Still, it's possible that at the next WWDC, or even next September, Apple will drop something new that will force us to use one of their compilers.
Possible != Easy. There are quite a lot of guys who took that path and its totally possible. Unfortunately a great example of what can go wrong is now available with RoboVM, this turned out to be such a huge effort to maintain that they literally closed their source.
Now the OSS community is trying to fork the code and because the code is so complex its really hard to do that.
Even if Codename One goes belly up or is acquired by a closed source company in the future you will probably be able to still work with the code without a problem.
There are a couple of other advantages with this approach:
1. Use the native tooling (e.g. profilers etc.) which are pretty amazing on iOS.
2. Just write Objective-C/SWIFT code for various features. This is hugely convenient when adopting features from the latest version of iOS.
Neither do I. Compiling to LLVM IR will enable Apple's tooling to generate correct binaries for the platform (actually nowadays Apple will do it for you through the use of LLVM bitcode for App Store submissions). There's still an issue of using the correct iOS APIs for the job, but that issue is certainly also there when compiling to C code.
Neither do I agree with the statements about C code being "easier to use"; it is still generated code and it will most likely not be the nicest code to work with.
You can open it in a debugger. C is something pretty much every developer knows and has a ton of documentation. LLVM is nicely documented but not exactly in that league. Its more like working with Java bytecode, possible not trivial.
E.g. if you have a bug in the LLVM translation code, good luck tracking that... With ParparVM just open it in the debugger and see what went wrong.
Look at the referenced quote in the readme from a guy actually going thru the LLVM path (CEO of RoboVM). Its theoretically easy but in all practicality its pretty far from easy and you have no way of knowing what Apple will do with LLVM in the future. But they pretty much guaranteed they will support C as its an officially supported language.
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... )
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.
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.
I'm confused. I don't think this is a JVM - it doesn't load and exectute byte-code at runtime. So is it a cross-compiler to C with a runtime that manages GC?
Its an AOT compiler which does qualify as a JVM of sort. It takes Java bytecode and allows you to run it which is really the main "concept" of the JVM. It includes a GC and the basic semantics of the Java language (e.g. like GWT).
I'm not sure if I agree with that conclusion. After all, RubyMotion and the Elements Compiler (www.elementscompiler.com) have kept up with all the new compiler requirements from Apple, including the requirement to emit bitcode for watchOS and tvOS. So clearly it's possible. And using LLVM directly, rather than using C as an intermediate representation, yields more control over debug information. Still, it's possible that at the next WWDC, or even next September, Apple will drop something new that will force us to use one of their compilers.