Possible Bug in jrubyc

Ruby JRuby
1

Hi All,

I recently started working on packaging up a project I’ve been working
on,
and one of the requirements has been to compile ruby source into class
files to be jarred up for distribution. I’ve struggled through a
million
little issues, bouncing back and forth between rawr, warbler, and just
doing it myself with rake, and finally realized that (in addition to?)
other problems, the fundamental issue is that the class files produced
by
jrubyc throw an exception when executing in the JRE. Here’s the deal:

java -version
java version “1.7.0_07”
Java™ SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot™ 64-Bit Server VM (build 23.3-b01, mixed mode)

jruby -v
jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot™ 64-Bit
Server VM 1.7.0_07-b10 [darwin-x86_64]

cat com/sas/solstice/agent/main.rb
puts “Hello, Mark!”

jruby -S jrubyc com/sas/solstice/agent/main.rb
(produces the exact same file as “jrubyc
com/sas/solstice/agent/main.rb”,
btw)

java -cp .:lib/java/jruby-complete.jar com.sas.solstice.agent.main
Exception in thread “main” java.lang.NoSuchMethodError:
org.jruby.javasupport.util.RuntimeHelpers.preLoad(Lorg/jruby/runtime/ThreadContext;Ljava/lang/String;Z)V
at com.sas.solstice.agent.main.load(com/sas/solstice/agent/main.rb)
at com.sas.solstice.agent.main.main(com/sas/solstice/agent/main.rb)

jruby com/sas/solstice/agent/main.rb
Hello, Mark!

jruby com/sas/solstice/agent/main.class
Hello, Mark!

Google tells me (thanks to this mailing list) that at least one other
person has run into similar issues trying to run a webapp in Tomcat, but
I’m guessing all the additional variables in that setup might have
masked
the actual problem. There also seems to be an open bug report (
http://jira.codehaus.org/browse/JRUBY-7050) triggered by failing unit
tests, but it doesn’t look like anyone has really investigated.

Is anyone else aware of this? Are there possibly known workarounds?
NoSuchMethodError makes me think that maybe there was a refactoring at
some point that broke something that got overlooked. Just browsing the
source, I noticed that

https://github.com/jruby/jruby/blob/master/src/org/jruby/javasupport/util/RuntimeHelpers.java

looks like:

package org.jruby.javasupport.util;

import org.jruby.runtime.Helpers;

@Deprecated
public class RuntimeHelpers extends Helpers {
}

This seems like a very promising lead for the given error, but I don’t
have the context to follow it. It also tells me that, in spite of the
subject of this email, jrubyc is probably doing its job right, but the
jruby runtime needs a bit of tweaking. Any thoughts?

Thanks so much!
Mark

2

Ok, I see the problem (I think). About a month
ago, org/jruby/javasupport/util/RuntimeHelpers.java moved to
org/jruby/runtime/Helpers. But the problem I’m seeing was caused by
some
refactoring that happened prior to that move. I noticed that the
signature
sought by the bytecode in the classfile
is
org.jruby.javasupport.util.RuntimeHelpers.preLoad(Lorg/jruby/runtime/ThreadContext;Ljava/lang/String;Z)V,
which I think means it wants a preLoad method which returns void, and
RuntimeHelpers (which is empty and deprecated, but inherits from
Helpers)
no longer has that method. At some point (I couldn’t quite pinpoint
when),
RuntimeHelpers switched from

public static void preLoad(ThreadContext context, String[] varNames) {

to

public static StaticScope preLoad(ThreadContext context, String[]
varNames)
{

(Note the return type change). So I think there are two problems with
the
bytecode being produced. First, it’s still referencing RuntimeHelpers,
which is now deprecated, and second, whatever produces the bytecode
didn’t
get updated in concert with everything else when preLoad changed return
type.

I’m fairly confident at this point that this is a legitimate bug, so
I’ll
file a bug report, but I wanted to report back to the list since I
jumped
the gun on sending out the first question.

Thanks!
Mark

P.S. Looking through the JRuby code really makes me appreciate the
phenomenal amount of work the JRuby team does and has done. So much
code
created, managed, and tested! I remain absolutely amazed that someone
had
the idea and the gumption to understand all the systems necessary to
pull
all this together, and the will to stick with it over all these years.
The
end result opens doors for me at work, and provides me opportunities to
deal with technology that makes me happy and engaged. The work you all
are
doing is absolutely appreciated. Thanks!

3
4

Hi Mark,

Le 25/04/2013 13:37, Mark McCraw a écrit :

jruby com/sas/solstice/agent/main.class
Hello, Mark!

Odd. If this works, then the failing one should more than likely also
work. Are you sure the jruby-complete.jar you add to the classpath is
the same version as your jruby installation?

This definitely works with a recent version (although I am on Ubuntu,
rather than OS X):

$ mkdir -p com/sas/solstice/agent; echo “puts ‘Hello Mark’” >
com/sas/solstice/agent/main.rb
$ cat com/sas/solstice/agent/main.rb
puts ‘Hello Mark’
$ jruby -S jrubyc com/sas/solstice/agent/main.rb
$ java -cp .:./jruby.jar com.sas.solstice.agent.main
Hello Mark
$ jruby -v
jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot™ 64-Bit
Server VM 1.7.0-b147 [linux-amd64]

Regards,
Sébastien.

5

Well, don’t I feel stupid! Sure enough, if I compile using the same
version of jruby-complete.jar that I run against, everything is fine.
The
versions were mismatched. Thanks for the pointer in the right
direction.
I’ve closed the issue I opened about this :wink: