JyNI Native

short Title info full Interface

logo title author Stefan Richthofer contact email Contact [email protected] description info Non- home www.jyni.org technical info

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

Wanna usage capabilities JyNI is currently available for only. Once it is sufficiently complete and stable, we will work out a read technical cross platform version compilable on Windows, MacOS info? and others. Thanks to Jython's hooking capabilities, it is The following built-in types are already supported: sufficient to place JyNI.jar on the classpath • PyString • PyBool • PyComplex • PyFrozenSet (and some native libraries on the library • PyTuple • PyInt • PySlice • PyClass yes path) when Jython is launched. • PyDict • PyLong • PyModule • PyInstance Then Jython should “magically” be able to • PyList • PyFloat • PySet • PyMethod load native extensions, as far as the needed Usage, Python -API is already implemented by JyNI. • Singletons PyNone, PyNotImplemented, PyEllipsis implementation, • Natively defined types up to some constraints No recompilation, no forking – it just works The function families PyArg_ParseTuple and capabilities? with original Jython and original extensions. Py_BuildValue are also supported.

implementation overview To create JyNI we took the source code of CPython 2.7 and stripped away all functionality that can be provided by Jython and is not needed for mirroring objects (see below). We kept the interface unchanged and reimplemented it to delegate calls to Jython via JNI and vice versa. Overview, Object The most difficult thing is to present JNI-jobjects from Jython to extensions such that object sync and synchronization they look like PyObject* from Python (C-API). For this task, we use the three different lookup by mirroring or approaches explained below, depending on the way a native type is implemented. wrapping. object sync object lookup Python wraps Java Java wraps Python objects are mirrored

To lookup the corresponding jobject of a This is the basic approach. It This approach is the only If the Python C-API provides PyObject*, we prepend an additional is not feasible if the C-API way to deal with types macros to access an header before each PyObject in memory. provides that are object's (If a PyGC_Head is present, we prepend access PyObject* unknown data, the PyObject* PyObject* our header even before that.) to the to Jython, object is object's i.e. types mirrored. meta ... jobject, flags, (PyGC_Head) PyObject ... structure natively Since info jobject via definded most PyObject* jobject macros. by an of such To reserve the additional memory, jobject extension. objects allocation is adjusted wherever it occurs. Examples: are The other lookup-direction is done via a PyDict, PySlice, PyModule Example: PyCFunction immutable, an initial hash map. data-synchronization is often sufficient. license roadmap The main goal of JyNI is The next steps toward this goal compatibility with NumPy are support for exceptions, the Examples: JyNI is available under the GNU GPL v. 3 and SciPy, since these remaining built-in types and PyTuple, PyList, PyString, with classpath exception. See www.jyni.org extensions are of most garbage collection. Cross- PyInt, PyLong, PyFloat, for more details. scientific importance. platform support will be ad- PyComplex dressed as a subsequent goal. Copyright © 2013 Stefan Richthofer