On 19/01/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > Not really a DBCP only discussion at this point ... > > > On Sun, Jan 18, 2009 at 1:20 PM, sebb <seb...@gmail.com> wrote: > > On 18/01/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > >> On Thu, Jan 15, 2009 at 6:22 AM, sebb <seb...@gmail.com> wrote: > >> > On 15/01/2009, Mark Thomas <ma...@apache.org> wrote: > >> >> > From: Phil Steitz [mailto:phil.ste...@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. > > > > <snip/> > > Wrong approach :-) Having said something is protected, the onus is > hardly on users to show why they need to write to it. > > > > > 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. > > > > <snap/> > > There could be external synchronization or single threaded scenarios > (container startup shutdown, who knows what :-) > > > > > >> 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... > > <snip/> > > Yes, and only the original author can attest to that. >
But we can draw inferences from other aspects of the class design. > > > in particular, the MAJOR_VERSION > > and MINOR_VERSION fields should surely be final, otherwise will the > > implementation be JDBC compliant? > > > > <snap/> > > No time to look at the code ATM, but those seem to be special cases > (theres more semantics to those fields that the purely final/non final > discussion here). > Indeed, that is the point - it does not make sense for these fields to be mutable. > > > If the user was expected to change the fields, why not provide > > synchronised setters/getters as is done with > > accessToUnderlyingConnectionAllowed? > > > > <snip/> > > Yes that can be done. My point was that if the author really had intended for the fields to be mutable, then why did (s)he not provide thread-safe methods for doing so? > But that doesn't change the fact that finalizing > the field(s) at this time breaks compatibility. > IMO, it only breaks compatibility with broken code. > -Rahul > > --------------------------------------------------------------------- > 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
