Request for collaboration on Cross-Language Garbage Collection

[Thrameos]

I am the developer of JPype which is a Python to Java bridge. As one of my developement tasks I am trying to fix the age old problem of cross language irresolvable reference loops. Your project was mentioned as one of those which may benefit from such a capability in Python. If any would like to participate in discussions on how we can implement hooks to support automatic reference loop detection and resolution please participate at

https://discuss.python.org/t/support-for-cross-language-garbage-collection/91055
jpype-project/jpype#1296

[mhsmith]

Thanks, I've responded in the discuss.python.org thread.

[Thrameos]

Thanks for the comment. Hope I answered your question. I was unaware of the library until recently as it never popped up on my searches. I am left to wonder though given it has a nearly identical api on the Python side why didn't it merge with JPype. I have been trying to maintain Andriod support for past 8 years but don't have any assistance and my Python to Java bridge is integrated far beyond all others. This should have been tagged as an overlap with our 25 year old project.

Regardless, I recommend submitting a section for the JPype userguide alternatives section so at least users can see it when shopping for bridge code.

[mhsmith]

Chaquopy originated in early 2017, when JPype was relatively inactive. Since Android's primary language is Java, there was also a need for the bridge to be bidrectional from the start, making it as easy as possible for Java code to access Python objects. So JPype didn't seem like a good option at the time.

In fact, Chaquopy's language bridge started off as a fork of PyJNIus, which wasn't being very actively maintained back then either, although almost every line of code has been rewritten by now.

Chaquopy's scope is quite a bit more than just a language bridge, as it also includes a large amount of Android-specific build and runtime support.

[Thrameos]

I am still down for merging at some point. Or at least incorporating those android features into Jpype once we complete our reverse bridge capabilities.

Sadly 2015 to 2017 was stagnant years for JPype. I starting 2018 and evaluated all java bridges at the time. PyJNIus segfaulted at the slightest deviation from expected so I gave up after 2 days. JPype had a few holes at the time but was a much better integrated to numpy and it took me 2 months to start hitting a frayed section. I have worked to cover all those holes and am now at the very limits of behavior integration like gc behavior merging and io file integration. There are a great number of areas that just aren't covered by PyJNIus code base. Feel free to browse and borrow or try running our test bench through an AI to make follow yours. Last I time I ran JPype test bench through was 5 years ago (and I had to convert most stuff by hand), I hit over 20 srgfault behaviors in PyJNIus..

PS. Those extras are all the more reason it should have a entry in JPype alternates as I steer people to PyJNIus for android support.