JPMS (aka fully modular driver)

[jorsol]

Hi, this is just an idea to the air to talk about the potential use of having a fully modular driver.

There are some benefits of having a modular driver, one of them is better encapsulation, we don't need to expose all the API to end-users, and reorganizing the code is already a great benefit, one small drawback is that it's obviously a breaking change, but IMO the benefits outweigh the drawback.

Having modules could help a lot in having a more maintainable driver, imagine optional features don't need to be baked into the core, and just plugged in, and some modules that are not maintained could be simply dropped.

The extensions API could be provided by different modules, so if you need the COPY API, add a module, the Replication API add a module, etc.

Not fully module related, (but also in the same scope), add a jar (module) with support to get the pluggable types for Jackson, or Gson, or jakarta.json...

This could imply many, many (many...) hours of discussion and code changes to reach a state of having clean code and a good API, but it probably worth it in the long run.

[sehrope]

We had some talk about this a few years back and IIRC everybody was in agreement that it'd be better overall with an JDBC layer atop a Postgres specific driver. I don't think it's possible to evolve the current driver code to that point though. It'd be much too invasive, too risky for backwards compatibility, and too slow to build it by changing this driver. If anything, it'll be a new driver project from scratch that eventually supersedes this one.

[davecramer]

I've been kicking around the "new driver from scratch" idea for quite some time. Given the complexities of the current one I think evolving it is going to work better. To this end I think one approach would be to make it so we could plug in different stream handlers. In my mind the goal would be to make it non-blocking.

[jorsol]

More than starting from scratch, I think evolving it is going to work better too. Making incremental changes, reorganizing code, and split modules (even if at the beginning they are not real "java modules") would make more sense to me... and yes, this will be invasive and definitely backward-incompatible with the current API, but in the end, it could pay off.

And what I mean by backward-incompatible is the extensions API, if users only touch the JDBC API then 99% of the cases should be working just fine. And yes, in the end having a modular driver could probably allow the change to a non-blocking stream handler (but I'm not sure of the benefit for the JDBC API).