On 06/08/2009, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > > -----Original Message----- > > From: sebb [mailto:seb...@gmail.com] > > > Sent: Thursday, August 06, 2009 8:55 AM > > To: Commons Developers List > > Subject: Re: [codec] Are we ready for Codec 1.4 RC4? > > > > On 06/08/2009, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > > > > -----Original Message----- > > > > From: sebb [mailto:seb...@gmail.com] > > > > Sent: Thursday, August 06, 2009 6:43 AM > > > > To: Commons Developers List > > > > Subject: Re: [codec] Are we ready for Codec 1.4 RC4? > > > > > > > > On 06/08/2009, Niall Pemberton <niall.pember...@gmail.com> wrote: > > > > > Are there any more changes people want to do before cutting another > > > > > Codec 1.4 RC? > > > > > > > > > The CPD reports to duplicated code that we could address, but this is > > not critical enough to hold up a release. Aside from that, let's go! > > > > > > > > > > > > > > I just did a quick scan looking for any mutable variables. > > > > There are some variables which ought to be final; these are already > > > > documented as to be treated as final so no problem. > > > > > > > > The only exception is DoubleMetaphone.maxCodeLen, which needs > > > > revisiting for a later release. > > > > > > > > There is one package protected static final array, i.e. > > > > Base64.CHUNK_SEPARATOR (test code needs access) > > > > > > > > This could be fixed by adding a package protected accessor which > > > > returned a copy of the array and making the array private. That's not > > > > essential. > > > > > > > > > The issue with a fix like this one and others issues reported by > > FindBugs is that the fixes break binary compatibility (for example, > > org.apache.commons.codec.net.URLCodec.ESCAPE_CHAR is not final but should > > be.) Sure, no one is probably changing ESCAPE_CHAR, but binary > > compatibility can only be broken in a major release (2.0, 3.0, etc) > > > > In this particular case, the array is package protected, and as such > > surely does not form part of the _public_ API? > > > Sure, in English, but in Java one can create a ...codec package and access > the field. >
Of course, but the user should realise that this is not supported, so if it breaks, then tough. > > If we are not changing it to private now, perhaps we should add a > > comment to say the array will be made private in a future release? > > > Commenting it is a fine idea. > > > Gary > > > > > > > > > > > > > > > Otherwise looks OK to me. > > > > > > > > > Agreed. > > > > > > > > > Gary > > > > > > > > > > > > > > > Niall > > > > > > > > > > ------------------------------------------------------------------ > > --- > > > > > 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 > > > > > > > > > --------------------------------------------------------------------- > > > 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 > > > --------------------------------------------------------------------- > 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
