Installer somewhat broken/JRuby doesn't appear to work with current SL4A. Project inactive?

[martinjos]

I've tried this and the installer keeps failing halfway through the download of the extras file. It did succeed one time, but then, when I tried to run the Hello World script, SL4A complained that org.jruby.Main (I think) was missing. I would assume this might be because it hasn't kept up with SL4A interface changes, is this correct?

I notice that there have been no updates to this in 2 years (in fact, pretty much since it was first uploaded). Are there no plans to continue development on it? Are there (or does anyone think there are) reasons for preferring to stay with the approach of having a completely separate API interface from SL4A?

[rscottm]

Yes, the JRuby SL4A interpreter has not been updated since I first created it to move it out of the SL4A project. At the time, they were hoping to move most of the interpreters outside of the SL4A project. I think I might have been the only one who fell for it :)

A can't imagine that too much has changed. It could probably be brought back up to date with a few hours of work that would also update the JRuby version. I'll see if I can find some time to do it in the next few weeks (unless someone else wants to take a shot at it). We could use someone who wants to take this on over the long term. Interested?

I'm not sure I understand the last part of your question. Are you referring to the differences between Ruboto and SL4A? Or, are you talking about differences between JRuby/SL4A and other languages on SL4A?

[martinjos]

Kind of between things at the moment (almost), so I've been able to spend (read: waste) some time today trying to get this to work. A few results/ideas to report.

1. It turns out my problem with not being able to run JRuby has to do with an issue in CyanogenMod (still unfixed in CM9, it seems). The only "fix" found to date seems to involve making the Dalvik interpreter cache directory for jruby world-writeable.

• http://code.google.com/p/cyanogenmod/issues/detail?id=3141
• http://code.google.com/p/android-scripting/issues/detail?id=419

2. My issues with the installer can probably only be fixed (if at all) via the android-scripting InterpreterForAndroid and Utils projects.

3. Meanwhile, there also seem to be problems with the newest version of JRuby. This is probably because of that project's moves towards JRE 7 (something which might ultimately threaten JRuby for Android's existence if they ever decide to stop supporting JRE 6...).

Although they do still officially support JRE 6, it seems that there are still problems with running "dx" (Dex) on both their binary and source releases (even if built with JRE 6, and after removing the JRE-7-only "com.headius.invokebinder" classes). In the case of the source releases I believe that this may be because of the (large number of) binary dependencies packaged along with the source, which were presumably compiled against JRE 7. If this is the case, a "solution" may be to get source distributions for all of the dependencies and also recompile them using JRE 6.

The problem is that the "dx" compile step takes upwards of 40 minutes (on my admittedly outdated machine), with no sign of nearing completion. I have encountered one or two sources stating that dx will take huge amounts of time if there are any classes compiled using JRE 7, while it takes only a minute or so if they are all compiled using JRE 6. This seems to occur even if the "source" and "target" code versions are both set to 6. The only solution seems to be to actually get JDK 6 from Oracle, and recompile (which is what I have resorted to). However as I said, the binary dependency jars still seem to cause problems.

Here is one source that talks about the JDK 7 dex problem:

• https://groups.google.com/forum/#!msg/android-contrib/h0sDMo5DVBI/Vu58NbsCBzQJ

More information on JRuby's use of Java 7 features:

• http://blog.jruby.org/2011/12/getting_started_with_jruby_and_java_7/

4. Something I have noticed is that the android-scripting project still seems to contain
   its own files for JRuby. It occurs to me that this may cause confusion, with people unsure
   which version they are supposed to use. Maybe it would be best to either (a) delete that part
   of the android-scripting source tree so that people are forced to seek out the github
   project, or (b) re-merge the github project back into that tree.

Incidentally, there does seem to be someone within that project claiming to be working on JRuby support - see http://code.google.com/p/android-scripting/people/list - maybe it would be best to ask if he has any thoughts about this first.

5. I forked the github project and made a few changes, but mostly just source tree cleanup type things. Not sure whether you will want any of this. However, I also (a) changed jruby_extras.zip to jruby.zip, as I thought this offered better security (and, at the time, I thought it might fix things), and (b) changed the downloader to use my forked repository. So you'd have to avoid pulling that change. And also, (a) takes up more system memory, so
   it might not be desirable. However, it has occurred to me that it also provides an interesting new (failing, unfortunately) test-case for the issue in (1).

6. My question before about the API was to do with preferring Ruboto over SL4A.

7. Dammit, I hate markdown :)