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. > 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). > 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. But that doesn't change the fact that finalizing the field(s) at this time breaks compatibility. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
