Jyni

- Linux Mint Debian Edition (LMDE) (32 bit and 64 bit)
- Linux Mint 17 (64 bit)
- Mac OS-X (10.10 and 10.11)


v2.7-alpha.2.3
JyNI alpha 2.3 brings compatibility with Jython 2.7 beta4.
Internally it has some minor improvements over alpha 2.2, some of them were just enabled by Jython 2.7 beta4, but nothing notable for users.
- JyNI alpha 2.3 requires Jython 2.7 beta4 and won't run with earlier releases
- JyNI alpha 2.3 was tested on the same systems as alpha 2.2

See JyNI alpha 2.2 release notes for warnings about garbage collection etc. These still apply.


v2.7-alpha.2.2
This release is essentially equal to alpha.2.1, but brings compatibility to Jython 2.7 beta 3. While earlier JyNI-releases are incompatible with Jython 2.7 beta 3, this release actually requires it and won't run or compile with earlier Jython versions. Further, a unittest (test_JyNI.py) was added, essentially testing the capabilities demonstrated in JyNIDemo.py, JyNIDatetimeTest.py and JyNIExceptionTest.py.

JyNI 2.7-alpha.2.2 has been tested with
- Jython 2.7 beta 2 (confirmed it does not run with it)
- Jython 2.7 beta 3

on
- Linux Mint Debian edition (LMDE) (32 bit and 64 bit)
- Linux Mint 13 (64 bit)


v2.7-alpha.2.1
JyNI 2.7-alpha.2.1 is an intermediate release to demonstrate JyNI's new Tkinter capabilities.
Main improvements over alpha.2 are support for heap types and the introduction of a JyNI-GIL (global interpreter lock) to mimic CPython's GIL behaviour.

JyNI's "GIL" is not really global since it is scoped on native code (i.e. there can always be multiple threads in Java, but there can only be one thread in native extension-code at the same time, unless one uses Py_BEGIN_ALLOW_THREADS-macro). It is always acquired when a thread enters JyNI's native part and released when it enters Java code again. This way we aim to keep Jython-code free from multithreading regressions (Jython has no GIL because it uses Java's threading architecture), while native extensions get familiar GIL-induced behaviour in their native code.

Further built-in types are now supported: PyFunction, PyCode and (partly) PyCell. Additionally there were significant improvements for the support of PyType (these came with the support for heap-types).

JyNI alpha 2.1 was developed with the explicit goal to support Tkinter. It was tested with basic Tkinter code and the priority of bug-fixing was focused on the C-API needed by Tkinter. Nevertheless this resulted in numerous bug fixes giving benefit also to every other native extension.

The state of native garbage collection did not change since the last release (I promised GC support for alpha.3. This is why this release is called alpha.2.1 rather than alpha.3 ;-) ). So the advice from the last release is still relevant:
JyNI should not be used for more than demonstration purposes, since it would potentially leak a massive amount of memory if an extension crucially relies on garbage collection.

JyNI alpha 2.1 has been tested with
- Jython 2.7 beta 1
- Jython 2.7 beta 2 (pre-release)

on
- Linux Mint Debian edition (LMDE) (32 bit and 64 bit)
- Linux Mint 13 (64 bit)

If you compiled it for another distribution, please consider to report your experience to
contactjyni.org. If you are using a distribution not listed above, we would also appreciate
any feedback, whether you got the binaries working or what error you received if any.

Release alpha 2 contains significant improvements over alpha 1. The main new feature is full
exception support. Exceptions filed in native code via Python C-API are translated to Jython
exceptions and can be accessed just like if they were generated by Python code. We added
a simple demo script JyNI-Demo/src/JyNIExceptionTest.py to demonstrate this (did not want
to mess up JyNIDemo.py with exception stuff).

Additionally, we support some new built-in types, compared to alpha 1. These are PySet,
PyFrozenSet, PyUnicode, PyClass, PyInstance, PyMethod and all built-in exception types.
Also the support of PyType was significantly improved.

One milestone in direction NumPy/SciPy is that JyNI is now able to use the original datetime
module. Jython features an own implementation of the datetime module, so this does not pay
off in new functionality right now. However, the original datetime module contains an own C-API
section that is not provided by Jython's version. Since NumPy uses this C-API, we will have to
use the original module. That JyNI alpha 2 is capable of using it, is demonstrated in
JyNI-Demo/src/JyNIDatetimeTest.py.

Another important improvement is that we finally managed to provide a makefile. Building JyNI is
much easier now. However, it is not as comfortable as an autotools-script - you may have to
adjust some variables in the makefile by hand, depending on your system. Mainly, you have to
specify, where Java and Jython can be found. Detailed instructions on building and using JyNI
are provided in the readme.

What still does not work is native garbage collection. We are going to address this in the next release. However, until garbage collection works, JyNI should not be used for much more than
demonstration purposes, since it would potentially leak a massive amount of memory if an extension crucially relies on garbage collection.

JyNI alpha 2 has been tested on
- Linux Mint Debian edition (LMDE) (32 bit and 64 bit)
- Linux Mint 13 (64 bit)
- Ubuntu 13.10 (64 bit)

If you compiled it for another distribution, please consider to report your experience to
contactjyni.org. If you are using a distribution not listed above, we would also appreciate
any feedback, whether you got the binaries working or what error you received if any.

Release alpha 1 is mainly intended as a proof of concept. A major lack is a smooth way to build it, since I did not setup any autotool-stuff yet. However, there are binaries for Linux Mint Debian Edition (LMDE) 64 and 32 bit. I could test the 64 bit one also on Ubuntu-based Linux Mint and it ran just like on LMDE, so it should work for Ubuntu as well. I suppose it would also work on other distributions. Additionally, the README contains some build instructions if you want to build JyNI yourself.
Don't expect it to be usable for much more than seeing that it works. Try out the demo extension and modify it like you want. The README tells you what should work and what not.
Unfortunately, behind the scenes the garbage collection is still broken, so native objects are not collected. For the demo-extension, this does not matter, but as I said - don't expect it to be usable for much more in this release.

Quickguide to run the demo using the binaries:

Extract JyNI-Demo/src/JyNIDemo.py from the sources.
To launch it with CPython, extract DemoExtension.so from the bin archive (32 or 64 bit, whatever is appropriate for your system).
JyNIDemo.py adds the extension folder via sys.path.append([path]).
You can modify that line so it finds your extracted DemoExtension.so or delete the line and put
DemoExtension.so on the pythonpath.
If you launch JyNIDemo.py with Jython, it won't work.
Put JyNI.jar, libJyNI-Loader.so and libJyNI.so on Jython's pythonpath or classpath.
libJyNI-Loader.so and libJyNI.so can alternatively be placed somewhere on the Java library path.
Jython should now be able to run JyNIDemo.py.
This has been tested with Jython 2.7 beta 1. I believe, it would not work with older Jython versions, but haven't tried.