commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [proxy] toward a v2.0 release
Date Thu, 27 Mar 2014 14:42:50 GMT
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 <sebbaz@gmail.com> wrote:
> On 27 March 2014 13:16, Matt Benson <gudnabrsam@gmail.com> wrote:
>> On Mar 27, 2014 6:43 AM, "sebb" <sebbaz@gmail.com> wrote:
>>>
>>> On 27 March 2014 04:29, Matt Benson <mbenson@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message