Interview with Frank Wierzbicki from the Jython project

I started using Jython for testing and scripting the Java code I was working on in 1999. Ever since it remained a favorite tool for me. Sometime in 2004 I started contributing patches to the Jython project until the then project lead Brian Zimmer gave me commit privileges. A few months later Brian had some new stuff in his life that was not going to leave him with enough time for Jython development. At that point I was the heaviest contributor, and he offered me the lead role.

There are about eight active developers committing code to Jython. I don't think there are really any defined roles, developers work in those parts of the codebase that interests them. There are some areas where one developer does most of the work, but it isn't a rigid system at all.

Jython was started by Jim Huginin in the late nineties -- Jython's repository marks his first checkin as 1997. His motivations are described in the Story of Jython.

Sun Microsystems allows me to spend most of my time working on Jython.

Any application that needs to access frameworks or libraries written in Java will find that Jython does a very good job in this area. Java code can be imported and used directly by Jython code.

Applications that want to access multiple cores using threads should also consider Jython. Our multi-threading story is potentially better than CPython's due to our lack of a GIL (Global Interpreter Lock). Our dictionary implementation is based on the ConcurrentHashMap from the wonderful java.util.concurrent APIs, which means that our dictionary should scale very well in the face of multiple threads. To make good use of multiple cores from CPython, you'd need to use multiple processes or drop to C code for your threading.

Jython requires a larger minimum memory footprint compared to CPython, but Jython uses Java's garbage collection mechanisms, which are far more sophisticated than CPython's. I don't think this has been measured, but my gut would say that we will do better for some memory intensive tasks.

Speed-wise, we perform between the same and about two times slower compared to CPython for most tasks. There are a few areas where we find that we are faster than CPython, see here for one.

As an aside, the 2.5.0 cycle focused almost exclusively on CPython compatibility. We have done very little performance work to date. Performance will be a big focus for 2.5.1 and 2.6.

I don't actually know the user statistics here. I do know that most of the Jython developers work day to day on OS X. From the questions that we get on the mailing lists and IRC, I know that Linux, Unix, and Windows are well represented in our user populations.

Our primary focus for 2.5.0 was compatibility with the 2.5 version of CPython. We have made great strides in this area, supporting far more of the libraries that ship with CPython, and we have specifically worked on getting more real world frameworks working on Jython. Some of these frameworks that are working well on Jython are: Pylons 0.9.7, Django 1.0.3 and SQLAlchemy 0.6.0.

We plan to release a 2.5.1 fairly quickly, to round out some of the smaller bugs that we where not able to fix for the 2.5.0 release. After that we will work on 2.6, followed by a 3.x. I don't have any real timelines for these yet.

I also plan to take advantage of the really cool work being done for JDK 7 in the Da Vinci Machine project which aims to improve the support that the JVM has for dynamic languages. Using this work (much of which has already made it's way into OpenJDK) Jython will perform better with much simpler internal code.

Jython is a great platform for Python developers that want to work in a Java environment, and a great tool for Java developers who want to access the highly productive, highly readable, and powerful Python language.