sebb wrote: > On 23/11/2009, Henri Yandell <flame...@gmail.com> wrote: >> Given that the Sun JDK's SSL implementation has the same problem as >> other SSL implementations, and given that Sun don't support the free >> 1.4 and 1.5 versions (so no security fixes coming), I think we do a >> disservice in even encouraging people to stay on 1.4 and 1.5 by >> continuing to support them. > > I don't see it like that. > > The policy has been for Commons components to be upwards compatible, > so IMO the fact that Commons Foo supports Java 1.2 or 1.3 has no > little or no bearing on whether the end user decides to upgrade to > 1.6. > > Larger organisations tend to be very conservative about upgrading to > the latest version of Java; if we change Commons to require Java 1.6 > unneccessarily then IMO the likely effect is to prevent some companies > from using the latest version of Commons, i.e. it makes the situation > slightly worse, not better. > >> 1.6 for all Commons components :) > > I assume that is not serious, otherwise -1.
Agree with sebb on this. Dropping support for 1.5 is not a serious option. Since 1.4 ~ 1.5 wrt this problem, I want to keep the min jdk for dbcp 1.3 at jdk 1.4. In dbcp/pool 2.0, we can up the minimum to 1.5+ and take advantage of the concurrency package and / or borrow from Oliver's great new concurrency additions to [lang]. There are quite a few bug fixes in dbcp 1.3 that we should make available ss drop-in replacement for users of earlier versions. I am being a little inconsistent here by increasing the required level to 1.4, which normally should only be done in a major version release, but 1.3 is so old now that I am OK with that change. Phil > > I'm all for changing the minimum version of Java where it helps the > end-user, but not just for the sake of it. > >> Hen >> >> >> On Sun, Nov 22, 2009 at 5:58 PM, Gary Gregory >> <ggreg...@seagullsoftware.com> wrote: >> > Our server and tools are all on Java 6, so for us, moving to 6 is quite >> fine. >> > >> > We strongly encourage our users to move away from 1.4.2 ASAP. >> > >> > Gary >> > >> >> -----Original Message----- >> >> From: Phil Steitz [mailto:phil.ste...@gmail.com] >> >> Sent: Sunday, November 22, 2009 14:03 >> >> To: Commons Developers List >> >> Subject: Re: [dbcp] 1.3 release problems >> >> >> >> Gary Gregory wrote: >> >> > Does dropping support for Java 1.4 simply the issue? >> >> >> >> No. Would have to drop 1.5 too. >> >> >> >> Phil >> >> > >> >> > Gary >> >> > >> >> >> -----Original Message----- >> >> >> From: Phil Steitz [mailto:phil.ste...@gmail.com] >> >> >> Sent: Sunday, November 22, 2009 08:43 >> >> >> To: Commons Developers List >> >> >> Subject: [dbcp] 1.3 release problems >> >> >> >> >> >> I am running into some problems preparing for dbcp-1.3. I would >> >> >> appreciate comments / patches on any of the issues below. >> >> >> >> >> >> 1. Findbugs is showing some real (inconsistent synch) and not so >> >> >> real (e.g. serialization issues on classes that IMO should not be >> >> >> serializable, but we can't fix until 2.0). The full report is here: >> >> >> http://commons.apache.org/dbcp/findbugs.html >> >> >> I would appreciate suggestions/patches/commits for what to fix and >> >> how. >> >> >> >> >> >> 2. We can't compile commons-pool-1.3.jar against JDK 1.6 (JDBC 4) >> >> >> and expect it to work for JDK 1.4/1.5 (JDBC 3) clients (at least not >> >> >> as the code stands today). So we need to create two jar artifacts. >> >> >> The question is which one gets the 1.3 name, what is the other >> >> >> named and how do we package the distros? >> >> >> >> >> >> 3. I assume it is OK at this point to drop the nojdbc3 Ant target >> >> >> and compiler flags for JDBC 2. >> >> >> >> >> >> TIA >> >> >> >> >> >> Phil >> >> >> >> >> >> -------------------------------------------------------------------- >> >> - >> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
