In the RC1 release thread, Thomas E Enebo [email protected] wrote:
Bug reports welcome and requested!
Please try your apps against 1.4.0RC1 ASAP and report problems
Not sure if these count, but thought I would mention them anyway. We’re
using JRuby in an embedded context and two sanity check tests fail for
us
when switching from jruby-engine to JRuby’s new built-in support for
javax.script.
-
This one might be a bug, although the impact is low.
public void testWriterEncoding() throws Exception {
String testString = “\u30C6\u30B9\u30C8”;
assumeThat(Charset.defaultCharset(), canEncode(testString));ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByExtension("rb"); ScriptContext context = new SimpleScriptContext(); StringWriter stringWriter = new StringWriter(); context.setWriter(stringWriter); engine.eval("puts '" + testString + '\'', context); assertEquals("Wrong value came out on the Writer",
testString, stringWriter.toString().trim());
}
The test itself passes but we get a mystifying warning on stderr:
:1 warning: already initialized constant STDERR
As you can see, the script is a single line of code and it certainly
isn’t
trying to define a constant, so I have to imagine every script gets this
warning.
-
This one is not a bug but the behaviour changed for some reason:
public void testErrorBehaviourForUnknownSymbol() throws Exception {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByExtension(“rb”);try { engine.eval("no_method_with_this_name"); fail("Expected ScriptException"); } catch (ScriptException e) { RaiseException cause = (RaiseException) e.getCause(); cause.toString(); StringWriter writer = new StringWriter(); cause.printStackTrace(new PrintWriter(writer)); assertTrue("Not seeing the expected string at the
start", writer.toString().startsWith(“undefined local variable or
method”));
}
}
This fails because e.getCause() is now a RuntimeException. The
RaiseException we expected is now inside the RuntimeException but it’s
still
present, so if there is a good reason why this additional level of
exceptions was added, I’ll just change our test. As RaiseException is
already a RuntimeException I’m finding it hard to explain why it needed
to
be changed. 
TX