I’m so glad to have found this thread. I’m a professional rubyist too
and I’ve been searching for solutions to running dynamic JVM languages
on Dalvik, specifically JRuby.
(I’m starting an Android Developer’s group in my city, Phoenix, and
there’s lots of local interest in Ruby Android development, if it’s
possible.)
I hope someone posts back if they get something working! I’ll post
back, if I do.
Does anyone know if there’s any development underway to allow for
run-time bytecode generation / compilation and whatnot on Dalvik? If
Dalvik were modified to support this (if it’s even possible), I’m
certain the memory usage would go up … but, without things like
on-the-fly method handling, you lose a big benefit of Ruby: DSL
creation. Ruby is an ideal language for creating DSLs for Android
development, in my opinion, specifically because of some of its
dynamicness. That said … you could still make some pretty nice DSLs
with Ruby, without on-the-fly invoker/compilaiton.
Anyway, incase it helps anyone … here are some other threads where
I’ve been trying to document JRuby+Android, as well as running dynamic
JVM languages on Dalvik, in general:
“Status of Jython, JRuby, Scala, etc Android development?”:
http://groups.google.com/group/android-beginners/browse_thread/thread/59350a39960c6b28/8363e867741eba2a
“Java/Ruby Support”:
http://groups.google.com/group/phoenix-android/browse_thread/thread/6e254dcdf738f5df
Charles Oliver N. wrote:
Ted H. wrote:
informed and/or connected, who would want to take a stab at addressing
this?
The real implication here is simply that anything in JRuby that depends
on generating bytecode would have to be ripped out. This includes:
- on-the-fly compilation
- on-the-fly method handle (invoker) generation
- Java subclassing (and potentially interface impl via …reflect.Proxy)
That’s not so bad is it? There’s two possible execution scenarios that
would work with these limitations:
- Pure interpreted, where all code gets parsed on the device and
executed with our AST-walking interpreter logic. This would probably be
slower than we’d like, but easy to make work.
- Pure compiled, with all invokers/handles generated ahead-of-time as
well.
Both cases are already possible in the current codebase; the only trick
would be producing a deliverable .jar that provides only the one and has
no dependencies on the other.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email