RoboVM 0.0.1 released

[Niklas Therning]

Hi,

Today we have the pleasure to announce the availability of the first
preview release of RoboVM, version 0.0.1!

The announcement can be read on the blog:
http://blog.robovm.org/2013/01/robovm-001-released.html

The download is available from the main web site: http://www.robovm.org

/Niklas

[Mario Zechner]

Can you give more technical details? i.e. what are the limitations, what GC is used, is JNI supported, is this based on VMKit?

[Vasilij Sviridov]

Perfect,

What about publishing to itunes ? 

[Niklas Therning]

On 2013-01-24 10:13, Mario Zechner wrote:
> Can you give more technical details? i.e. what are the limitations, what GC is used, is JNI supported, is this based on VMKit?
>

Hi Mario,

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.

/Niklas

[1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/

[Niklas Therning]

On 2013-01-24 14:50, Vasilij Sviridov wrote:
> Perfect,
>
> What about publishing to itunes ?
>

Hi Vasilij,

If you mean the iOS App Store when you say iTunes then, yes! That's the
primary goal of this project. To make it possible to develop native iOS
apps that can be published to the App Store and run on non jailbroken
iOS devices. It's not there yet though and it will take some time but
one day...

/Niklas

[Philipp Schmid]

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=Debug

Unsupported build type: Debug

Is 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:

[Артём А]

It's really awesome!

I'm writing a desktop app which uses Scala in some places because it provides both a high-level coding and a quite good execution performance. However, Oracle JVM uses too much memory, so RoboVM can be a very good alternative in my case.

понедельник, 21 января 2013 г., 19:50:36 UTC+4 пользователь Niklas Therning написал:

[Mario Zechner]

Hi, comments inline :)

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.

Runtime loading of Java bytecode is less important in our domain, game development. I've been battling non-executable memory pages on iOS with Avian before. It's a real bummer. Glad you fixed that :)

 

2. No JNI through dynamic library loading. Apple doesn't allow iOS apps
in the App Store that include dynamic libraries.

That's what i thought, not a big issue really, linking natives statically is trivial anyways.

 

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

[1] http://libgdx.badlogicgames.com

[Niklas Therning]

Hi Philipp,

Just drop the "--build=Debug" and it should work. I have updated the build instructions in the docs. ./build.sh without any args will build release and debug versions of all libs for all platforms. If you just want to build for a particular platform you can do that. E.g.:

  ./build.sh --target=ios-x86 --build=release

will build a release build for ios-x86. The supported targets are linux-x86, macosx-x86, ios-x86, ios-thumbv7. The supported build types are release and debug.

If you want to link against the debug libs rather than the release libs you can supply the -use-debug-libs arg to the robovm compiler. The debug libs have to be copied from vm/target/binaries/ to /opt/robovm/lib/vm/ first.

We haven't done much yet to optimize the executable's file size. Stripping the executable from debug info will bring it down to less than 10 MB. The RoboVM compiler only does unoptimized debug builds at the moment. A release build in the future will turn on LLVM optimizations and utilize LLVM's link-time-optimizations which will bring down file sizes. But a RoboVM app will always be larger than the equivalent Objective-C app since we need to link in a lot of the core classes in the executable. For Objective-C apps the core classes are included in iOS.

Regarding your Objective-C questions. Calling Java from Objective-C is not what we're trying to achieve I'm afraid. It is certainly doable using JNI and in theory you should be able to embed RoboVM compiled code and the RoboVM core in your Objective-C app but it won't be easy. There's another project out there called J2ObjC [1] that does pretty much what you want and IIUC makes it easy to mix Java and Objective-C code in the same Xcode project.

/Niklas

[1] http://code.google.com/p/j2objc/

--
 
 

[Niklas Therning]

On 2013-01-25 09:00, Mario Zechner wrote:

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.

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.

 

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.

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.

 

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

[1] http://libgdx.badlogicgames.com

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! :-)

/Niklas

[Mario Zechner]

On Friday, January 25, 2013 1:13:21 PM UTC+1, Niklas Therning wrote:

<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.

Awesome! I'll give this a try on the desktop, need to recompile our shared libs to static libs, not a big deal, It seems the "VM" core is pretty slick and easy to manipulate, a good thing should i need to add some things :)

 

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.

I went that route as well in a project called Jack [2]. Instead of LLVM, i output C++. It's nowhere near as complete as yours, but i only played with it for a few weekends. Good thing is that i know Soot as well now, so maybe i can help on that side a little should the need arise.

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! :-)

Yes, the files you see in the backend(s) are really all that needs to be ported. It's basically an abstraction over window creation/managment, input, file i/o, audio, graphics and networking. Based on that the rest of the lib is implemented in a platform independent manner. MonoTouch has quite a few utility classes that make creating the window and adding a GL context easier, so for RoboVM i'd have to dive deeper into iOS. Shouldn't be a big deal :)

I saw in the commit history that you've been working on RoboVM since 2010. If you find the time, could you give a bit of insight into what made you work on it?

Mario