This project provides a rebundled version of the Jython library (specifically:
org.python:jython-standalone) with shaded (i.e., renamed) dependencies.
You can use it as follows:
<dependency> <groupId>org.scijava</groupId> <artifactId>jython-shaded</artifactId> <version>2.7.1</version> </dependency>
With this approach, dependencies of Jython are renamed to have a package prefix
org.scijava.jython.shaded. So all of Jython "just works" without
interfering with other consumers of JFFI or other dependencies you might have
on your classpath.
It leverages the Maven Shade Plugin to do it.
The Jython project is awesome. But it has a critical problem: the binary artifacts available from Maven Central are unshaded uberjars, and hence not usable in large projects. In particular, both Jython and JRuby depend on the JFFI library, but at different and incompatible versions thereof.
The naive way to add a Jython dependency is:
<dependency> <groupId>org.python</groupId> <artifactId>jython</artifactId> <version>2.7.1</version> </dependency>
But that artifact does not include the critical
Lib/ directory with all of
the native Python libraries necessary for many functions to work (e.g.,
So another artifact is available which includes those libraries:
<dependency> <groupId>org.python</groupId> <artifactId>jython-standalone</artifactId> <version>2.7.1</version> </dependency>
jython-standalone are uberjars, meaning they
bundle the dependencies of the project inside the JAR itself. And they are
both unshaded, meaning they don't rename the package prefixes of those
dependencies. So if you need to use a different version of those dependencies
(e.g., because JRuby needs a different version of JFFI), then you are out of
Here is an example Jython script that produces an exception when attempting to run it using Jython 2.5.3 when JRuby 1.7.12 and dependencies (including JFFI 1.2.7) are also on the classpath:
import os print os.path.isdir('/')
The exception which occurs is:
Traceback (most recent call last): File "test.py", line 2, in <module> File ".../jython-standalone-2.5.3.jar/Lib/posixpath.py", line 195, in isdir File ".../jython-standalone-2.5.3.jar/Lib/posixpath.py", line 195, in isdir java.lang.IncompatibleClassChangeError: Found class com.kenai.jffi.InvocationBuffer, but interface was expected at com.kenai.jaffl.provider.jffi.AsmRuntime.marshal(AsmRuntime.java:167) at org.python.posix.LibC$jaffl$0.stat$raw(Unknown Source) at org.python.posix.LibC$jaffl$0.stat(Unknown Source) at org.python.posix.BaseNativePOSIX.stat(BaseNativePOSIX.java:200) at org.python.posix.LazyPOSIX.stat(LazyPOSIX.java:207) at org.python.modules.posix.PosixModule$StatFunction.__call__(PosixModule.java:954) at org.python.core.PyObject.__call__(PyObject.java:391) at posixpath$py.isdir$17(/Applications/Science/Fiji.app/jars/jython-standalone-2.5.3.jar/Lib/posixpath.py:198) at posixpath$py.call_function(/Applications/Science/Fiji.app/jars/jython-standalone-2.5.3.jar/Lib/posixpath.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.pycode._pyx0.f$0(New_.py:2) at org.python.pycode._pyx0.call_function(New_.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1275) ...
When running with
jython-shaded on the classpath instead of
jython-standalone, the above script works as expected.
Q: Why is this structured as a multi-module project?
A: Due to a bug in ASM (the library that
maven-shade-plugin uses to
rewrite the Java bytecode with the shaded package names), many of the
<foo>$py.class files cannot be processed properly. Fortunately, these classes
do not actually need to be rewritten, since they themselves do not directly
reference any of Jython's dependencies. So this project works around the issue
by using the Shade plugin twice: once to build a JAR of shaded dependencies
<foo>.py classes, and a second time to mix them back in to the