1.6.0RC1, JSR-223 and returning variables

Ruby JRuby
1

Hi.

I’m working on a java 1.6 project where we would like allow scripting
with different scripting engines via JSR-223. Currenty we would like to
support javascript, jython, groovy and jruby. As I tested the different
languages for basic functionality, I came across a problem with jruby.

It seems that passing back variables isn’t working as I expected
(according to the other engines).

I’ve learned from this:

http://markmail.org/message/wlktabnqosiyu4h3?q=jsr223+change+variable+list:org.codehaus.jruby.user#query:jsr223%20change%20variable%20list%3Aorg.codehaus.jruby.user+page:1+mid:22liw4ajmq3s6x5n+state:results

that ruby puts variables like “a” as global variables to the script
accessible as “$a”. So far so good. But trying to get the modified “a”
from the binding returns the initial value, not the changed one.

As the post above mentions, one has to use:

System.setProperty(“org.jruby.embed.localvariable.behavior”,
“transient”);

Using this allows access to the variable within ruby as “normal” “a”
variable but still returns the initial value.

BUT, putting the variable as “@a” to the binding, using the same in ruby
and getting “@a” back via binding seems to work for me. Now it contains
the modified value.

Now my question is: shouldn’t variable names be independent of any
scripting language specific style when using them on java side? All
other engines I’ve tested are working with simple “a” on java side (and
even on script code basis but that shouldn’t be mandatory I guess).

Here’s the code I used:

(not working, outputs “value a: 0”):
System.setProperty(“org.jruby.embed.localvariable.behavior”,
“transient”);

ScriptEngineManager seMgr = new ScriptEngineManager();
ScriptEngine se = seMgr.getEngineByName(“jruby”);

Bindings bindings = se.createBindings();
bindings.put(“a”,0);

se.eval(“a=a+1\n”, bindings);

System.out.println("value a: "+bindings.get(“a”));

(working, outputs “value a: 1”):
System.setProperty(“org.jruby.embed.localvariable.behavior”,
“transient”);

ScriptEngineManager seMgr = new ScriptEngineManager();
ScriptEngine se = seMgr.getEngineByName(“jruby”);

Bindings bindings = se.createBindings();
bindings.put(“@a”,0);

se.eval(“@a=@a+1\n”, bindings);

System.out.println(“value a: “+bindings.get(”@a”));

Also tried it with jruby 1.5.6 but there even “@a” didn’t work for me.
I am missing something here?

Thanks!

–
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

2

On Sat, Feb 5, 2011 at 7:43 AM, Veit G. [email protected] wrote:

I’ve learned from this:

http://markmail.org/message/wlktabnqosiyu4h3?q=jsr223+change+variable+list:org.codehaus.jruby.user#query:jsr223%20change%20variable%20list%3Aorg.codehaus.jruby.user+page:1+mid:22liw4ajmq3s6x5n+state:results

that ruby puts variables like “a” as global variables to the script
accessible as “$a”. So far so good. But trying to get the modified “a”
from the binding returns the initial value, not the changed one.

I recently fixed a bug about this area, so it might have been fixed by
that change.

As the post above mentions, one has to use:

System.setProperty(“org.jruby.embed.localvariable.behavior”, “transient”);

Using this allows access to the variable within ruby as “normal” “a”
variable but still returns the initial value.

“a” is a local variable. Local variables won’t survive over the
evaluation when transient model is chosen. If it is persistent, you
can get local variables after the evaluation.

BUT, putting the variable as “@a” to the binding, using the same in ruby
and getting “@a” back via binding seems to work for me. Now it contains
the modified value.

I introduced “lazy” retrieval option to improve performance. See

If this default value is confusing, I’m willing to get that back to
old behavior.

Now my question is: shouldn’t variable names be independent of any
scripting language specific style when using them on java side? All
other engines I’ve tested are working with simple “a” on java side (and
even on script code basis but that shouldn’t be mandatory I guess).

This default behavior is identical to the reference implementation
released from Sun. We have a plan to switch default from global to
transient in the next major release, maybe 2.0 or so. Changing default
setting of local variable behavior is considered big.

-Yoko