commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [codec] Are we ready for Codec 1.4 RC4?
Date Thu, 06 Aug 2009 15:57:59 GMT
> -----Original Message-----
> From: sebb [mailto:sebbaz@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 <GGregory@seagullsoftware.com> wrote:
> > > -----Original Message-----
> >  > From: sebb [mailto:sebbaz@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.pemberton@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. 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message