Skip to content

Releases: Stewori/JyNI

v2.7-alpha.5

21 Sep 20:13
Compare
Choose a tag to compare
v2.7-alpha.5 Pre-release
Pre-release

JyNI 2.7-alpha5

With JyNI alpha 5, we proudly present the first version of JyNI that runs on Windows.

The main part of this release was developed within a Google Summer of Code project. We thank Google a lot for this wonderful program! For details about the development process including its numerous demanding issues, take a look at the GSoC blog of this project.

New features

The most notable new features include:

  • JyNI now builds and runs on Windows using a makefile-based toolchain and MSVC for Python 2.7
  • ctypes, NumPy and Tkinter were explicitly asserted to work on Windows equally well as on POSIX (i.e. up to known limitations)
  • improved support of PyFile API by Christian Weilbach's contribution
  • improved management of built-in extensions – datetime, _winreg, msvcrt are now built-in
  • support of the _winreg module allows automatic detection of CPython's dll folder on Windows
  • our new module config_util automatically configures paths for CPython's dynamic library folder and lib-tk folder in a platform-independent fashion
  • Tkinter on Windows – not as trivial as it might seem, Tkinter is enabled to properly auto-detect the location of Tcl, Tk and Tix bundled with a CPython installation
  • mbcs support – JyNI now adds the mbcs encoding to Jython (Windows only)
  • JyNI provides putenv implementation in Jython – os.environ now actually calls the system's underlying putenv function on write access
  • JyNI enables sys.winver and sys.dllhandle fields for Jython on Windows
  • various bugfixes

Requirements and platform support

JyNI v2.7-alpha.5 requires Jython 2.7.1.

JyNI v2.7-alpha.5 was tested with Java 7 and 8 on

Binaries are provided for Linux, OS-X and Windows.

Thank you

Thanks go to

Note on NumPy 13.2

NumPy 13.2 is not supported by JyNI alpha 5 due to issues in Cython 0.27.
Please move on directly to NumPy 13.3, where this issue was fixed.

For details see numpy/numpy#9786 and #20.

Note on NumPy 14.x

The NumPy 14 series does not work with this release of JyNI.
Please stick to NumPy 13.3, which is the latest NumPy release known to work with JyNI. We hope to fix issues with NumPy 14 (and 15) in the next release.

For details see #22.

v2.7-alpha.4

14 Jun 22:30
Compare
Choose a tag to compare
v2.7-alpha.4 Pre-release
Pre-release

Welcome to JyNI v2.7-alpha.4!

Among plenty bugfixes, the most notable new feature is support for NumPy (>= 1.12). Not everything is working already, but it is possible to import numpy, create nd-arrays, apply arithmetics to them, do eigenvalue decompositions and things alike. We still observe issues with subclassing nd-array and also the lack of buffer protocol support locks out various features.
For details and examples, follow the discussion at #2.

Another important new milestone in this release is support for new-style classes.
In combination with improved ctypes support this allows to use PyOpenGL in Jython. We still observe issues on OSX, but most test-demos work on Linux. Note that on first run Jython will prompt you to create some .pyc-files using CPython. This is Jython's current way to handle Python functions that exceed JVM size limits; PyOpenGL contains several of them.

Extensions generated via Cython are mostly workable (e.g. mtrand from NumPy). However, cythonizing pyx-files is not yet feasible with Jython, but can be done with CPython to build native libraries initially. Once the .so files are compiled, make sure Jython has them in its sys.path, then JyNI can load them into the JVM.

For a more detailed write-up of some usability demos and implementation techniques, especially regarding garbage collection and weak references, see the publication

Garbage Collection in JyNI – How to bridge Mark/Sweep and Reference Counting GC., Proceedings of the 8th European Conference on Python in Science (EuroSciPy 2015), CoRR abs/1607.00825 (2016)

It features a NumPy example and also shows how to embed Python calls seamlessly into Java code (Tkinter demo).

Some improvements to Jython were triggered by work on this JyNI release. Most notably, it is now possible to control how platform detection values os.name and sys.platform are presented to specific extensions.
Improving support for oversized functions like mentioned above was also motivated partly with native extensions in mind.

JyNI v2.7-alpha.4 requires Jython 2.7.1.

JyNI v2.7-alpha.4 was tested with Java 7 and 8 on

Binaries are provided for Linux (32 bit and 64 bit) and OS-X.

Thank you

Thanks go to

v2.7-alpha.3

16 Feb 03:07
Compare
Choose a tag to compare
v2.7-alpha.3 Pre-release
Pre-release

Right in time for Jython 2.7.1 we are proud to announce the release of JyNI v2.7-alpha.3, which is quite a milestone. Packed with new features and improvements it finally masters to bridge Jython's and CPython's garbage collection mechanisms. A lot of work went into this release, including an entire Google Summer of Code project (see http://gsoc2015-jyni.blogspot.de). Take a look at the main milestones:

  • garbage collection for native objects is implemented, plus a mechanism to (unit-)test it
    (see upcoming paper "Garbage Collection in JyNI – How to bridge Mark/Sweep and Reference Counting GC in Proc. of the 8th. European Conference on Python in Science (EuroSciPy 2015)" for further reading on this topic)
  • JyNI is now also workable (and tested) on Mac OS-X (the Tkinter demo currently fails, see #4)
  • the ctypes extension is supported (many original ctypes unittests currently fail though, but mostly due to secondary issues; the core functionality is working, a demo-script is provided)

The road to these milestones is paved with bugfixes, extended API support and several design improvements. To name a few:

  • The referencing scheme was cleaned up and now follows clear rules in line with JNI requirements.
  • Support for weak references and corresponding builtin types was achieved.
  • The handling of subtypes was improved, which incorporated massive work in typeobject.c
  • ThreadState API was improved - e.g. the PyGILState_xxx method family is now supported in a Jython consistent way. Threads are attached or detached to/from the JVM properly (c.f. JNI methods AttachCurrentThread and DetachCurrentThread). This incorporated a redesign of how JyNI handles SystemState, ThreadState and the GIL.
  • It is now possible to use JyNI from pure Java-code, which was originally hindered by several bugs. The upcoming EuroSciPy 2015 paper about JyNI features a rich example of this (see JyNI.TestTk.java).
  • The work on JyNI also triggered improvements on Jython, e.g. PyDictionary and PyStringMap were unified under a common abstract class and most work on the gc module is grounded in JyNI development.

JyNI v2.7-alpha.3 requires Jython 2.7.1. You can currently use it with Jython 2.7.1 beta3, available on Frank's blog: http://fwierzbicki.blogspot.de/2016/02/jython-271-beta3-released.html

JyNI v2.7-alpha.3 was tested with Java 7 and 8 on

  • 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

18 Mar 01:00
Compare
Choose a tag to compare
v2.7-alpha.2.3 Pre-release
Pre-release

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

05 Sep 22:02
Compare
Choose a tag to compare
v2.7-alpha.2.2 Pre-release
Pre-release

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

02 Apr 01:04
Compare
Choose a tag to compare
v2.7-alpha.2.1 Pre-release
Pre-release

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
contact@jyni.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.

v2.7-alpha.2

28 Oct 13:56
Compare
Choose a tag to compare
v2.7-alpha.2 Pre-release
Pre-release

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
contact@jyni.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.

v2.7-alpha.1

18 Jul 10:36
Compare
Choose a tag to compare
v2.7-alpha.1 Pre-release
Pre-release

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.