Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: JRuby 1.1.5
-
Fix Version/s: None
-
Component/s: Intro, Java Integration
-
Labels:None
-
Environment:Linux clevo 2.6.25.14-69.fc8 #1 SMP Mon Aug 4 14:20:24 EDT 2008 i686 i686 i386 GNU/Linux
Description
from #jruby:
CaneToad: it seems the first time you invoke the script engine, it can report the error to be in the builtins when it isn't...doesn't happens on subsequent calls to the script engine
headius: hmmm
...
headius: I'd say go ahead and file it
Java code to reproduce:
////////////////////////////////////////////////////////////////////
import javax.script.*;
public class jruby2 {
public static void run(ScriptEngine engine, String msg) {
System.err.println(msg);
try {
engine.eval("a=Hello");
} catch(ScriptException e) {
e.getCause().printStackTrace(System.err);
}
}
public static void main(String [] args) throws Exception {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("jruby");
run(engine, "------------ first");
run(engine, "------------ second");
}
}
////////////////////////////////////////////////////////////////////
Here's what it gives:
[dcampbel@clevo ~]$ javac -classpath .:jruby.jar:jruby-engine.jar jruby2.java
[dcampbel@clevo ~]$ java -classpath .:jruby.jar:jruby-engine.jar jruby2
------------ first
/builtin/javasupport.rb:49:in `const_missing': uninitialized constant Hello (NameError)
from <unknown>:1
...internal jruby stack elided...
from Module.const_missing(<unknown>:1)
from (unknown).(unknown)(:1)
------------ second
null:1:in `const_missing': uninitialized constant Hello (NameError)
from <unknown>:1
...internal jruby stack elided...
from Module.const_missing(<unknown>:1)
from (unknown).(unknown)(:1)
Notice that the first call reports the error in a builtin, while the second identical call does not
This may be simply a side-effect of Java integration lazily initializing. The first call triggers JI stuff to load up, which insinuates itself into the stack trace. The second call already has JI initialized, so it doesn't show up. I suspect requiring 'java' before the first call would cause both traces to be the same. Pretty minor issue though, and I'm not sure whether we can or need to fix it.