Re: JDBC 4 Compliance

John R Pierce wrote
> On 6/24/2013 4:18 PM, Kevin Wooten wrote:
>> Second, porting my implementation back to Java 5/6 and/or PostgreSQL
>> servers prior to 9.2.  The current driver has lots of special case
>> code for servers and now JDK’s that have been EOL’d.  My project
>> implementation currently has none, it runs on JDK 7/JDBC 4.1 and
>> Postgres >= 9.2.  I believe there is a more elegant way to handle
>> these cases going forward than the option used in the mainstream
>> project of abstract/concrete classes for each JDBC version. I think
>> JDBC differences should be handled with the maven pre-processor plugin
>> to conditionally compile for each JDBC. Server differences can still
>> use special case code and/or polymorphic classes to address the
>> problem/feature at hand.
>
> speaking as a user and system administrator, I would NOT want to need to
> use different JAR files for each {jvm,postgres} version. that would be a
> nightmare.
>
> we have a LOT of systems in our manufacturing operations that are
> running older versions of {os, postgres, jvm} for various reasons, not
> the least of which is upgrades often break things in very non-obvious
> ways.

I really don't see how this a problem in the normal case where you'd pick a
JAR and then simply ignore upgrading as time progresses - just like you are
doing with everything else.

I would imagine that in most cases forward compatibility is maintained is
this scenario.  If you want to restrict yourself to
lowest-common-denominator you are free to do so.

Introducing new feature runs the risk of introducing bugs but at the same
time those features generally have value otherwise they would not have been
developed.  There needs to be some plan to get Java users access to the new
functionality when they use PostgreSQL.

At this point I can imagine that we'd break at Java 7 then the modern driver
would try to maintain backward compatibility as long as possible.  It would
be deprecated at some point and a post-modern driver based on Java 12 could
become the mainline driver.

I do not think our present situation is inherently a bad one or unexpected
given the unique requirements that manifest themselves by working in two
worlds.  Which is why being open to forks and/or custom implementations in
order to test-drive new features and other changes is worthwhile.  Leave the
"mainline" JAR focused on stability and compatibility over feature
implementation but give people the option to choose some other trade-off.
At some point the technical debt from stability/compatibility will result in
the new mainline driver arriving in the same "maintenance mode" status that
the current mainline driver exhibits.

David J.




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