JyNI – Jython Native Interface

JyNI is a compatibility layer with the goal to enable Jython to use native CPython extensions like NumPy or SciPy. This way we aim to enable scientific Python code to run on Jython. Since Java is rather present in industry, while Python is more present in science, JyNI will be an important step to lower the cost of using scientific code in industrial environments.

Our philosophy is to integrate JyNI with Jython and CPython extensions as seamless as possible. So JyNI aims to work without any recompilation of Jython or the desired CPython extensions. It neither requires a customized Jython version, nor customized versions of the CPython extensions (of course your JyNI version must match the platform your CPython extension was built for). Simply put JyNI.jar on the classpath (along with its native libraries) and Jython should “magically” be able to load native extensions, as far as the needed Python C-API is already implemented by JyNI.


2015-04-13/14/15/16 – PyCon coding sprints: Come sprint with us on JyNI.

Learn about Python’s C-extension API, see Jython in action and more. Also newbies are welcome, but you should be able to roughly read C-code. We will work closely with Jython sprinters, so feel encouraged to take a look at Jython sprints too. See PyCon sprints page.

2015-03-18 – JyNI 2.7-alpha.2.3 establishes compatibility with Jython 2.7 beta 4

Apart from this it has minor internal improvements, but nothing notable for users. Note that it won’t work with earlier Jython versions than 2.7 beta 4. Get it...

2014-09-06 – Support for Jython 2.7 beta 3 provided (JyNI 2.7-alpha.2.2 released)

alpha.2.2 is essentially identical to alpha.2.1, but brings compatibility to Jython 2.7 beta 3, which was broken because of some minor API changes. Note that alpha.2.2 definitely won’t work with Jython versions prior to 2.7 beta 3. (One can still use alpha.2.1 for such versions.) Get it here...

2014-05-01 – Proceedings of the 6th European Conference on Python in Science (EuroSciPy 2013) released

Feel free to read the JyNI paper. It presents rich information around JyNI along with examples, an overview how the implementation works and what the next steps will be. The complete proceedings are available here.

2014-03-29 – JyNI supports Tkinter (JyNI 2.7-alpha.2.1 released)

New features are support for PyFunction, PyCode and heap-types along with various bug fixes. This version of JyNI is capable to run (at least basic) Tkinter code. Check it out...

2013-10-28 – JyNI 2.7-alpha.2 has been released!

Main features are full exception support and support for the original datetime module. Though Jython features an own implementation of datetime, support for the original module is a step toward NumPy, because the original datetime features a C-API that is used by NumPy. Read the release note on JyNI 2.7-alpha.2 for more details.

2013-08-23/24 – JyNI was presented at EuroSciPy in Brussels, Belgium

See abstract and poster.

2013-07-20 – JyNI 2.7-alpha.1 released

Our first release is mainly intended as a proof of concept.

Current State

We aim to meet compatibility with the latest common version of Jython and CPython, which is 2.7 at the moment. Thus we develop and test JyNI with Jython 2.7beta 3. Please have this in mind when trying it out. JyNI does not yet support the complete Python C-API. The following builtin types are currently covered:

  • Number types PyInt, PyLong, PyFloat, PyComplex
  • Sequence types PyTuple, PyList, PySlice, PyString, PyUnicode
  • Data structure types PyDict, PySet, PyFrozenSet
  • Operational types PyModule, PyClass, PyInstance, PyMethod, PyFunction, PyCode, PyCell (partly)
  • Singleton types PyNone, PyNotImplemented, PyEllipsis, PyBool
  • Native types PyCFunction, PyCapsule, PyCObject
  • Natively defined custom types (you cannot (yet) subclass them in Jython)
  • Exception types
  • PyType as static type or heap type


  • PyWeakReference
  • Support for new-style classes/instances

As long as one sticks to the already supported types, the function families PyArg_ParseTuple and Py_BuildValue should also work.

JyNI is not yet cross platform – it is developed on Linux Mint Debian Edition 64 bit. We compiled and tested it successfully for

  • Linux Mint Debian Edition (LMDE) (32 bit and 64 bit)
  • Linux Mint 13 (64 bit)
  • Ubuntu 13.10 (64 bit)

So it is very probable that it would also work on other distributions, at least on Debian- and Ubuntu-based ones. OS X and Windows are not yet covered, but we will work out a cross platform version when the basic functionality is sufficiently complete and stable on our development platform.


For JyNI v2.7-alpha.3, we aim to support garbage collection and the original ctypes module. However, the main milestone we aim for is compatibility with NumPy. When it is reached, we will declare JyNI to have beta state and focus on cross platform development. The next milestone will then be support for Windows and OS X, which will mark JyNI release version 1.0.


JyNI is released under the GNU GPL. To allow for commercial use, we append the classpath exception like known from GNU Classpath.

GNU GPL v3 applies by its formulation found at http://www.gnu.org/licenses/gpl.html.

The formulation of the classpath exception is as follows:

“Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.”

We were frequently asked, why not LGPL, respectively what the difference to LGPL is. Please feel free to read details about the classpath exception and notes on the differences to LGPL here (Wikipedia).

EuroSciPy 2013

JyNI was presented at EuroSciPy on the 23rd and 24th of August 2013 in Brussels, Belgium with the following abstract:

“Jython is a Java-based Python implementation and the most seamless way to integrate Python and Java. However, it does not support native extensions written for CPython like NumPy and Scipy. Since most scientific Python-code fundamentally depends on exactly such native extensions directly or indirectly, it usually cannot be run with Jython. JyNI aims to close this gap. It is a layer that enables Jython-users to load native CPython-extensions and access them from Jython the same way as they would do in CPython. In order to leverage the JyNI functionality, you just have to put it on the Java-classpath when Jython is launched. It neither requires you to recompile the extension-code, nor to build a customized Jython-fork. That means, it is binary compatible with existing extension-builds.

At the time when this abstract is written, JyNI does not fully implement the Python C-API and we are in fact just capable to load simple examples that only involve most basic builtin-types. The concept is rather complete though and our goal is to provide the C-API needed to load NumPy as soon as possible. After that we will focus on SciPy and others.

We expect that our work will also enable Java developers to use CPython-extensions like NumPy in their Java-code.”

The corresponding EuroSciPy page can be found here. The conference poster can be found here.


There was a JyNI-paper released in the proceedings of EuroSciPy2013 on 2014-05-01. A direct link to the PDF is available here.


For feedback, questions and feature requests write to contact@jyni.org. For bug reports write to bugreport@jyni.org. Please don’t report obvious issues resulting from not yet implemented API (see section “Roadmap”) as bugs. Please DO report, if JyNI appears to be not buildable on a presumably supported platform or if the demos don’t run as expected (don’t forget to provide output of the build- or the demo-run).