On 22/01/2012 17:46, Kevin Grittner wrote:
> John Lister<john(dot)lister-ps(at)kickstone(dot)com> wrote:
>> I noted from the recent NIO thread that support for Java 1.4 was
>> checked. I know from previous discussion that this has been
>> brought up, but was wondering if there was a reason for still
>> supporting 1.4? I therefore wondered if it is still worth while
>> supporting something released nearly 10 years ago and nearly 8
>> years since its last update and not freeze a version for that
>> release (except maybe security related updates). Similarly would
>> it be wise to freeze the jdbc 2& 3 updates as well since they
>> require Java 1.4 and concentrate on jdbc 4 support and maybe Java
>> 1.5 (or even 1.6) and the additional features?
>> With that, I'll leave it open to the floor to discuss...
> JDK 1.5 was released in September of 2004, entered its end-of-life
> phase in April of 2008, with support dropped in November of 2009.
> JDK 1.6 was released in December of 2006 and is mature and still
> supported. JDK 1.7 was released six months ago and might not be
> considered mature enough for everyone yet.
> I really don't see the point of supporting anything so archaic as
> JDK 1.4. The old jars are still there for anyone who is stuck at
> that level for some reason.
> JDK 1.5 is a little more borderline; newer versions have only been
> available for five years, and it has only been completely out of
> support with the vendor for a little over two years. With those
> numbers, it would be hard for someone to really find fault with the
> project for not producing new driver versions. On the other hand,
> JDK 1.5 entered its end-of-life phase when the latest major release
> of PostgreSQL was 8.3, and went completely out of support when the
> latest major release of PostgreSQL was 8.4 -- PostgreSQL releases
> which won't hit EOL for another year or two.
> Perhaps the litmus test should be whether there is still a supported
> major version of PostgreSQL which was released while the Java
> version was still supported? Such a test would have us dropping
> support for JDK 1.4 now, but still supporting JDK 1.5 until July of
I did consider 1.6 as the base line, but thought it may be a stretch too
far so left it with 1 increment, so phasing out 1.5 support in a couple
of years sounds good. One of the reasons in previous discussions is that
large enterprises were and maybe still are using 1.4 and were/are
reluctant to change due to testing/stability requirements, etc. I was
wondering if they would also be using new releases of the driver because
of the same.
Also, and this may be a step too far, what would the implications of
phasing out specific jdbc version support. For example jdbc 3 is nearly
10 years old with 2 even older. If for example we were making the jump
to only support JDK 1. 6 and above, would it make sense to remove builds
for earlier versions. One could even merge the classes to remove the
jdbc 2 *3 specific versions into a single JDBC 4 tree and apply any 1.6
features to the whole source tree?
As a side issue I imagine this may clean up the build farm and testing
side of things?
Again just a thought..
In response to
pgsql-jdbc by date
|Next:||From: Oliver Jowett||Date: 2012-01-22 22:11:36|
|Subject: Re: Java 1.4|
|Previous:||From: Lew||Date: 2012-01-22 18:59:43|
|Subject: Re: Java 1.4|