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 <gillese...@gmail.com> wrote:
Hello.
Le jeu. 23 mai 2019 à 13:43, Alex Herbert <alex.d.herb...@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-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
