JRuby

JRuby trunk does not build with IBM JVM 1.5

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.2
  • Component/s: IBM/Other VM
  • Labels:
    None
  • Environment:
    Windows XP 32-bit
  • Number of attachments :
    0

Description

JRuby trunk does not compile using the IBM JVM 1.5

C:\svn\jruby>java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20071025 (SR6b))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled)
J9VM - 20071004_14218_lHdSMR
JIT - 20070820_1846ifx1_r8
GC - 200708_10)
JCL - 20071025

Here is the build output:

Buildfile: build.xml

init:

clean:
[delete] Deleting directory C:\svn\jruby\docs\api
[delete] Deleting directory C:\svn\jruby\src_gen

init:

jar:

jar-jruby:

init:

extract-rdocs:

prepare:
[mkdir] Created dir: C:\svn\jruby\build
[mkdir] Created dir: C:\svn\jruby\build\classes
[mkdir] Created dir: C:\svn\jruby\build\classes\jruby
[mkdir] Created dir: C:\svn\jruby\build\classes\test
[mkdir] Created dir: C:\svn\jruby\build\test-results
[mkdir] Created dir: C:\svn\jruby\build\test-results\html
[mkdir] Created dir: C:\svn\jruby\docs\api

compile-tasks:
[copy] Copying 8 files to C:\svn\jruby\build\classes\jruby
[copy] Copying 22 files to C:\svn\jruby\build\classes\jruby\builtin
[copy] Copying 1 file to C:\svn\jruby\build\classes\jruby

compile-annotation-binder:
[mkdir] Created dir: C:\svn\jruby\src_gen
[javac] Compiling 5 source files to C:\svn\jruby\build\classes\jruby
[javac] Note: C:\svn\jruby\src\org\jruby\anno\AnnotationBinder.java uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

check-for-optional-java4-packages:

check-for-optional-packages:

compile-jruby:
[apt] Compiling 521 source files to C:\svn\jruby\build\classes\jruby
[apt] warning: Annotation types without processors: [java.lang.Override, java.lang.SuppressWarnings, java.lang.Deprecated, org.jruby.anno.JRubyConstant, org.jruby.anno.JRubyModule, java.lang.annotation.Retention, java.lang.annotation.Target]
[apt] 1 warning
[apt] Note: Some input files use unchecked or unsafe operations.
[apt] Note: Recompile with -Xlint:unchecked for details.

compile:

generate-method-classes:
[echo] Generating invokers...
[echo] Compiling populators...
[javac] Compiling 132 source files to C:\svn\jruby\build\classes\jruby
[javac] C:\svn\jruby\src_gen\org$jruby$RubyEnumerable$Populator.java:38: cannot find symbol
[javac] symbol : class RubyEnumerableInvoker$first_1_s_method_multi
[javac] location: package org.jruby
[javac] javaMethod = new org.jruby.RubyEnumerableInvoker$first_1_s_method_multi(cls, Visibility.PUBLIC);
[javac] ^
[javac] C:\svn\jruby\src_gen\org$jruby$RubyYAML$Populator.java:15: cannot find symbol
[javac] symbol : class RubyYAMLInvoker$quick_emit_s_method_multi
[javac] location: package org.jruby
[javac] javaMethod = new org.jruby.RubyYAMLInvoker$quick_emit_s_method_multi(cls, Visibility.PRIVATE);
[javac] ^
[javac] 2 errors

Activity

Hide
Charles Oliver Nutter added a comment -

This issue was caused because of hash ordering differences in reflection results on Sun versus IBM JDK. In RubyEnumerable, we bound a single Ruby method using two different Java method names. On Sun JDK, the first method was the name was used for the generated invoker, and everything bound correctly. On IBM, in some cases the first method and other cases the second method name would be used, leading to us generating the invoker with one name and trying to construct it with another. The fix was simply to make sure only a single Java method name was used to bind the method in question.

Fixed in r8702.

Show
Charles Oliver Nutter added a comment - This issue was caused because of hash ordering differences in reflection results on Sun versus IBM JDK. In RubyEnumerable, we bound a single Ruby method using two different Java method names. On Sun JDK, the first method was the name was used for the generated invoker, and everything bound correctly. On IBM, in some cases the first method and other cases the second method name would be used, leading to us generating the invoker with one name and trying to construct it with another. The fix was simply to make sure only a single Java method name was used to bind the method in question. Fixed in r8702.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: