JRuby

ClassCastException calling Fixnum#== with a Java Integer

Details

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

Description

system ~/projects/jruby/tmp $ jruby -X+C -rjava -e "5 == java.lang.Integer.new(5)"
Integer.java:52:in `compareTo': java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
	from NativeMethodAccessorImpl.java:-2:in `invoke0'
	from NativeMethodAccessorImpl.java:57:in `invoke'
	from DelegatingMethodAccessorImpl.java:43:in `invoke'
	from Method.java:601:in `invoke'
	from JavaMethod.java:455:in `invokeDirectWithExceptionHandling'
	from JavaMethod.java:316:in `invokeDirect'
	from InstanceMethodInvoker.java:59:in `call'
	from MethodHandle.java:566:in `invokeWithArguments'
	from InvocationLinker.java:166:in `invocationFallback'
	from file:/Users/headius/projects/jruby/lib/jruby.jar!/jruby/java/java_ext/java.lang.rb:29:in `method__6$RUBY$\=\^=\_'
	from Users$headius$projects$jruby$lib$jruby_dot_jar$jruby$java$java_ext$java_dot_lang$method__6$RUBY$\=\^=\_:-1:in `call'
	from Users$headius$projects$jruby$lib$jruby_dot_jar$jruby$java$java_ext$java_dot_lang$method__6$RUBY$\=\^=\_:-1:in `call'
	from RuntimeHelpers.java:2686:in `invokedynamic'
	from RubyComparable.java:117:in `callCmpMethod'
	from RubyComparable.java:108:in `op_equal19'
	from RubyComparable$INVOKER$s$1$0$op_equal19.gen:-1:in `call'
	from RuntimeHelpers.java:2686:in `invokedynamic'
	from RubyNumeric.java:878:in `op_num_equal'
	from RubyFixnum.java:825:in `op_equalOther'
	from RubyFixnum.java:818:in `op_equal19'
	from MethodHandle.java:566:in `invokeWithArguments'
	from InvocationLinker.java:166:in `invocationFallback'
	from -e:1:in `__file__'
	from -e:-1:in `load'
	from Ruby.java:778:in `runScript'
	from Ruby.java:771:in `runScript'
	from Ruby.java:648:in `runNormally'
	from Ruby.java:497:in `runFromMain'
	from Main.java:376:in `doRunFromMain'
	from Main.java:265:in `internalRun'
	from Main.java:231:in `run'
	from Main.java:215:in `run'
	from Main.java:195:in `main'

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

This appears to be newish on master only.

Show
Charles Oliver Nutter added a comment - This appears to be newish on master only.
Hide
Permalink
Charles Oliver Nutter added a comment -

Looks like the problem here is that we see two compareTo methods, one that takes Object and one that takes Integer, and because we don't have narrowing logic we pick the first one. That causes us to coerce a Fixnum to java.lang.Object, which produces a java.lang.Long, and the compareTo(Object) version on java.lang.Integer attempts to cast, producing the error.

I think the right fix here is to do Java Language Specification style narrowing, looking for the most specific overload. I will attempt that.

Show
Charles Oliver Nutter added a comment - Looks like the problem here is that we see two compareTo methods, one that takes Object and one that takes Integer, and because we don't have narrowing logic we pick the first one. That causes us to coerce a Fixnum to java.lang.Object, which produces a java.lang.Long, and the compareTo(Object) version on java.lang.Integer attempts to cast, producing the error. I think the right fix here is to do Java Language Specification style narrowing, looking for the most specific overload. I will attempt that.
Hide
Permalink
Charles Oliver Nutter added a comment - 
commit aecaffe712b9fdb5af1a733f081ce6e3023776da
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Jun 28 16:49:22 2012 -0500

    Fix JRUBY-6745
    
    ClassCastException calling Fixnum#== with a Java Integer
    
    The problem here was that when given multiple overloads that are
    all dispatchable with a given set of arguments, we just picked the
    first one. This specific case had both compareTo(Object) and
    compareTo(Integer), and we picked the Object version. Because the
    coercion from Fixnum to Object produces a Long, we eventually hit
    a ClassCastException when the Object version tried to call the
    Integer version. By fixing Java method dispatch to narrow
    overloads to the most specific version, we now will call the
    Integer version and coerce properly.
    
    I believe this was working in 1.6.7 because we had other bugs
    relating to how we coerce versus how we dispatch that caused us
    to coerce to Integer but still call the Object version.
Show
Charles Oliver Nutter added a comment - commit aecaffe712b9fdb5af1a733f081ce6e3023776da Author: Charles Oliver Nutter <headius@headius.com> Date: Thu Jun 28 16:49:22 2012 -0500 Fix JRUBY-6745 ClassCastException calling Fixnum#== with a Java Integer The problem here was that when given multiple overloads that are all dispatchable with a given set of arguments, we just picked the first one. This specific case had both compareTo(Object) and compareTo(Integer), and we picked the Object version. Because the coercion from Fixnum to Object produces a Long, we eventually hit a ClassCastException when the Object version tried to call the Integer version. By fixing Java method dispatch to narrow overloads to the most specific version, we now will call the Integer version and coerce properly. I believe this was working in 1.6.7 because we had other bugs relating to how we coerce versus how we dispatch that caused us to coerce to Integer but still call the Object version.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Charles Oliver Nutter
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: