Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 72.14.220.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=XeYEob+2Nqi9rGP+k3v2ara4LifJRYiEfczrKb0IsWHFE5SrBybWlH767rJ57eFKqs
         AfNHnXriso0DAgtIBqKgMsdZRVNL/ls31Otp8wk+uDgkiMw+VOlkry1HThOHB5TcXadS
         ULgcVFkzTzDVi91oVyF1+PLjhUJ3nWoZH0b5w=
MIME-Version: 1.0
In-Reply-To: <002c01c976f4$89705cf0$9c5116d0$@org>
References: <ce1f2ea80901141323k5efe164agd750731e7372987c@mail.gmail.com>
	 <496E98AE.7050604@btopenworld.com> <496EA885.5000006@gmail.com>
	 <002c01c976f4$89705cf0$9c5116d0$@org>
Date: Thu, 15 Jan 2009 11:22:03 +0000
Message-ID: <25aac9fc0901150322o26b3d308q97833b081bc6f818@mail.gmail.com>
Subject: Re: [DBCP] svn commit: r734473
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 15/01/2009, Mark Thomas <markt@apache.org> wrote:
> > From: Phil Steitz [mailto:phil.steitz@gmail.com]
>
> >
>  > Stephen Colebourne wrote:
>  > > Rahul Akolkar wrote:
>  > >>
>
> > >> Note that the above breaks binary and source compatibility.
>  > Therefore,
>  > >> at the least, such changes deserve notable mentions in the release
>  > >> notes and often additional thought about the version number of the
>  > >> next release.
>  > >
>
> > > We shouldn't create any more jar hell situations.

As far as I can tell, making these static fields final will only break
code that tries to write to the field(s).

If code merely references the field, then it will continue to compile
and run against a final-ised version of the class.

Any code that writes to the fields in question is dubious at best, so
I personally don't see any problem in breaking it.

Surely "jar hell" can only happen to incorrect code in this case?

Or am I missing some subtlety here?

>  > I agree with Stephen on this.  This is a needless break.  I would
>  > prefer
>  > to limit changes to what is required to support compilation under JDK
>  > 1.6.   Otherwise, we need to target a 2.0 (and consider changing
>  > package
>  > name) and as there does not appear to be collective energy to push out
>  > a
>  > 1.2.3 bugfix release, I would really like to see 1.3 usable by current
>  > users as there are some nasty bugs that have been fixed in trunk.
>
>
> +1
>
>
>  Mark
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org