-1 I agree with sebb. There is no use case for this. I've elaborated this some more in the jira.
2014-05-01 20:18 GMT+02:00 Dipanjan Laha <dipanja...@gmail.com>: > -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 > > > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
