JRuby

JRuby version 1.1.3 also has the same error
I can run JRuby version 1.1 however then jirb does not work but this is other error

We notice a similar behaviour:

• • • • • • • • • • • • Start Display Current Environment ************
                        WebSphere Platform 6.1 [BASE 6.1.0.19 cf190836.04] [WEBSERVICES 6.1.0.19 cf190834.03] running with process name
                        Host Operating System is Windows XP, version 5.1 build 2600 Service Pack 3
                        Java version = J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled)

After deploying a jruby 1.1.4 project (packed with warbler) we got following exception:

[25.09.08 15:48:54:939 CEST] 00000027 ServletWrappe E SRVE0068E: Es wurde eine Ausnahme angefangen, die in einer der Servicemethoden des Servlet Rails ausgelöst wurde. Ausgelöste Ausnahme: java.lang.ClassFormatError: (InterfaceImpl-571218939) class name is invalid at offset=0
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:256)
at org.jruby.util.JRubyClassLoader.defineClass(JRubyClassLoader.java:22)
at org.jruby.java.MiniJava.defineOldStyleImplClass(MiniJava.java:510)
at org.jruby.java.MiniJava.createOldStyleImplClass(MiniJava.java:193)
at org.jruby.javasupport.Java.new_proxy_instance2(Java.java:1587)
at org.jruby.java.proxies.JavaInterfaceTemplate.jcreateProxy(JavaInterfaceTemplate.java:256)
at org.jruby.java.proxies.JavaInterfaceTemplate.access$000(JavaInterfaceTemplate.java:23)
at org.jruby.java.proxies.JavaInterfaceTemplate$3.call(JavaInterfaceTemplate.java:163)
at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodNoBlock.call(JavaMethod.java:62)
at org.jruby.RubyClass.finvoke(RubyClass.java:343)
at org.jruby.javasupport.util.RuntimeHelpers.invoke(RuntimeHelpers.java:335)
at org.jruby.java.proxies.JavaInterfaceTemplate$2.call(JavaInterfaceTemplate.java:147)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:242)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:151)
at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:156)
at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:394)
at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:101)
at org.jruby.internal.runtime.methods.DefaultMethod.interpretedCall(DefaultMethod.java:163)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:140)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:253)
at org.jruby.RubyClass.finvoke(RubyClass.java:458)
at org.jruby.javasupport.util.RuntimeHelpers.invoke(RuntimeHelpers.java:342)
at org.jruby.RubyObject.callMethod(RubyObject.java:700)
at org.jruby.javasupport.JavaEmbedUtils$1.callMethod(JavaEmbedUtils.java:133)
at org.jruby.rack.DefaultRackApplication.__call(DefaultRackApplication.java:64)
at org.jruby.rack.DefaultRackApplication.call(DefaultRackApplication.java:44)
at org.jruby.rack.DefaultRackDispatcher.process(DefaultRackDispatcher.java:32)
at org.jruby.rack.RackServlet.service(RackServlet.java:42)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1095)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:569)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3440)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:815)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1461)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:118)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

Looking into it.

I've fixed the InterfaceImpl thing and another bad test in testYAML and I'm working my way through the test run. Once it's running I'll set up a CI build against it.

i'm using IBM's Java 6. Here's the current issue, in the command-line test:

    [junit] Failure:
    [junit] test_server_vm_option(TestCommandLineSwitches) [/home/headius/jruby/./test/test_command_line_switches.rb:223]:
    [junit] <"j9jit24"> expected to be =~
    [junit] </(tiered|server)/>.
    [junit] 
    [junit] junit.framework.AssertionFailedError: Faults encountered running test/test_command_line_switches, complete output follows:
    [junit] Failure:
    [junit] test_client_vm_option(TestCommandLineSwitches) [/home/headius/jruby/./test/test_command_line_switches.rb:242]:
    [junit] <"j9jit24"> expected to be =~
    [junit] </client/>.
    [junit] Failure:
    [junit] test_dash_little_n_wraps_script_with_while_gets(TestCommandLineSwitches)
    [junit]     [/home/headius/jruby/./test/test_command_line_switches.rb:92:in `test_dash_little_n_wraps_script_with_while_gets'
    [junit]      /home/headius/jruby/./test/test_helper.rb:37:in `with_temp_script'
    [junit]      /home/headius/jruby/lib/ruby/1.8/tempfile.rb:188:in `open'
    [junit]      /home/headius/jruby/./test/test_helper.rb:29:in `with_temp_script'
    [junit]      /home/headius/jruby/./test/test_command_line_switches.rb:90:in `test_dash_little_n_wraps_script_with_while_gets']:
    [junit] <"a\na\nb\nb\n"> expected but was
    [junit] <"a\na\n">.
    [junit] Failure:
    [junit] test_dash_little_p_wraps_script_with_while_gets_and_prints(TestCommandLineSwitches)
    [junit]     [/home/headius/jruby/./test/test_command_line_switches.rb:102:in `test_dash_little_p_wraps_script_with_while_gets_and_prints'
    [junit]      /home/headius/jruby/./test/test_helper.rb:37:in `with_temp_script'
    [junit]      /home/headius/jruby/lib/ruby/1.8/tempfile.rb:188:in `open'
    [junit]      /home/headius/jruby/./test/test_helper.rb:29:in `with_temp_script'
    [junit]      /home/headius/jruby/./test/test_command_line_switches.rb:100:in `test_dash_little_p_wraps_script_with_while_gets_and_prints']:
    [junit] <"a\na\na\nb\nb\nb\n"> expected but was
    [junit] <"a\na\nb\nb\n">.
    [junit] Failure:
    [junit] test_server_vm_option(TestCommandLineSwitches) [/home/headius/jruby/./test/test_command_line_switches.rb:223]:
    [junit] <"j9jit24"> expected to be =~
    [junit] </(tiered|server)/>.

Obviously the server/client strings are the old classic problem with matching against the name of the VM. But the -n and -p behaviors, I'm confused about; there's nothing that should be platform-specific in them.

Fixes to date committed to trunk.

Fixed the above and some JI test bugs (see JRUBY-3037). Current issue now appear to be something freezing during test_launching_by_shell_script.rb.

I've made a few more fixes and disabled some tests that appeared to be failing under IBM JDK, and I think we're able to run the test suite to completion now. See JRUBY-3037, JRUBY-3040, and JRUBY-3043 for those remaining broken cases.

I fixed what I could and disabled a few tests. See the bugs listed in my previous comment for those issues. They're mostly minor, and we now have a CI run against IBM that should help keep it working into the future.