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-08-28 – JyNI-talk at EuroSciPy 2015 in Cambridge
2015-08-17 – JyNI license changed to LGPL
JyNI is now licensed under the LGPL. We made this decision, because LGPL is an OSI-approved license and on the other hand, the difference between LGPL and GPL with classpath-exception only impacts statical binding, which is hardly a use-case for JyNI anyway.
2015-08-11 – JyNI was presented at the JVM Language Summit at Oracle campus in Santa Clara
The JVM Language Summit is an annual event where language designers, compiler writers, runtime engineers and JVM core developers discuss the future of the JVM and the Java programming language. The JyNI presentation is available here; slides will be available online soon.
2015-08-02 – Important note: JyNI’s repository version now requires Jython >2.7.0.
So until Jython 2.7.1 is released (presumably in November 2015) you must build Jython from its latest repository version. See JyNI-readme for a quick-guide (scroll down to section 3).
2015-05-22 – Kick off for Google Summer of Code JyNI-project
Implementing garbage collection support was successfully filed as a GSoC project for summer 2015. Blog available here.
2015-04-22 – lwn.net reports about the JyNI-session at the Python Language Summit
JyNI was presented at the Python Language Summit on April the 8th at PyCon 2015. See report at lwn.net.
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
2013-07-20 – JyNI 2.7-alpha.1 released
Our first release is mainly intended as a proof of concept.
Current release is JyNI 2.7-alpha.2.3.
We aim to meet compatibility with the latest common version of Jython and CPython, which is 2.7 at the moment. 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
- 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 LGPL.
GNU GPL v3 applies by its formulation found at http://www.gnu.org/licenses/gpl-3.0-standalone.html
with the additional GNU LGPL v3 clauses found at http://www.gnu.org/licenses/lgpl-3.0-standalone.html.
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.”
For feedback, questions and feature requests write to firstname.lastname@example.org. For bug reports write to email@example.com. 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).