[Question to the community] Removing jasync modules?

[guizmaii]

Who's using the jasync modules?
What if I tell you that I want to remove them?
Why did you make the choice to use the jasync backend over the JDBC one?

I'm personally using Quill for several years, in different projects and companies and I've never used anything else than the JDBC backend, considering it a safer choice.

Why am I considering removing the jasync modules?

1. Because there's a deadlock somewhere there. Either in the code or, if we're lucky, in the tests.
   (But probably in the code, see https://x.com/lukasz_bialy/status/1707341633929314347?s=20)
   We can clearly see the jasync CI deadlock sometimes (not that uncommon at all)

2. Because maintaining Quill is already challenging, so I'm trying to remove as many things as possible to improve the life of the Quill maintainers.
   This module feels like a duplicate of the JDBC one to me and apparently it has issues (deadlock in CI + issues reported by users)

3. If I understood correctly the talk of JDG at ZIO World 2023, the "blocking" JDBC way will be the one to prefer/the most performant one with Java 21 and virtual threads (See https://youtu.be/ygOmwze5ETk?si=r_GT4p4j_D6C0aHv)

[gabfssilva]

I haven't been closely following the Scala world recently. However, my 2 cents: what about r2dbc support instead of jasync? r2dbc is a pretty mature API, it has some official drivers, and it also supports reactive streams. I'm not sure if the jdbc stream API matches the quality of r2dbc, but maybe with Loom support, it wouldn't matter anyway. Still, it'll work only on Java 21+.

[guizmaii]

what about r2dbc support instead of jasync?

Our goal here is not to find a replacement for jasync
Our goal is to simplify the life of the people making and maintaining Quill on their free time by removing unnecessary stuff from the Quill codebase

[guizmaii]

@juliano I think we gave enough time to people to manifest themselves now. No one came here nor on Discord so I guess it's fair to consider that we can safely remove the JAsync support

[juliano]

@guizmaii both PRs for quill and protoquill updated

[guizmaii]

I gave a last chance to people on Twitter/Discord. Let's merge them tomorrow morning if no one manifested him/herself

[guizmaii]

JAsync support as been dropped

[ddw-tsc]

For what it's worth now, yes, we are using this. Even with a MariaDBZioJAsyncContext built by extending the MySQLDialect to an MariaDBDialect and mixing in other parts for the JAsync stuff.

Obivously open source maintainers are free to drop whatever they want when they want to. But 3 weeks from "giving notice" by raising a GitHub issue to removing the feature is quite a short time. Nothing to do about it of course by now.