Обсуждение: Java 1.4
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... Thanks John -- www.pricegoblin.co.uk
John Lister <john.lister-ps@kickstone.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 2014. -Kevin
On 01/22/2012 09:46 AM, Kevin Grittner wrote: > John Lister<john.lister-ps@kickstone.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 "The" vendor? There are more than one. > 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 One vendor's version did. > 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. There is still support for Java 5, and indeed many shops are still using it or even only just switching over to it. It all depends on whom you pay for support. > 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 > 2014. Perhaps that "litmus test" should take into account the many different versions of Java out there, the many different systems still running Java 5 and earlier, and understand that there is still a business need for support for versions that might seem old to people imagining that there is only one vendor, one version, one marketplace for Java. One of the largest markets for JDBC, if not the largest, is enterprise Java, where the versions lag far behind the naive presentation based only on Sun's core Java support schedule. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
On 22/01/2012 17:46, Kevin Grittner wrote: > John Lister<john.lister-ps@kickstone.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 > 2014. 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.. John -- www.pricegoblin.co.uk
On 23 January 2012 07:59, Lew <noone@lewscanon.com> wrote: > "The" vendor? There are more than one. Which other Java vendors do you think we should consider here? What do their release/support schedules look like? Oliver
On 01/22/2012 02:11 PM, Oliver Jowett wrote: > On 23 January 2012 07:59, Lew<noone@lewscanon.com> wrote: > >> "The" vendor? There are more than one. > > Which other Java vendors do you think we should consider here? All of them. IBM markets several Java implementations (PC, Z/OS, ...). HP has at least one. Oracle itself has several. > What do their release/support schedules look like? You can Google it as well as I can, señor. Here's one link to Oracle's support, which continues to uphold version 1.4: <http://www.oracle.com/us/technologies/java/java-se-support-393643.html> As far as I can tell from the Oracle website, there's no announced plan or date for discontinuation of support for 1.4 yet. "... enjoy Oracle Lifetime Support as well as updates on older releases dating back to Java SE 1.4.2" -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
On 2012-01-22 21:01, John Lister wrote: > 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. I think that if someone is conservative enough to use 1.4, they will a) be successfully running with whatever old version of the driver they have, b) still use an older version of postgres, and c) have a well tested system without any major bugs left that would require a driver or database update. Basically the only reason not to update such an old system is because it works, and that means no one will risk an update of a relatively minor component like a driver. Who cares if there is a bug in the driver, if it never affected them in the past 10 years. And if there really is someone who needs a current version of the driver running on a stone age vm, that someone will probably be willing to either backport the update or pay someone else to do it. I may be wrong, but nobody on the list seems to know someone who really needs support for 1.4. Till -- Kyon, Till Toenges, tt@kyon.de, http://kyon.de Obergplatz 14, 47804 Krefeld, +49-2151-3620334
On 22 Jan 2011 Lew<noone@lewscanon.com> wrote: >On 01/22/2012 02:11 PM, Oliver Jowett wrote: >>On 23 January 2012 07:59, Lew<noone@lewscanon.com> wrote: >>>"The" vendor? There are more than one. >>Which other Java vendors do you think we should consider here?
>All of them. >IBM markets several Java implementations (PC, Z/OS, ...). HP has at least one. >Oracle itself has several. I think the issue is particular JDK revisions. I would imagine IBM, et al stick to the jdk specs (or should be) and so long as we don't use any vendor specific extensions then it should work across the board. Even if it doesn't I imagine many of the other versions are commercial offering for which I don't have the money to purchase a licence and I'm sure others are in the same boat. >>What do their release/support schedules look like?
>You can Google it as well as I can, señor. Here's one link to Oracle's >support, which continues to uphold version 1.4: ><http://www.oracle.com/us/technologies/java/java-se-support-393643.html> >As far as I can tell from the Oracle website, there's no announced plan or >date for discontinuation of support for 1.4 yet. > "... enjoy Oracle Lifetime Support as well as updates on older releases dating >back to Java SE 1.4.2" But that is only "sustaining support" which doesn't include any updates or fixes as I read it. The Extended support which potentially offers fixes, etc expires next year for 1.4 and a year after for 1.5. However I would use a similar argument as above, I don't have access to those commercial licences or any fixes, etc I understand that large enterprise setups are where 1.4 is being used which is why I posed the question, but I would echo the sentiments of Till in an earlier post, that the people with a requirement for 1.4 are unlikely to use a new version of the driver without substantial testing or a new version of the database, and if they do are likely to have paid support... but I maybe wrong? John -- www.pricegoblin.co.uk
Before we go much further down this road I'd like to understand the goal here. The main project has a guide to how to submit patches. Paraphrased it says that if the patch is significant you should propose it on the list for discussion. The reason I bring this up is that recently we had someone on the list propose that he was going to move the project to git and had setup a repository and we were going to simply change the revision control system. Since then that person has disappeared from the list, however this caused a flurry of activity which fortunately has been followed up by Maciek. More recently a patch has been presented with the subject NIO support. This patch in fact only provides an alternative implementation of setTimeout. The author has promised an NIO implementation later. All of these proposals require significant changes in the project, and as such need to be discussed on the list. For instance I do believe there was some discussion on alternative implementations for setTimeout as the one that I wrote was a bit too simple. That being said I don't think we can entertain any of these without a plan. So back to my initial point. Can we get some discussion on the benefits of both NIO, and dropping 1.4 ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Mon, Jan 23, 2012 at 3:34 AM, John Lister <john.lister-ps@kickstone.com> wrote: > On 22 Jan 2011 Lew<noone@lewscanon.com> wrote: > >>On 01/22/2012 02:11 PM, Oliver Jowett wrote: >>>On 23 January 2012 07:59, Lew<noone@lewscanon.com> wrote: >>>>"The" vendor? There are more than one. >>>Which other Java vendors do you think we should consider here? > >>All of them. > >>IBM markets several Java implementations (PC, Z/OS, ...). HP has at least >> one. >>Oracle itself has several. > > I think the issue is particular JDK revisions. I would imagine IBM, et al > stick to the jdk specs (or should be) and so long as we don't use any vendor > specific extensions then it should work across the board. Even if it doesn't > I imagine many of the other versions are commercial offering for which I > don't have the money to purchase a licence and I'm sure others are in the > same boat. > >>>What do their release/support schedules look like? > >>You can Google it as well as I can, señor. Here's one link to Oracle's >>support, which continues to uphold version 1.4: >><http://www.oracle.com/us/technologies/java/java-se-support-393643.html> > >>As far as I can tell from the Oracle website, there's no announced plan or >>date for discontinuation of support for 1.4 yet. > >> "... enjoy Oracle Lifetime Support as well as updates on older releases >> dating >>back to Java SE 1.4.2" > > But that is only "sustaining support" which doesn't include any updates or > fixes as I read it. The Extended support which potentially offers fixes, etc > expires next year for 1.4 and a year after for 1.5. However I would use a > similar argument as above, I don't have access to those commercial licences > or any fixes, etc > > I understand that large enterprise setups are where 1.4 is being used which > is why I posed the question, but I would echo the sentiments of Till in an > earlier post, that the people with a requirement for 1.4 are unlikely to use > a new version of the driver without substantial testing or a new version of > the database, and if they do are likely to have paid support... but I maybe > wrong? > > John > -- > www.pricegoblin.co.uk
On 2012-01-23 15:02, Dave Cramer wrote: > So back to my initial point. Can we get some discussion on the > benefits of both NIO, and dropping 1.4 ? Support for 1.4 was a bit of extra work recently, as far as i read the mails on this list. Dropping it would make it easier for everyone to add to or experiment with the driver. Till -- Kyon, Till Toenges, tt@kyon.de, http://kyon.de Obergplatz 14, 47804 Krefeld, +49-2151-3620334
23.01.12 16:02, Dave Cramer написав(ла): > More recently a patch has been presented with the subject NIO support. > This patch in fact only provides an alternative implementation of > setTimeout. The author has promised an NIO implementation later. Small correction for everyone to understand it right: the patch does contain NIO support for V3 non-secure connections. V2 and secure requires extra work I am going to perform in the nearest time. I posted to the list early because I simply wanted to get feedback as early as possible. Note that NIO itself do not provide any specific benefits (may be performance?). What you get is much better control on IO, comparing to using streaming. So, you can get timeout processing in same thread, you can see when your buffers overflow and react accordingly, you can see when your SSL data is available for reading. As far as I can see, introducing NIO do not require global changes. The tricky thing is handling read during write, but this is additional feature NIO makes possible. Best regards, Vitalii Tymchyshyn
On Mon, Jan 23, 2012 at 9:36 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote: > 23.01.12 16:02, Dave Cramer написав(ла): > >> More recently a patch has been presented with the subject NIO support. >> This patch in fact only provides an alternative implementation of >> setTimeout. The author has promised an NIO implementation later. > > Small correction for everyone to understand it right: the patch does contain > NIO support for V3 non-secure connections. V2 and secure requires extra work > I am going to perform in the nearest time. I posted to the list early > because I simply wanted to get feedback as early as possible. > > Note that NIO itself do not provide any specific benefits (may be > performance?). What you get is much better control on IO, comparing to using > streaming. So, you can get timeout processing in same thread, you can see > when your buffers overflow and react accordingly, you can see when your SSL > data is available for reading. > > As far as I can see, introducing NIO do not require global changes. The > tricky thing is handling read during write, but this is additional feature > NIO makes possible. It is however making changes at the very core of the code. I'm not saying it isn't good or bad, just that it will require considerable testing. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca
23.01.12 18:08, Dave Cramer написав(ла): > On Mon, Jan 23, 2012 at 9:36 AM, Vitalii Tymchyshyn<tivv00@gmail.com> wrote: >> 23.01.12 16:02, Dave Cramer написав(ла): >> As far as I can see, introducing NIO do not require global changes. The >> tricky thing is handling read during write, but this is additional feature >> NIO makes possible. > It is however making changes at the very core of the code. I'm not > saying it isn't good or bad, just that it will require considerable > testing. > For sure. Best regards, Vitalii Tymchyshyn
On 01/23/2012 12:34 AM, John Lister wrote: > On 22 Jan 2011 Lew<noone@lewscanon.com> wrote: > >>On 01/22/2012 02:11 PM, Oliver Jowett wrote: >>>On 23 January 2012 07:59, Lew<noone@lewscanon.com> wrote: >>>>"The" vendor? There are more than one. >>>Which other Java vendors do you think we should consider here? > >>All of them. > >>IBM markets several Java implementations (PC, Z/OS, ...). HP has at least one. >>Oracle itself has several. > > I think the issue is particular JDK revisions. I would imagine IBM, et al stick to the jdk specs (or should be) and solong as we don't use any vendor specific extensions then it should work across the board. Even if it doesn't I imaginemany of the other versions are commercial offering for which I don't have the money to purchase a licence and I'msure others are in the same boat. The issue to which I was responding was whether Postgres JDBC drivers should support Java 1.4. How does your comment impinge on that? My reasoning is that if a substantial body of customers uses Java 1.4, and there is some evidence that this is true, then Postgres JDBC drivers should be available for it. >>>What do their release/support schedules look like? > >>You can Google it as well as I can, señor. Here's one link to Oracle's >>support, which continues to uphold version 1.4: >><http://www.oracle.com/us/technologies/java/java-se-support-393643.html> > >>As far as I can tell from the Oracle website, there's no announced plan or >>date for discontinuation of support for 1.4 yet. > >> "... enjoy Oracle Lifetime Support as well as updates on older releases dating >>back to Java SE 1.4.2" > > But that is only "sustaining support" which doesn't include any updates or fixes as I read it. The Extended support whichpotentially offers fixes, etc expires next year for 1.4 and a year after for 1.5. However I would use a similar argumentas above, I don't have access to those commercial licences or any fixes, etc And yet the quote you cite and purport to refute specifically promises "updates". How do you explain that? > I understand that large enterprise setups are where 1.4 is being used which is why I posed the question, but I would echothe sentiments of Till in an earlier post, that the people with a requirement for 1.4 are unlikely to use a new versionof the driver without substantial testing or a new version of the database, and if they do are likely to have paidsupport... but I maybe wrong? And my answer is yes, we should support Java 1.4, for the reasons I stated and to which you have not spoken. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
-----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Lew Sent: Monday, January 23, 2012 1:21 PM To: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Java 1.4 On 01/23/2012 12:34 AM, John Lister wrote: > On 22 Jan 2011 Lew<noone@lewscanon.com> wrote: > >>On 01/22/2012 02:11 PM, Oliver Jowett wrote: >>>On 23 January 2012 07:59, Lew<noone@lewscanon.com> wrote: >>>>"The" vendor? There are more than one. >>>Which other Java vendors do you think we should consider here? > >>All of them. > >>IBM markets several Java implementations (PC, Z/OS, ...). HP has at least one. >>Oracle itself has several. > > I think the issue is particular JDK revisions. I would imagine IBM, et al stick to the jdk specs (or should be) and solong as we don't use any vendor specific extensions then it should work across the board. Even if it doesn't I imaginemany of the other versions are commercial offering for which I don't have the money to purchase a licence and I'msure others are in the same boat. The issue to which I was responding was whether Postgres JDBC drivers should support Java 1.4. How does your comment impingeon that? My reasoning is that if a substantial body of customers uses Java 1.4, and there is some evidence that this is true, thenPostgres JDBC drivers should be available for it. > I understand that large enterprise setups are where 1.4 is being used which is why I posed the question, but I would echothe sentiments of Till in an earlier post, that the people with a requirement for 1.4 are unlikely to use a new versionof the driver without substantial testing or a new version of the database, and if they do are likely to have paidsupport... but I maybe wrong? And my answer is yes, we should support Java 1.4, for the reasons I stated and to which you have not spoken. ----------------------------------------------------------------------------- I'm only minimally following this but like most things specifics really do help. Is there a listing of not-yet-implementedfeatures (or improvements)? Regardless, such a list should have minimum JDK release requirements listedso that the community would know which desirable features require either a discontinuance of support for older Javareleases OR maintaining additional backward-compatible releases. There doesn't seem to be that many changes to the codebasethat would overwhelm multiple distributions even if there is a smaller number of maintainers using a supposedly "notas branching friendly" source control infrastructure. Skipping some of the language conveniences (i.e., generics) available in more recent versions is maybe annoying but it isa reasonable trade-off for maintaining backward compatibility; but if there is a unavoidable version restriction for aspecific feature then it is likely to be better to implement that feature and up the minimum version than to ignore it infavor of either simplicity or keeping the newest release Java 1.4 compatible. The same kind of thinking goes toward officially supporting different JREs. Make efforts to maintain broad support - thoughthat technically means having these releases in the buildfarm - and address the pros/cons of specific features thatare desirable but that cannot be used on all flavors. My 2 cents. David J.
On Jan 23, 2012, at 11:33 AM, David Johnston wrote: > The same kind of thinking goes toward officially supporting different JREs. Make efforts to maintain broad support - thoughthat technically means having these releases in the buildfarm - and address the pros/cons of specific features thatare desirable but that cannot be used on all flavors. I'll toss in my 2¢ as a Postgres and Java advocate, and one-time patch submitter (which ended up getting abandoned anyway). Weigh that as you will :-) Maintaining Java 1.4 compatibility was a significant barrier to me contributing a patch to the pg-JDBC driver. I may bespoiled, but I write 1.6 code all day every day and being forced to drop back to 1.4 (especially when you have to keeptrack of compatibility in your head, my machine doesn't even have a supported 1.4 install anymore, making it very hardto test well!) really adds both a psychological and a time barrier to contributing code to the driver. As a user (and I do understand not everyone has the same values / needs), I would strongly prefer to see time spent on developing/ shoring up new features and improvements (e.g. JDBC4 features) rather than maintaining support for effectivelylegacy JVM versions.
It would appear from this small survey that there is a preference for maintaining support for 1.4.I am sensitive to the additional work required to code and test all new code against 1.4 It occurs to me that if we move to git then we can keep two branches active. One branch would support 1.4 for backpatches and the other branch would drop 1.4 support and new features would be developed on that line. Thoughts ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Mon, Jan 23, 2012 at 2:55 PM, Steven Schlansker <stevenschlansker@gmail.com> wrote: > > On Jan 23, 2012, at 11:33 AM, David Johnston wrote: > >> The same kind of thinking goes toward officially supporting different JREs. Make efforts to maintain broad support -though that technically means having these releases in the buildfarm - and address the pros/cons of specific features thatare desirable but that cannot be used on all flavors. > > I'll toss in my 2¢ as a Postgres and Java advocate, and one-time patch submitter (which ended up getting abandoned anyway). Weigh that as you will :-) > > > Maintaining Java 1.4 compatibility was a significant barrier to me contributing a patch to the pg-JDBC driver. I may bespoiled, but I write 1.6 code all day every day and being forced to drop back to 1.4 (especially when you have to keeptrack of compatibility in your head, my machine doesn't even have a supported 1.4 install anymore, making it very hardto test well!) really adds both a psychological and a time barrier to contributing code to the driver. > > As a user (and I do understand not everyone has the same values / needs), I would strongly prefer to see time spent ondeveloping / shoring up new features and improvements (e.g. JDBC4 features) rather than maintaining support for effectivelylegacy JVM versions. > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
On Sat, 21 Jan 2012, John Lister 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? > I am all for dropping support for 1.4. If people are having a hard time finding a 1.4 JDK to build/test with now, that's only going to be a bigger problem down the road. I still need a 1.2 JDK to make back branch releases for 8.2 and 8.3 and that's a real pain. Kris Jurka
On Tue, Jan 24, 2012 at 6:51 AM, Dave Cramer <pg@fastcrypt.com> wrote: > It occurs to me that if we move to git then we can keep two branches > active. One branch would support 1.4 for backpatches and the other > branch would drop 1.4 support and new features would be developed on > that line. I assume you mean that 9.2 would have a "split" release (separate 1.4 support) and all the older active release branches would remain with a single 1.4-compatible version and have backpatches from the new 1.4-compatible branch? That could work, but for what it's worth, I think the best way to do this would be to drop 1.4 compatibility entirely in the mainline development branch (e.g., with 9.2 the first non-1.4-compatible release; I'd love to talk to anyone planning to talk to 9.2 from Java 1.4), and keep all the existing release branches compatible until we drop support. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
On Tue, 24 Jan 2012, Dave Cramer wrote: > It occurs to me that if we move to git then we can keep two branches > active. One branch would support 1.4 for backpatches and the other > branch would drop 1.4 support and new features would be developed on > that line. I don't think this is a real feasible option. Who is really going to take it upon themselves to maintain this separate 1.4 branch? Do patch submitters need to submit two versions of every patch, one for 1.4 and one for 1.5+. Git is not going to magically make this all work. Kris Jurka
On Tue, Jan 24, 2012 at 12:54 PM, Kris Jurka <books@ejurka.com> wrote: > > > On Tue, 24 Jan 2012, Dave Cramer wrote: > >> It occurs to me that if we move to git then we can keep two branches >> active. One branch would support 1.4 for backpatches and the other >> branch would drop 1.4 support and new features would be developed on >> that line. > > I don't think this is a real feasible option. Who is really going to take > it upon themselves to maintain this separate 1.4 branch? Do patch > submitters need to submit two versions of every patch, one for 1.4 and one > for 1.5+. Git is not going to magically make this all work. > > Kris Jurka > Well my suggestion was that the 1.4 branch would only get bug fix support, not new features. However you are correct multiple patches would be required which would increase the effort required to submit patches. I would agree this is not what we want. If we are in agreement to drop 1.4 support then this discussion is moot. Does anyone have any strong objections to dropping 1.4 support ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca
This topic just came up again. I am going to propose that we drop support for 1.4 if there are no objections ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Wed, Jan 25, 2012 at 7:31 AM, Dave Cramer <pg@fastcrypt.com> wrote: > On Tue, Jan 24, 2012 at 12:54 PM, Kris Jurka <books@ejurka.com> wrote: >> >> >> On Tue, 24 Jan 2012, Dave Cramer wrote: >> >>> It occurs to me that if we move to git then we can keep two branches >>> active. One branch would support 1.4 for backpatches and the other >>> branch would drop 1.4 support and new features would be developed on >>> that line. >> >> I don't think this is a real feasible option. Who is really going to take >> it upon themselves to maintain this separate 1.4 branch? Do patch >> submitters need to submit two versions of every patch, one for 1.4 and one >> for 1.5+. Git is not going to magically make this all work. >> >> Kris Jurka >> > > Well my suggestion was that the 1.4 branch would only get bug fix > support, not new features. However you are correct multiple patches > would be required which would increase the effort required to submit > patches. I would agree this is not what we want. > > If we are in agreement to drop 1.4 support then this discussion is moot. > > Does anyone have any strong objections to dropping 1.4 support ? > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca
Hi, According to zeroturnaround.com's latest survey, only 6% of the java developers are stuck on 1.4 or older. I also think that those who are stuck on java 1.4, are probably stuck with an older postgresql-server anyways :-( -kny On Thu, 2012-05-17 at 13:25 -0400, Dave Cramer wrote: > This topic just came up again. > > I am going to propose that we drop support for 1.4 if there are no objections ? > > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > On Wed, Jan 25, 2012 at 7:31 AM, Dave Cramer <pg@fastcrypt.com> wrote: > > On Tue, Jan 24, 2012 at 12:54 PM, Kris Jurka <books@ejurka.com> wrote: > >> > >> > >> On Tue, 24 Jan 2012, Dave Cramer wrote: > >> > >>> It occurs to me that if we move to git then we can keep two branches > >>> active. One branch would support 1.4 for backpatches and the other > >>> branch would drop 1.4 support and new features would be developed on > >>> that line. > >> > >> I don't think this is a real feasible option. Who is really going to take > >> it upon themselves to maintain this separate 1.4 branch? Do patch > >> submitters need to submit two versions of every patch, one for 1.4 and one > >> for 1.5+. Git is not going to magically make this all work. > >> > >> Kris Jurka > >> > > > > Well my suggestion was that the 1.4 branch would only get bug fix > > support, not new features. However you are correct multiple patches > > would be required which would increase the effort required to submit > > patches. I would agree this is not what we want. > > > > If we are in agreement to drop 1.4 support then this discussion is moot. > > > > Does anyone have any strong objections to dropping 1.4 support ? > > > > Dave Cramer > > > > dave.cramer(at)credativ(dot)ca > > http://www.credativ.ca >
OK, After talking to a few folks here at pgcon I think it's time to move on and stop supporting 1.4. There's even some talk that we don't need to support 1.5 either. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, May 17, 2012 at 2:49 PM, Kjetil Nygård <polpot78@gmail.com> wrote: > Hi, > > According to zeroturnaround.com's latest survey, only 6% of the java > developers are stuck on 1.4 or older. > > I also think that those who are stuck on java 1.4, are probably stuck > with an older postgresql-server anyways :-( > > > -kny > > > > On Thu, 2012-05-17 at 13:25 -0400, Dave Cramer wrote: >> This topic just came up again. >> >> I am going to propose that we drop support for 1.4 if there are no objections ? >> >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Wed, Jan 25, 2012 at 7:31 AM, Dave Cramer <pg@fastcrypt.com> wrote: >> > On Tue, Jan 24, 2012 at 12:54 PM, Kris Jurka <books@ejurka.com> wrote: >> >> >> >> >> >> On Tue, 24 Jan 2012, Dave Cramer wrote: >> >> >> >>> It occurs to me that if we move to git then we can keep two branches >> >>> active. One branch would support 1.4 for backpatches and the other >> >>> branch would drop 1.4 support and new features would be developed on >> >>> that line. >> >> >> >> I don't think this is a real feasible option. Who is really going to take >> >> it upon themselves to maintain this separate 1.4 branch? Do patch >> >> submitters need to submit two versions of every patch, one for 1.4 and one >> >> for 1.5+. Git is not going to magically make this all work. >> >> >> >> Kris Jurka >> >> >> > >> > Well my suggestion was that the 1.4 branch would only get bug fix >> > support, not new features. However you are correct multiple patches >> > would be required which would increase the effort required to submit >> > patches. I would agree this is not what we want. >> > >> > If we are in agreement to drop 1.4 support then this discussion is moot. >> > >> > Does anyone have any strong objections to dropping 1.4 support ? >> > >> > Dave Cramer >> > >> > dave.cramer(at)credativ(dot)ca >> > http://www.credativ.ca >> > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
On 05/18/2012 06:19 AM, Dave Cramer wrote: > After talking to a few folks here at pgcon I think it's time to move > on and stop supporting 1.4. There's even some talk that we don't need > to support 1.5 either. I would target JDK 6 (although it is EOL later this year) and JDK 7. Maybe do one last release of current master with all JDKs available, and then switch and change the version number to something else, like -964/974.jar (PostgreSQL/JDK/Build). Just my $0.02. Best regards, Jesper
On 05/18/2012 03:39 PM, Jesper Pedersen wrote: > On 05/18/2012 06:19 AM, Dave Cramer wrote: >> After talking to a few folks here at pgcon I think it's time to move >> on and stop supporting 1.4. There's even some talk that we don't need >> to support 1.5 either. > > I would target JDK 6 (although it is EOL later this year) and JDK 7. > > Maybe do one last release of current master with all JDKs available, and then switch and change the version number to somethingelse, like -964/974.jar > (PostgreSQL/JDK/Build). The codebase has been Java5+ since March 12 when a commit went in with Java5 generics. -Mikko
On 05/18/2012 08:42 PM, Mikko Tiihonen wrote: > On 05/18/2012 03:39 PM, Jesper Pedersen wrote: >> On 05/18/2012 06:19 AM, Dave Cramer wrote: >>> After talking to a few folks here at pgcon I think it's time to move >>> on and stop supporting 1.4. There's even some talk that we don't need >>> to support 1.5 either. >> >> I would target JDK 6 (although it is EOL later this year) and JDK 7. >> >> Maybe do one last release of current master with all JDKs available, >> and then switch and change the version number to something else, like >> -964/974.jar >> (PostgreSQL/JDK/Build). > > The codebase has been Java5+ since March 12 when a commit went in with > Java5 generics. Ah, the Linux kernel approach: break it / remove it, and see if anyone screams. Personally I'm quite a big fan of that approach for the removal of legacy cruft and BC. -- Craig Ringer