On Mon, Jan 19, 2009 at 1:46 PM, sebb <seb...@gmail.com> wrote: > 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: <snip/> >> >> 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? > <snap/>
*shrug* > >> 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. > <snip/> I think it boils down to the above point -- saying all code that writes will necessarily be broken cannot be corroborated. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
