View on Github

Jython 3 Features and a Viable Minimum

This is a discussion document that attempts to describe, and to some extent prioritise, features for Jython 3, based on suggestions collated from various voices on jython-dev and in off-list e-mail.


We think people will continue to adopt and use Jython if Jython 3 …

The minimum viable product (MVP) is to approach all these targets closely, that is, it isn’t viable if it falls a long way short of any one of them. This does not preclude the availability of immature alpha versions. (It’s a public project, so it is there for anyone to build.)

Version and Forms


These choices, if valid, make a Python byte code interpreter a legitimate MVP.

Platforms and Environments

It is difficult to enumerate the possibilities in a MECE way. It is multidimensional, although not every combination makes sense. Which of the things in this section are MVP?

OS platforms:

Runtime environments:

These are imprecise definitions, but the intention is to run everywhere Java does, and take full advantage of each environment.

At the embedded end of the spectrum, Jython is probably only attractive if Python is not available directly (and Java is, obviously).

Significant Integrations

An unscientific, incomplete list based on projects we have noticed (e.g. via a reported bug).

There is a wider Python ecosystem that does not yet use Jython because they depend on extensions in C. E.g. there is not much in SciPy without numpy.

How do we find the time and collaborators to test integration into these environments? Have we enough understanding to avoid unintentionally making it difficult?


Implementation and API Features

The Java API available for embedding and to extension writers, will be heavily influenced by “internal” implementation choices. Looked at the other way, premature API choices may constrain implementation freedom in undesirable ways.

This is especially true of the object model, since for efficiency’s sake, objects exchanged at the API will be in the implementations we use internally.

This can be less difficult than in CPython because Java gives us good tools for encapsulation: interfaces, packages and modules. (Modules are important here. Many implementation details in Jython 2 became public API, just to cross our own package boundaries.)

Jython 2 Features not to Reproduce