Jpypes dbapi2 module instead of jaydebeapi

[devkral]

Jpype has now an own dbapi2 compatible jdbc module.

Wouldn't it be better to advertise it instead of jaydebeapi?

Many big projects have no python2 support anymore so the jython stuff becomes irrelevant. Even the newest pip would fail.

[Thrameos]

@baztian As the maintainer of JPype, I just wanted to bring this up again.

Coming back to this since @devkral raised it originally — worth noting concretely what's changed since then.

jpype.dbapi2 is a full PEP 249 (DB-API 2.0) implementation, actively maintained. This year I went through and tested it directly against a good number of the open issues in this tracker, to see whether the same problems show up there too: multiple cursors per connection, TIMESTAMP precision, BLOB/CLOB round-tripping, column aliasing in cursor.description, java.lang.Double conversion, reusing an existing java.sql.Connection, ARRAY parameter support. A couple of those turned into real bugs in jpype.dbapi2 itself, since fixed — cursor.description wasn't returning AS aliases, and an Array/Blob/Clob object fetched from one query couldn't be re-inserted as a parameter. It's also documented with worked examples against pandas, Polars, DBUtils connection pooling, and SQLAlchemy (including a jpype.dbapi2-based SQLAlchemy dialect for Apache Drill).

I don't think this repo needs to be declared dead or archived — Jython support is real, and for anyone still on Jython or Python 2, JayDeBeApi is legitimately still the only option there. But that's exactly the case a maintenance notice could make explicit, rather than the repo just going quiet: something like "for Jython/Python 2, use JayDeBeApi; for CPython 3, jpype.dbapi2 is actively maintained and PEP 249-compliant." Right now there's no signal anywhere (README, PyPI page) that this isn't the default answer for the common CPython case anymore, and a lot of years of Stack Overflow answers point here regardless of runtime — which increasingly means AI-assisted answers do too, since they're trained on exactly that history. A short note would help people self-select correctly without taking anything away from the Jython use case this project still serves.