JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-6741

Inconsistent == on java.lang.Integer between Mac and RedHat Enterprise Linux

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6.7
    • Fix Version/s: JRuby 1.7.0.pre2
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      require 'java'

      5==java.lang.Integer.new(5) returns true on Macs but nil on linux. I tried this on several different versions of JRuby up to and including 1.6.7.

      On the RHEL install and any macs the following returned true
      5.0 == java.lang.Double.new(5)
      5 == java.lang.Long.new(5)

      The fact that only Integer has this issue makes me think its some sort of bug related to JRuby on on Redhat. Id' be willing to try other things or do more investigation but right now I'm not sure how to proceed.

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        I would be more inclined to pin this on JVM differences. Sometimes JDK classes will add a new method that takes a primitive, and we'll start picking that one up.

        In this case, at least for fixnums, == will flip it around and call == on java.lang.Integer, which will call the Java equals(Object) and should coerce the fixnum to a java.lang.Long.

        On master/1.7 this actually leads to a ClassCastException:

        system ~/projects/jruby/tmp $ jruby -rjava -e "5 == java.lang.Integer.new(5)"
        Integer.java:37:in `compareTo': java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
        

        On 1.6.7 I see "true" result as you do (on Mac) for all cases, on both Java 6 and Java 7.

        I just happen to have a fedora VM here, so I'll give it a shot. Can you tell me what version of Java you tried with?

        Show
        Charles Oliver Nutter added a comment - I would be more inclined to pin this on JVM differences. Sometimes JDK classes will add a new method that takes a primitive, and we'll start picking that one up. In this case, at least for fixnums, == will flip it around and call == on java.lang.Integer, which will call the Java equals(Object) and should coerce the fixnum to a java.lang.Long. On master/1.7 this actually leads to a ClassCastException: system ~/projects/jruby/tmp $ jruby -rjava -e "5 == java.lang.Integer.new(5)" Integer.java:37:in `compareTo': java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer On 1.6.7 I see "true" result as you do (on Mac) for all cases, on both Java 6 and Java 7. I just happen to have a fedora VM here, so I'll give it a shot. Can you tell me what version of Java you tried with?
        Hide
        Charles Oliver Nutter added a comment -

        Created JRUBY-6745 to track the ClassCastException.

        Show
        Charles Oliver Nutter added a comment - Created JRUBY-6745 to track the ClassCastException.
        Hide
        Jason Gilman added a comment -

        The java version was:
        java version "1.6.0_31"
        Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
        Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

        Show
        Jason Gilman added a comment - The java version was: java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
        Hide
        Charles Oliver Nutter added a comment -

        Ok, it's very likely what I suspected: subtle differences between the Java installs.

        I committed a fix for JRUBY-6745 that also will probably fix this issue by making the selected methods more consistent across platforms. I don't have a RHEL instance set up right now, so can you confirm this for me with a master build?

        Show
        Charles Oliver Nutter added a comment - Ok, it's very likely what I suspected: subtle differences between the Java installs. I committed a fix for JRUBY-6745 that also will probably fix this issue by making the selected methods more consistent across platforms. I don't have a RHEL instance set up right now, so can you confirm this for me with a master build?
        Hide
        Jason Gilman added a comment - - edited

        I just cloned and built jruby master on my RHEL instance. I can confirm the bug is fixed now. Thanks for fixing this!

        Show
        Jason Gilman added a comment - - edited I just cloned and built jruby master on my RHEL instance. I can confirm the bug is fixed now. Thanks for fixing this!

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Jason Gilman
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: