4 ms·

ParparVM – Open Source JVM for iOS

74 points by danr4 11y ago

ivarv 11y ago
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-codenameone-to-compile-other-jvm-based-languages-to-ios http://stackoverflow.com/questions/34502625/can-i-use-codena... )
- adrianm 11y ago
  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.)
- badlogic 11y ago
  https://robovm.com 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.
  - invalidname 11y ago
    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 ;-)
mwcampbell 11y ago
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.
- marktangotango 11y ago
  There's a quote in the readme.md concerning robovm and difficulty migrating to ios9, FYI.
- invalidname 11y ago
  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.
  - frik 11y ago
    related HN topic "RoboVM Is No Longer Open-Source": https://news.ycombinator.com/item?id=10498635 https://news.ycombinator.com/item?id=10498635
- praseodym 11y ago
dmcg 11y ago
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?
- invalidname 11y ago
  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).

74 points by danr4 11y ago

ivarv 11y ago

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-codenameone-to-compile-other-jvm-based-languages-to-ios http://stackoverflow.com/questions/34502625/can-i-use-codena... )

adrianm 11y ago
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.)
badlogic 11y ago
https://robovm.com 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.
- invalidname 11y ago
  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 ;-)

mwcampbell 11y ago

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.

marktangotango 11y ago
There's a quote in the readme.md concerning robovm and difficulty migrating to ios9, FYI.
invalidname 11y ago
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.
- frik 11y ago
  related HN topic "RoboVM Is No Longer Open-Source": https://news.ycombinator.com/item?id=10498635 https://news.ycombinator.com/item?id=10498635
praseodym 11y ago

dmcg 11y ago

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?

invalidname 11y ago
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).