Ahead of time compiled classes reference methods whose signatures have changed #657

mamccr opened this Issue Apr 25, 2013 · 1 comment


None yet

1 participant

mamccr commented Apr 25, 2013

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

jruby -S jrubyc com/sas/solstice/agent/main.rb
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)

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) {


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.

@mamccr mamccr closed this Apr 25, 2013
mamccr commented Apr 25, 2013

Ugh. Sorry for the noise. The version of jruby I had installed was mismatched with the jruby-complete I was running against.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment