Issue1230210

Obviously, the jikes compiler outputs different byte code 
than javac. I was using jikes 1.21 to build jython 2.2a2 as 
of 2005-06-18, and noticed that isinstance(2.0, float) 
returned 0. This only happens with jikes and could 
indicate a bug in the project (or in jikes, but that is more 
unlikely).

After some debugging I found out where things differ. In 
Py.isInstance..

        if (cls instanceof PyType) {
            PyType objtype = obj.getType();
=>            if (objtype == cls)
                return true;
            return objtype.isSubType((PyType) cls);
        } else if (cls instanceof PyClass) {

.. the identity check fails with jikes, while it passes with 
javac. So somehow, with jikes, there are two instances of 
PyType for PyFloat.

Looking in PyFloat one see it caches its PyType..

    private static final PyType FLOATTYPE = PyType.
fromClass(PyFloat.class);

.. and submits it to the PyObject constructor..

    public PyFloat(double v) {
        super(FLOATTYPE);
        value = v;
    }

.. so that the default constructor in PyObject doesn't 
have to look it up on each instantiation. If I comment out 
super(FLOATTYPE) above, everything works again. But 
since I find the caching sound I don't want to do that. 

What's even more strange is that PyInteger does the 
exact same caching, but isinstance(2, int) works just 
fine.

The real bug it seems to me, is that PyType.
fromClass(PyFloat.class) can return different objects 
when it is supposed not to. After looking at it though, I 
can't figure out what might go wrong.

...johahn

Logged In: YES 
user_id=37674

I'm not sure the breakdown of javac and jikes uses but this sounds like 
a bug we should investigate.  The release of Jython will be built with 
javac.

Ive encountered this with Java 6 and javac and I have the feeling that they may be the same problem.  What is happening in my case is that it appears in PyType:
while(cur != PyObject.class) {

                    Class exposed_as = (Class)exposed_decl_get_object(cur, "as");

                    if(exposed_as != null) {

                        PyType exposed_as_type = fromClass(exposed_as);

                        class_to_type.put(c, exposed_as_type);

                        return exposed_as_type;

                    }

                    cur = cur.getSuperclass();


in addFromClass is triggering the static intializer of PyFloat to execute.  This happens during __builtin__.fromClass is executing against PyFloat.  In PyFloat we have this line of code:
 private static final PyType FLOATTYPE = PyType.fromClass(PyFloat.class);


which apparently is causing fromClass to execute and create a new type before the first call has a chance to put its class in the class_to_type HashMap, which means that we end up with multiple PyTypes floating around for PyFloat and who knows what else(if it fits the pattern) here.  Somewhat maddening.  This doesn't surprise me that its happening with jikes, given that it could produce different bytes.  In my case with javac, Im not sure what's really triggering it but Im running with some modified Jython code.  It doesn't happen for me with the vanilla code.

leouser

The code up on Subversion will hopefully fix this for jikes.  I suppose to verify it jikes will be needed to compile everything and see if it fails.

Jikes was last updated in October, 2004, and only partially supports
Java 5.  I don't think it's reasonable to support jikes for jython,
unfortunately.

For Jython 2.5a3+, I tried to build jython with jikes, but our
requirement of JDK 1.5 or later causes problems.  With our build.xml,
jikes will quit because we give it the "-source 1.5" flag, but jikes
only understands the 1.3 and 1.4 profiles for this.  If we change the
build.xml to source 1.4, then jikes emits a lot of errors relating to
enums (a 1.5 lang feature) and fails to complete.

Given that jikes is no longer supported, we can't support it either.