Maintainers needed

[bartdag]

Hi everyone,

It is becoming difficult to maintain Py4J alone and I would like to invite contributors to become Py4J maintainers.

The landscape has changed remarkably since Py4J was first created and as a dad, CTO of a growing company and mostly python programmer, I just cannot keep up with the support requests, new Java & Eclipse versions, and the constantly changing build ecosystem.

For example, Java 11 is a fundamentally different beast than Java 8, bintray (where I host Py4J eclipse artifacts) is closing, and Travis-ci.org is moving to Travis-ci.com.

I see this transition phase as a three-step process:

1. Selecting maintainers and continuing the usual maintenance work
2. Moving to a GitHub organization
3. Publishing a Py4J 1.0 or 2.0

If you are interested, please reply to this issue or contact me at barthelemy at infobart dot com

Selecting maintainers and continuing the usual maintenance work

I am looking for contributors who will help maintain Py4J by:

1. Submitting pull requests to contribute code, documentation or infrastructure changes
2. Helping merge pull requests submitted by other contributors
3. Answering support requests on GitHub issues and the mailing list
4. Striving to preserve good test coverage
5. Striving to preserve backward compatibility at all cost as long as Py4J is on the 0.x version path.

After 10 successful actions involving code or documentation, I would give commit access to the contributor and publicly recognize them on the Py4J readme file and website.

After we have our first maintainer, code contribution from maintainers (myself included) should always be performed through pull requests before being merged into master.

Moving to a GitHub organization

When we have enough maintainers (e.g., a super active maintainer or a few active maintainers), we would move all Py4J-related projects to a GitHub organization.

Ideally we would also find a way to give access to the various release platforms to at least one other key maintainer. This would allow a maintainer to perform release engineering and I would no longer be the bottleneck when releasing a new Py4J version.

Publishing Py4J 1.0 or 2.0

I would like the Py4J team to publish a 1.0 version of Py4J that is backward compatible with 0.x.

But if we want to support Java 11 and generate interest for more contributions, I don't think it is realistic to preserve backward compatibility. I would probably suggest to start fresh with Py4J 2 and remove a lot of the accumulated cruft (the net.sf package name, support for Python 2.x).

Maintainers would be the ones providing the direction for Py4J 2.

A word about backward compatibility

I very much agree with Linus Torvalds when he says "If a change results in user programs breaking, it's a bug in the kernel."

The value of a piece of software that you can upgrade with full confidence that you have nothing to change in your own software is incredible. It means extra work for the maintainers and it means crystalizing as features bad design decisions and long-standing bugs. But it also means that your users trust you because they know that you have their back, that you are not always chasing the latest fad, and that you are not constantly forcing them to spend their valuable time upgrading their code instead of developing useful and cool features.

Py4J is not dead or abandonware

Py4J is a mature library that is used in many environments by novices and experts alike. I am still reviewing pull requests, answering questions, and publishing new releases, but I am doing this only a few times per year. I also favor issues or pull requests that are well articulated and that come with reproducible error cases. A bigger team would be able to update the library more frequently, merge more contributions, and answer more questions.

[Thrameos]

Sorry to hear that this project is struggling. As the only gateway style solution for Python to Java it would be good for the community if this project is continued. I frequently point people here when a linked process bridge such a JPype is not appropriate.

[bartdag]

Hey, thanks for the comment! I updated the text to mention that Py4J is not dead: I will continue to publish new releases, but they may not be as frequent as some users would like.

[jonahgraham]

@bartdag I have forwarded this onto the EASE folk (via ease-dev) as they are quite reliant on py4j.

[johann-petrak]

I think the most important task is figuring out if and how py4j needs to get adapted to work with newer Java versions (if at all, these appears to be not at all clear yet judging from issue #403). I would be prepared to help with this as far as I can -- we are using py4j for the gatenlp library and would be happy to keep using it while supporting all new Java versions. The other thing that would be very important to us is additional proxy objects for Java types not distinguishable in Python, e.g. Long as it seems to be impossible to invoke Java methods overloaded on these types right now.

[RaiMan]

@bartdag
Hi, I am RaiMan from SikuliX.
Currently I am busy, to get my version 2.0.5 out till end of February. After that I already planned to get on with a Python bridge. Already 2 years ago I decided to use py4j (my project sikulix4python), since the server concept has many additional advantages over just being a java-python bridge (mainly access to other machines and/or virtual stuff).
So when I get back to this during March, I will try to contribute to py4j. First I will get an impression, how py4j behaves with Java 11 and 15 and report back. More things might follow.

Congratulations to this very professional and clear call for helpers/contributors. All the best.

[fmzone]

Hope more Maintainers joined,i think it's more better than jython.

[hariharansrc]

I am interested in contributing to this project. Please guide me on how to contribute to this project.

[HyukjinKwon]

@bartdag, I am interested in maintaining this library. it would be great to find a timeslot and have a short discussion.