Re: Drop support for jdk 1.1, 1.2 ? - Mailing list pgsql-jdbc

Kris Jurka wrote:

>
> On 29 Dec 2003, Dave Cramer wrote:
>
>
>>As we are going to be moving to gborg, it is an opportunity to do some
>>reorganization, one way of simplifying the driver is to drop support for
>>some old jvm's.
>>
>>Is this a problem for anyone?
>
>
> This is more of a general user survey for how the driver is used and
> developed.  With the upcoming physical move of the driver source code to
> http://gborg.postgresql.org/ from the main project's cvs repository we
> were wondering if there are other changes that should be made?  For
> example:
>
> What JVMs does the latest version of the driver need to support?  Are you
> likely to upgrade your 7.1 database to 7.4 without upgrading the JVM at
> the same time?
>
> What server versions does the latest version of the driver need to
> support?  Are you using a driver from a new server against an older one to
> get some of the fixes/features or do you just download/build the driver
> for the server version you are on?

We run 1.4.2 JVMs with drivers built from CVS + patches, against 7.3.x
(soon 7.4.x) servers.

Dropping 1.1 support would make modifying the driver a lot easier for me.

If we drop 1.1 support, can we also drop JDBC1 support? That is, not
separating out a JDBC1-only build as we currently do. The main problem
with merging JDBC1 and JDBC2 implementations currently is that JDBC2
depends on JDK 1.2 collection classes (java.util.Map etc). Merging that
code would make bits like correct scrollable resultset support much simpler.

Is there anyone using JDK >=1.2 but not JDBC2?

Is there a real benefit to dropping 1.2 support? It doesn't affect me
but seems a bit aggressive. The 1.2 -> 1.3 -> 1.4 API changes aren't
particularly large (as used by the driver, anyway). The main argument
for dropping 1.2 that I can see is that it reduces the number of JVMs
that need testing.

> What features are you sorely in need of that are either unimplemented or
> don't work as advertised?

Efficient batch insert/update support -- either a real implementation of
batch updates, or a clean COPY interface. Currently, doing 100k inserts
via JDBC to a remote database kills us because of the network roundtrip
latency involved in doing each insert separately. I can batch the
inserts into a single query in the application but that's a) nonportable
[well, so is COPY] and b) ugly -- the driver should be doing this, not
the app -- that's why JDBC has a batch-update interface!

Robust query timeout and cancellation support. This might need API
extensions since the JDBC cancel() API seems fundamentally broken. I'm
not convinced that the current backend cancellation protocol is safe in
all cases either (what if the cancel arrives before the query, due to a
delay in the connection delivering the query?).

Reducing the garbage generated by the driver (mostly double-handling of
parameter/result data) would be nice to have. Our system needs low-pause
collections, and the best way to reduce GC pauses is to not generate the
garbage in the first place.

All of the above are on my radar for eventually implementing, but I'm
short on time for JDBC hacking at the moment.

-O