Re: JDBC 4 Compliance

Dave Cramer-8 wrote

2) Maintenance Mode
You can tell the code is in maintenance mode just by reading it.  I won’t
repeat my previous discussions about the state of the code now but there
is
quite obvious code rot going on as features are slapped together in the
most fragile of ways. I believe that is what any project in “maintenance
mode” gets; just another name for a project experiencing code rot.  It
seemed obvious to me, both then and now, that working within the current
framework was going to take a lot longer than just rolling a new one;
that
comes from somebody who now has a near complete implementation of
java.sql.Driver.

I cannot seem to get a coherent thought going here but just some thoughts
for everyone to consider.

I think one of the biggest changes that could be made, given that the
current driver has accumulated so much technical (and process) debt - not to
mention the stability that it needs - would be for the PostgreSQL Global
Development Group to become not only the maintainer of the current driver
but also a trusted resource that PostgreSQL+Java users can rely upon to help
them evaluate the various implementations of the JDBC driver that exist to
meet the diverse needs of the community.  It should enforce minimal
standards by creating a black/white lists with specific details as to
missing mandatory features or structure (i.e., licensing; timely response to
community feedback like pull requests; etc...).

The goal should be to identify one or more reference implementations for the
current pair of JVM+PostgreSQL and assist whomever "maintains" that
implementation.  This implementation should try to strive for backward
compatibility but implementing all the specification/database features is of
a higher priority.  

As a user I would want an idea of the trade-offs between different
implementations to aid in researching and some guidance on how to properly
evaluate different drivers in my custom environment.

Without a strong JDBC community the attractiveness of PostgreSQL as a
back-end is going to stagnate.  Technological innovation is needed but the
way it is occurring right now has the downside of giving off a "fracturing"
vibe.  The programmers are not going to be able (or want) to solve that part
of the puzzle.  Ideally one of the vendors who wants to innovate on the
driver could take some of these observations and leverage it into something
they can earn money on (likely via consulting on things like performance -
and other kinds of - testing).

I am likely a typical user which means that the status-quo really hasn't
been something that I've said to myself that there is a problem.  Mailing
list traffic is pretty light and because it is in maintenance mode there
just isn't much excitement in being noisy just to tell people you are still
alive.  Putting things into core indeed has a high barrier but that is
because the vast majority of people simply look at the current driver as
being canon and want their existing software to continue working the way it
did on the last version.  Thus some form of forking is going to be required
- the question is who creates and maintains the forks and how long should
they survive.

Sorry for the rambling especially since I'm not currently planning to
actually act on my own advice but hopefully people will find some value in
my perspective.

David J.






--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5760763.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.


-- 
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc