Very nice!I just ran the IOSDemo.java the simulator :-)The build instructions seem not to work on Mac OS X:charlie:External_Software schmidp$ cd robovm/vm/charlie:vm schmidp(master)$ ./build.sh --build=DebugUnsupported build type: DebugIs it possible to call Java code from Objective-C?What I would love to see is a blog post about how to take an existing Objective-C App, "convert" it into a RoboVM project, add an example Java class and call the added Java code from Objective-C and visa versa.By "convert" I mean the project setup and not converting Objective-C code to Java.My intention behind this request is, that it would be a nice start on migrating existing projects to a common code base.For example I would very much like to take a few of our existing iOS/Android projects and replace the Objective-C models and business code with Java so that both, the iOS and the Android project use the same model code base.This would already be a huge step for us (we are a typical app development shop) as it would require much less communication between our iOS and Android developers :-)Currently the IOSDemo app is about 26MB after being installed in the simulator. Any chance on getting the file size down?But maybe it's just the debug build, I haven't played around that much yet.All the best, Philipp
On Monday, January 21, 2013 4:50:36 PM UTC+1, Niklas Therning wrote:
Limitations:
1. RoboVM can not and never will be able to load Java bytecode
dynamically. Bytecode is compiled ahead-of-time into machine code and
linked into a single binary. So you could say that RoboVM isn't really a
virtual machine since it doesn't interpret bytecode. This is by design
since non jailbroken iOS devices wouldn't allow JITted code to be run
(memory pages cannot be made executable in iOS). Since bytecode cannot
be loaded dynamically there are never more than two classloaders in a
RoboVM app, the boot classloader and user classloader.
2. No JNI through dynamic library loading. Apple doesn't allow iOS apps
in the App Store that include dynamic libraries.
JNI:
Yes, RoboVM implements JNI but on iOS the JNI library code has to be
statically linked into the executable. Statically linked JNI code in
user classes hasn't actually been implemented yet but it should be
trivial since it has already been done for the core classes. We've
implemented as much of the JNI API as have been needed so far. If you
want to know exactly how much please see the JNI API implementation in
vm/core/src/native.c.
GC:
RoboVM uses the Boehm-Demers-Weiser [1] as used by many other projects.
The stack, static data areas and data structures used by the vm code are
scanned conservatively while Java objects are precisely GCed.
RoboVM is not based on VMKit but we do use LLVM for the machine code
generation.
Are you working on something that you would consider using RoboVM for?
Please let me know the details and I will try to tell you whether RoboVM
will fit your needs in the future once it matures.
--
Hi, comments inline :)
<snip/>
JNI:
Yes, RoboVM implements JNI but on iOS the JNI library code has to be
statically linked into the executable. Statically linked JNI code in
user classes hasn't actually been implemented yet but it should be
trivial since it has already been done for the core classes. We've
implemented as much of the JNI API as have been needed so far. If you
want to know exactly how much please see the JNI API implementation in
vm/core/src/native.c.
Thanks for the pointer. We are usually really only interested in direct ByteBuffer access as well as critical array locking (so no copy is created). Judging by native.c you cover pretty much everything that's relevant when using JNI. Could you elaborate on what is needed to allove JNI for user classes? I could maybe send a pull request, a bit of direction would save me some time.
GC:
RoboVM uses the Boehm-Demers-Weiser [1] as used by many other projects.
The stack, static data areas and data structures used by the vm code are
scanned conservatively while Java objects are precisely GCed.
I guess integrating boehm works. Introducing a copying GC will probably a bit of work as currently objects are directly passed around by pointer, much like in (older) Dalvik.
RoboVM is not based on VMKit but we do use LLVM for the machine code
generation.
Are you working on something that you would consider using RoboVM for?
Please let me know the details and I will try to tell you whether RoboVM
will fit your needs in the future once it matures.
I'm the creator of libgdx [1], a popular cross-platform (win/mac/lin/android/html5/ios) game development framework, with the public API being in Java. We've had quite a ride getting our iOS backend going via IKVM and MonoTouch. It works great, but we'd like to provide a a backend that does not require a costly license. Also, the prospect of an LLVM based backend means that this thing could actually fly given all the free optimizations you get from LLVM. Finally, it looks comparatively easy to port to new/other platforms, especially consoles.
You could have a real winner here, as RoboVM might not only open up these platforms to Java folks, but any JVM language really.
Thanks for all the hard work and publishing it under such a permissive license! If there are things i can help with, i'll gladly fork and send pull requests your way. However, my time is rather limited, so if you can directly point me at tasks, i could save quite a bit of it.
ciao,Mario
<snip>
The unimplemented JNI functions dealing with ByteBuffers in native.c have now been implemented and . And I've just checked in code that fixes the JNI for user classes problem:
https://github.com/robovm/robovm/commit/c69a46fa490ab2c4b7ccd7b15cd7dde12f7cbd05.
Just point out the .a or .o files you want to link against using the -static-libs command line option.
The boehm GC is very easy to use and integrate. If it turns out it doesn't perform acceptably we will have to do something about that.
It would be amazing to have a RoboVM based libgdx backend! If you or someone in your community would like to try that I will help out in any way I can. Judging from the current MonoTouch based backend (after a very quick look) it doesn't seem very complicated, right? Is that the only platform dependent code or would other things have to be ported specifically for RoboVM? Issues in RoboVM will probably pop up all over the place so there will be plenty of opportunity to contribute to RoboVM! :-)