-1 Imho this usecase also gives a false impression of over riding, so maybe we should make the util classes final as Gary suggested. And imo switching to Guava would be much more of an effort than to compose ones own util class :)
On Thursday, 1 May 2014, Jörg Schaible <joerg.schai...@gmx.de<javascript:_e(%7B%7D,'cvml','joerg.schai...@gmx.de');>> wrote: > sebb wrote: > > > On 1 May 2014 14:21, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > >> On 05/01/2014 03:03 PM, sebb wrote: > >>> On 1 May 2014 12:05, <t...@apache.org> wrote: > >>>> Author: tn > >>>> Date: Thu May 1 11:04:59 2014 > >>>> New Revision: 1591602 > >>>> > >>>> URL: http://svn.apache.org/r1591602 > >>>> Log: > >>>> [COLLECTIONS-519] Constructors of *Utils classes are now protected to > >>>> [allow sub-classing. Thanks to Radoslav Paskalev, Daniel Feist. > >>> > >>> -1 > >>> > >>> I don't think this is a good idea. > >>> > >>> See my comments on the JIRA issue. > >> > >> I consider this to be a compromise considering the fact that previously > >> the util classes all had a public constructor. > >> > >> So when people are migrating from 3.2.1 to 4.0, they have some troubles. > >> To ease the migration I thought that making it protected is safe: > >> > >> * it can not be instantiated > > > > Surely it is now instantiable via a sub-class? > > > >> * if somebody wants to sub-class: at your own risk, like before > >> > >> The composition approach is the right way to go, and I would personally > >> never do something like the issue originator. > > > > The problem we have is that if 4.1 now allows sub-classing, how can we > > ever drop it? > > > > We need to grab the opportunity of 4.x to fix all these bad coding > > practises. > > > > Conversion to 4.x will amyway require some effort on the part of users. > > Let's not spoil the API for all for the sake of a few. > > +1 > > We broke the API on purpose. > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
