FTR, I agree these should be removed, but out of common courtesy we should
probably seek James's acquiescence.
Matt
On Mar 27, 2014 9:43 AM, "sebb" <seb...@gmail.com> wrote:
> Also just noticed that there are a lot of @author tags.
> These are deprecated, and should ideally be removed (the authors can
> be credited elsewhere).
>
> One is yours, the rest are James Carman.
>
> On 27 March 2014 14:13, sebb <seb...@gmail.com> wrote:
> > On 27 March 2014 13:16, Matt Benson <gudnabr...@gmail.com> wrote:
> >> On Mar 27, 2014 6:43 AM, "sebb" <seb...@gmail.com> wrote:
> >>>
> >>> On 27 March 2014 04:29, Matt Benson <mben...@apache.org> wrote:
> >>> > This is the notice that I intend to serve as release manager and
> begin
> >>> > cutting release candidates in the very near future after a very small
> >>> > amount of remaining cleanup. Those of you who wish to formulate and
> >> express
> >>> > opinions on the state of the codebase before the v2 API is set in
> stone
> >>> > should probably go ahead and begin doing so.
> >>>
> >>> I took a quick look, and Eclipse complains that the interface
> >>> implementations are not flagged with @Override, even though the
> >>> compiler is set to 1.6.
> >>> Is that intentional? [Obviously does not affect the API]
> >>
> >> Not intentional; thanks for spotting and addressing. We should
> potentially
> >> add these items to one of our static code checker configurations.
> >
> > Well, I've fixed the Java 5 ones so far; I can fix the Java 6 ones soon.
> >
> >>>
> >>> Also, I spotted at least one instance of
> >>>
> >>> @SuppressWarnings("unchecked")
> >>>
> >>> with no explanation as to why it is safe to ignore the warning.
> >>>
> >>> Since such warnings can indicate a generics issue which may be tricky
> >>> to fix later I think they need to be addressed before fixing the API.
> >>>
> >>
> >> If you see it again, let me know and/or add a TODO in the code.
> >
> > There are quite a lot; none are commented in-line.
> > So rather than me adding TODO it's probably quicker to search for
> >
> > @SuppressWarnings("unchecked")
> >
> >>> My other main concern regarding API petrification is mutable public or
> >>> protected variables.
> >>> Not yet scanned to see if there are any of these.
> >>
> >> Again, if these can be caught by a tool, let's set it up.
> >
> > I don't have a working tool; at present I just look for ^package and
> > visually scan the Outline in Eclipse.
> > Rather tedious!
> >
> >> The current configs are minimal.
> >
> > Yes, I noticed only the following mutable fields
> >
> > SingletonProvider.instance
> > ProviderDecorator.inner
> > TrainingContext.TrainingContextFrame.matcher
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
