JRuby on Android - getting a VerifyError thrown

I’m experimenting with JRuby on Android. Unfortunately, Android
doesn’t have java.lang.mangement - is there any way around that?

I’m getting a VerifyError thrown when Android’s classloader tries to
pull in org.jruby.manager.BeanManager - the exception is thrown at
line 209 of Ruby.java (from trunk):

    this.beanManager        = new BeanManager(this,

config.isManagementEnabled());

And this from the android log:

VFY: unable to resolve static method 1349:
Ljava/lang/management/ManagementFactory;.getPlatformMBeanServer
()Ljavax/management/MBeanServer;

Using trunk jruby - 1.1.4 doesn’t load in Android.


James M. | [email protected]
Ruby and Ruby on Rails consulting
blog.restphone.com


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Try running with JMX disabled:
jruby -J-Djruby.management.enabled=false

Or, if you are programatically running JRuby instances, you could try to
set
this System property yourself.

On Tue, Oct 7, 2008 at 2:05 PM, James M. [email protected]
wrote:

And this from the android log:
blog.restphone.com


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Fabio K.

Caelum - Ensino e Inovação
http://www.caelum.com.br

Yeah, I’d expect we need a more “servicey” way of loading these things
that can fail gracefully if e.h. javax.management isn’t present. And I
would wager that’s an approach we’d need in several places to support
platforms like Android.

Look at how the LazyLoading service thingy (search for “lazy” in
Ruby.java") does stuff; something similar for JRuby-level services would
probably be appropriate.

James M. wrote:


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Thanks - I’ll give it a shot, but I think I have to change some code,
not just the setting. register() and unregister() need to be moved
out of BeanManager, since BeanManager itself won’t even load.

On Tue, Oct 7, 2008 at 10:57 AM, Fabio K. [email protected]
wrote:

Try running with JMX disabled:
jruby -J-Djruby.management.enabled=false
Or, if you are programatically running JRuby instances, you could try to set
this System property yourself.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Hey Guys,

I’m a rubyist, and java neophyte (but i’ve been following the jvms
development for a while). Anyway, i’ve been googling for information
regarding android, jruby, and javaMe to try and get a better lay of
the land before i figure out how to get into things deeper (i’m a top
down sorta guy). I found a blog post by John Rose back from May (
http://blogs.sun.com/jrose/entry/with_android_and_dalvik_at ) about
the dalvik vm ( Dalvik (software) - Wikipedia ),
which makes the following claim:

  1. Something like the dx tool can be forced into the phone, so that
    Java code could in principle continue to generate bytecodes, yet have
    them be translated into a VM-runnable form. But, at present, Java code
    cannot be generated on the fly. This means Dalvik cannot run dynamic
    languages (JRuby, Jython, Groovy). Yet. (Perhaps the dex format needs
    a detuned variant which can be easily generated from bytecodes.)

I don’t have either the contacts or sufficient background to really
know what the real implication of this is, or to what degree things
have changed internal to android (or could change). Anyone better
informed and/or connected, who would want to take a stab at addressing
this?

-T

On Tue, Oct 7, 2008 at 5:59 PM, Charles Oliver N.
[email protected] wrote:

this System property yourself.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

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.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

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.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Has anyone actually gotten pure compiled or pure interpreted JRuby
working on Android yet? Or, if I wanted to try to get this working,
what might I need to do?

remi Taylor wrote in post #751346:

Has anyone actually gotten pure compiled or pure interpreted JRuby
working on Android yet? Or, if I wanted to try to get this working,
what might I need to do?

This is an old thread, but if anyone stumbles into it:

Check out

http://ruboto.org/

That’s a working JRuby on Android!

On Mon, Jul 25, 2011 at 8:26 PM, Uwe K. [email protected]
wrote:

That’s a working JRuby on Android!

You can also get it for SL4A (
Google Code Archive - Long-term storage for Google Code Project Hosting. ). I’d be interested if
anyone knows the differences between JRuby in the two environments.