Forum: JRuby JRuby on Android - getting a VerifyError thrown

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
James M. (Guest)
on 2008-10-07 21:06
(Received via mailing list)
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. | removed_email_address@domain.invalid
Ruby and Ruby on Rails consulting
blog.restphone.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Fabio K. (Guest)
on 2008-10-07 21:58
(Received via mailing list)
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. <removed_email_address@domain.invalid>
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.
http://www.fabiokung.com

Caelum - Ensino e Inovação
http://www.caelum.com.br
James M. (Guest)
on 2008-10-07 22:21
(Received via mailing list)
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. <removed_email_address@domain.invalid>
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
Charles Oliver N. (Guest)
on 2008-10-08 02:00
(Received via mailing list)
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
Ted H. (Guest)
on 2008-10-09 06:54
(Received via mailing list)
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 ( http://en.wikipedia.org/wiki/Dalvik_virtual_machine ),
which makes the following claim:

7) 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.
<removed_email_address@domain.invalid> 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
Charles Oliver N. (Guest)
on 2008-10-10 10:04
(Received via mailing list)
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
remi T. (Guest)
on 2008-11-11 00:59
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/b...

"Java/Ruby Support":
http://groups.google.com/group/phoenix-android/bro...

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
remi T. (Guest)
on 2008-11-20 20:19
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?
Uwe K. (Guest)
on 2011-07-26 05:26
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!
Eric C. (Guest)
on 2011-07-28 04:51
(Received via mailing list)
On Mon, Jul 25, 2011 at 8:26 PM, Uwe K. <removed_email_address@domain.invalid>
wrote:
>
> That's a working JRuby on Android!

You can also get it for SL4A (
http://code.google.com/p/android-scripting/ ). I'd be interested if
anyone knows the differences between JRuby in the two environments.
This topic is locked and can not be replied to.