commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Herbert <alex.d.herb...@gmail.com>
Subject Re: [rng] binary compatibility with final modifier
Date Thu, 23 May 2019 12:10:38 GMT

On 23/05/2019 12:53, sebb wrote:
> Are the classes supposed to be final?
> Or just the existing constructor(s)?

The two package-private classes are definitely helper classes and should 
be final.

The class with the clirr issue (it is actually an info) only has static 
methods. So currently it is a utility class.

Changing it to have a new role with instance methods would be a design 
update that could be served by introducing a new class. However this 
class has taken the best name.

Any instance role for the class would require that it is typed for 
generics. But a quick try seems to pass clirr.

Gilles, any opinion on a future for ListSampler as:

public class ListSampler<T> {

    // Other static stuff (already in the class)...

    T sample();

}


Alex


>
> On Thu, 23 May 2019 at 12:51, Gilles Sadowski <gilleseran@gmail.com> wrote:
>> Hello.
>>
>> Le jeu. 23 mai 2019 à 13:43, Alex Herbert <alex.d.herbert@gmail.com> a écrit
:
>>> [rng] has three classes with a private constructor that are not
>>> currently marked as final. 1 is public and 2 are package private.
>>>
>>> If I mark them as final then clirr:check ignores the package private
>>> ones and produces this warning for the public one:
>> If it's a "Warning" and not an "Error", I don't think that it could
>> count as a release blocker.  [Confirmation from PMC members
>> welcome...]
>>
>>> "Added final modifier to class, but class was effectively final anyway"
>>>
>>>
>>> Given the class could not have been extended (due to a private
>>> constructor) it seems OK to allow the final modifier.
>> I think so.
>>
>>> So can the final modifier be added? Is there a precedent here with
>>> regard to releases?
>> Cf. above.
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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