Issue1889

Jython 2.7.0a1 produces an ugly, but surprisingly non-fatal, stack dump with each run on Windows 7 64-bit. (Not quite a crash then.) I've added a pasted version of the console session as an attachment. The short version of the story runs as follows:
>hg update v2.7.0a1
...
>ant clean
...
>ant
... only the usual complaints
>dist\bin\jython
*sys-package-mgr*: processing new jar, 'C:\hg\jython-dev\dist\jython-dev.jar'
...
*sys-package-mgr*: processing new jar, 'C:\hg\jython-dev\dist\javalib\jffi-x86_64-Windows.jar'
...
java.lang.ExceptionInInitializerError
        at com.kenai.jffi.Foreign.getInstance(Foreign.java:95)
        at com.kenai.jffi.Type$BuiltinTypeInfo.<clinit>(Type.java:265)
        at com.kenai.jffi.Type$Builtin.size(Type.java:216)
...
        at org.python.core.io.StreamIO.isatty(StreamIO.java:234)
        at org.python.core.io.BufferedIOMixin.isatty(BufferedIOMixin.java:90)
        at org.python.core.io.TextIOBase.isatty(TextIOBase.java:175)
        at org.python.core.PyFile.file_isatty(PyFile.java:485)
        at org.python.core.PyFile.isatty(PyFile.java:480)
        at org.python.core.PySystemState.initEncoding(PySystemState.java:273)
        at org.python.core.PySystemState.<init>(PySystemState.java:216)
        at org.python.core.PySystemState.doInitialize(PySystemState.java:918)
        at org.python.core.PySystemState.initialize(PySystemState.java:828)
        at org.python.core.PySystemState.initialize(PySystemState.java:778)
        at org.python.core.PySystemState.initialize(PySystemState.java:771)
        at org.python.util.jython.run(jython.java:159)
        at org.python.util.jython.main(jython.java:135)
Caused by: java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: could not locate stub library in jar file.  Tried [jni/x86_64-Windows/jffi-1.2.dll, /jni/x86_64-Windows/jffi-1.2.dll]
...
Caused by: java.lang.UnsatisfiedLinkError: could not locate stub library in jar file.  Tried [jni/x86_64-Windows/jffi-1.2.dll, /jni/x86_64-Windows/jffi-1.2.dll]
        at com.kenai.jffi.internal.StubLoader.getStubLibraryStream(StubLoader.java:336)
...
Jython 2.7a1+ (, May 19 2012, 09:43:27)
[Java HotSpot(TM) 64-Bit Server VM (Sun Microsystems Inc.)] on java1.6.0_26
Type "help", "copyright", "credits" or "license" for more information.
>>> [x*x for x in range(10)]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

I spent some time looking into this.

The problem appears to be that we have updated JFFI to a snapshot release that does not support the full set of platforms. When we use JFFI, com.kenai.jffi.internal.StubLoader looks for a JAR named after the architecture of the machine and loads a versioned DLL from it. Here is the one for i386:

>jar tf extlibs\jffi-i386-Windows.jar
META-INF/
META-INF/MANIFEST.MF
jni/
jni/i386-Windows/
jni/i386-Windows/jffi-1.2.dll

But the one for 64-bit Windows, and several others, contain nothing:

>jar tf extlibs\jffi-x86_64-Windows.jar
jni/

In a previous version, it looked like this:

>jar tf ..\jython-2.5\extlibs\jffi-x86_64-Windows.jar
META-INF/
META-INF/MANIFEST.MF
jni/
jni/x86_64-Windows/
jni/x86_64-Windows/jffi-1.0.dll

Quite recently, the project supplied new JARs, see: https://github.com/jnr/jffi/commit/e3e5810e6d9ea3d7669ada2e18226d472bcb81ee (this seems to be the authoritative source).

Rudely forcing the JAR from that commit into extlibs solves the problem for Windows 7/64. I won't try to make a patch for that as it's probably easier to go to the source and get a stable release. Although actively worked, it is not clear to me what the project considers a stable release.

Weird - we'll be having another look at this around the time that the next JRuby comes out - they are the ones developing jffi - I'd be surprised if they have this problem. We probably missed a jar.

The jar is not so much missing as empty, as are those for several other platforms. A changeset pulled jars from the jnr project during developement. (However, that seems to be the situation indefinitely: it would help if the jnr project were to define releases of a described quality.)

Just in the scope of this issue, here is a patch that means we can run Jython 2.7 on Windows 7. It supplies a more recent jar file from the jnr project, and (for the benefit of developers using Eclipse) updates .classpath to use it.

I've done a round of developement using this locally, so I propose to commit this (now I can).

Revised jar now pushed to the trunk. I'll close this, as I seem able to, but feel free to tell me only the PM is supposed to do that.

Note that a good few of the other jffi jars are empty too, so other users of several other platforms will have the same problem.

Jeff: feel free to close bugs as you see fit.