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=YT60mNSz9F3FQW5+QEEQpgwKijDm7xqt9Pt1dRhO5JQEC6UxM+C5w48AyqiQKxbyhy
         EqqHOmXxq3DC5WzoWrNLxkeV6ma2Kmm1gffb0+rwYp9Gd5JtzcHmwjLJZUzKVcxO1CVt
         vR4gwVd6AnmPy8BqN9hu13sTHpZh5rm1RuOn8=
MIME-Version: 1.0
In-Reply-To: <ce1f2ea80901171908u1307ae1dked4d1746befb7da3@mail.gmail.com>
References: <ce1f2ea80901141323k5efe164agd750731e7372987c@mail.gmail.com>
	 <496E98AE.7050604@btopenworld.com> <496EA885.5000006@gmail.com>
	 <002c01c976f4$89705cf0$9c5116d0$@org>
	 <25aac9fc0901150322o26b3d308q97833b081bc6f818@mail.gmail.com>
	 <ce1f2ea80901171908u1307ae1dked4d1746befb7da3@mail.gmail.com>
Date: Sun, 18 Jan 2009 18:20:27 +0000
Message-ID: <25aac9fc0901181020p3ca6ede8uc6fddb7ca65f1224@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 18/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Thu, Jan 15, 2009 at 6:22 AM, sebb <sebbaz@gmail.com> wrote:
>  > 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.
>  >
>
> <snip/>
>
>  Yup.
>
>
>
>  > 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?
>  >
>
> <snap/>
>
>  It may be possible that for some constrained usage pattern the non
>  final protected field may be written to, and with said constraints it
>  may be less dubious or not at all.

I'd be interested to see a use case for changing any of the fields.

The existing references to the fields within the class do not use
synchronisation.
It would be tricky to make the any code that changes any of the fields
thread-safe.

>  I think whats being pointed out
>  here is that at some point a design decision was made to have a non
>  final protected field and its hard to say what usage implications that
>  has had in the wild.

I take your point, but I think it's more likely that the final
qualifier was accidentally omitted... in particular, the MAJOR_VERSION
and MINOR_VERSION fields should surely be final, otherwise will the
implementation be JDBC compliant?

If the user was expected to change the fields, why not provide
synchronised setters/getters as is done with
accessToUnderlyingConnectionAllowed?

>
>  -Rahul
>
>
>  ---------------------------------------------------------------------
>  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