Is a Mac needed in order to compile?
For now you'll need Xcode to use RoboVM which implies Mac OS X running on Mac hardware or in a VM (it can be done although Apple doesn't allow it unless you run the VM on Mac hardware).
RoboVM: Native iOS apps in Java
41–50 of 64 posts
Re: RoboVM: Native iOS apps in Java
#42Earlier quoted context omitted.
Theos [0] has been used with Linux before but I have never personally done so. I don't think anybody has yet ported ld64/codesign to run natively on Linux but it has been possible for some time to run the Mac CLI dev tools under Linux using runtime shims like maloader [1] or its descendant Darling [2]. [0]: https://github.com/DHowett/theos [1]: https://github.com/shinh/maloader [2]: http://www.darlinghq.org/
is it possible to run this on windows 7?
maloader and Darling won't, they require Linux. LLVM works fine on Windows. I'm guessing the RoboVM front-end is also fairly portable. The effort to port ld64/codesign to Windows would probably be similar to the effort to port them to Linux.
Re: RoboVM: Native iOS apps in Java
#43There goes the neighborhood.
Kidding.. anyone know how this compares to Titanium? E.g. performance, energy efficiency, debuggability, etc.? http://www.appcelerator.com/titanium/
Re: RoboVM: Native iOS apps in Java
#44 Print the CLA, sign it and scan it (or use a camera to photograph it) and e-mail it to hello(at)robovm.com. Include your GitHub user name in the e-mail.
Re: RoboVM: Native iOS apps in Java
#45Print the CLA, sign it and scan it (or use a camera to photograph it) and e-mail it to hello(at)robovm.com. Include your GitHub user name in the e-mail. print & scan in 21st century...really?
A bit wacky indeed. For what it's worth when dealing with this stuff I use Apple's Preview App's signature feature. It's pretty neat. You take a photo of your signature with your webcam and place/resize it as necessary. I create a new signature each time (paranoia) but if you have to do this a lot you can have Preview save it for later.
Re: RoboVM: Native iOS apps in Java
#46I've successfully used RoboVM to ship native linux binaries from jvm bytecode, in addition to the headlining cross-platform-mobile features. It's fantastic. It worked pretty much out-of-box with a few commands from the Getting Started page.
And as for performance: startup time is impressive: an order of magnitude faster than launching a jar in the jvm, such that you can actually use it in the middle of other shell scripts without blinking. Once it's been running for a while, it's hard to beat the kind of optimizations a JIT compiler can do, but RoboVM is still approximately as fast as java (I think the mailing list handwaves this to about 2x slower; still a couple hundred times faster than most interpreted languages, so I'm pretty okay with this).
RoboVM uses the Boehm GC, which is mature, effective, and (of critical note to me) a heap-compacting garbage collector... which means you can confidently use it even for applications with days or months of contiguous uptime.
I've thrown wicked strange bytecode at RoboVM. It copes fine; I was impressed. (After some time working in golang gave me a great appreciation for the semantic style of goroutines, I've been trying to bring them everywhere. I made some custom bytecode with code derived from the Apache JavaFlow library to try to break RoboVM, and it didn't even blink; I'm now using it with http://paralleluniverse.co/quasar/ very happily.)
And did I mention how pleasant it is to ship statically linked native executables?
Re: RoboVM: Native iOS apps in Java
#47Java experts: would this make Clojure a potentially valid development option now for iOS?
It says that it takes Java byte code and translates it to native ARM or x86 code. Since Closure is a JVM language, then yes, it would be possible to do so. I'm worried Scala would get implemented first, though. :)
Scala already works as-is. I'm sure clojure does as well.
Re: RoboVM: Native iOS apps in Java
#48Doesn't Apple's ToS prohibit writing apps in any language other than Objective-C? Or using other than Apple's tools?
It used to. They changed it, fortunately.
Re: RoboVM: Native iOS apps in Java
#49Earlier quoted context omitted.
No. They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable). They also (generally) prohibit interpreters that download code from the network and execute it. If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently). They just want to make sure that the executable code that sh…
Yep. These are the relevant lines from the policy: 2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected And I suppose this covers use of W^X / mprotect: 2.5 Apps that use non-public APIs will be rejected
mprotect() simply returns EPERM. The kernel enforces W^X; once a page has gone writable, it can never be executable, and vis versa.
Re: RoboVM: Native iOS apps in Java
#50I've successfully used RoboVM to ship native linux binaries from jvm bytecode, in addition to the headlining cross-platform-mobile features. It's fantastic. It worked pretty much out-of-box with a few commands from the Getting Started page. And as for performance: startup time is impressive: an order of magnitude faster than launching a jar in the jvm, such that you can actually use it in the middle of other shell sc…
I'm pretty sure the Boehm GC isn't heap compacting.
It at least didn't used to be, and if it is it works in some way I cannot fathom, as I'm not sure how you can compact the heap without changing the value of pointers, which the Boehm GC cannot do safely.
That said it's still a very good GC and you should be fine. (It does try to minimize fragmentation in other ways, but nothing is as effective as heap compacting.)