Issue2216

Observe:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True

----------

The errant return value comes from this injected method in PyJavaType.java:

(lines 904-921)

    private static abstract class ComparableMethod extends PyBuiltinMethodNarrow {
        protected ComparableMethod(String name, int numArgs) {
            super(name, numArgs);
        }
        @Override
        public PyObject __call__(PyObject arg) {
            Object asjava = arg.__tojava__(Object.class);
            int compare;
            try {
                compare = ((Comparable<Object>)self.getJavaProxy()).compareTo(asjava);
            } catch(ClassCastException classCast) {
                return Py.NotImplemented;
            }
            return getResult(compare) ? Py.True : Py.False;
        }

        protected abstract boolean getResult(int comparison);
    }

In particular, a ClassCastException was thrown.

Which, when reduced, come to this simplified Java snippet:

import java.math.BigInteger;

public class BigCompare {

    public static void main(String[] args) {
        Object bi = (Object) new BigInteger("10");
        Object i = (Object) new Integer(100);
        System.out.println("" + ((Comparable<Object>)bi).compareTo(i));
    }   
}

$ java BigCompare 
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger
        at java.math.BigInteger.compareTo(BigInteger.java:99)
        at BigCompare.main(BigCompare.java:8)

There's a dance inside Jython where Integer and BigInteger are tried to be coerced to each other for comparison, but all attempts failed. Hence, the non-conformant result.

Need to fix this coercion so that it does something reasonable for comparing BigInteger and int for example. The default mechanism that ultimately uses class, then IdentityHashCode to determine ordering needs to be retained for 2.7, but can be pulled out for 3.x.

This is apparently in response to http://permalink.gmane.org/gmane.comp.lang.jython.user/10467, but I think it does not answer the underlying problem. The underlying problem is a bug in our JSR-223 implementation probably also identified in #2090 and #1494. The mistake is to test this at the REPL prompt, when the problem is in the *different* interpreter used by the script engine. This seems to be why #1494 was closed, in error I think.

You could say the observed behaviour is correct, under the arcane Python 2 rules. BigInteger is not a special Java class to the interpreter, so it is not numerically comparable to int. Alternatively, having Jython treat java.lang.BigInteger as a number *may* be a good idea. (How about BigDecimal too? Or java.lang.Number in general, in the same way that Comparable gets special treatment?) It would be a new feature, not a bug-fix.

Agreed, but a potentially nice new feature. Less important that what we did for Map, List, or Set however.

I think we're saying that a more forgiving set of coercion rules should be in force for mathematical integers of various actual classes. I agree, but  don't see it as a *essential* for 2.7.2.