The clone method and Cloneable interface should be treated with caution [1], so I don't think it makes sense to make it easier to use.
I would rather see copy methods allied to a suitable interface. [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4 On 24 August 2015 at 11:07, sebb <seb...@gmail.com> wrote: > On 24 August 2015 at 10:57, Jörg Schaible <joerg.schai...@swisspost.com> > wrote: >> Hi Sebb, >> >> sebb wrote: >> >>> On 24 August 2015 at 08:04, Jörg Schaible <joerg.schai...@swisspost.com> >>> wrote: >>>> Hi Sebb, >>>> >>>> sebb wrote: >>>> >>>>> On 23 August 2015 at 23:19, <dbros...@apache.org> wrote: >>>>>> Author: dbrosius >>>>>> Date: Sun Aug 23 22:19:04 2015 >>>>>> New Revision: 1697267 >>>>>> >>>>>> URL: http://svn.apache.org/r1697267 >>>>>> Log: >>>>>> remove the need for casting at the clone() call site >>>>> >>>>> -1 >>>>> >>>>> I was hoping to reduce the number of API changes to the minimum, so we >>>>> can potentially release a >>>>> version that is binary compatible with 5.2. >>>> >>>> Are you sure that this is binary incompatible? IIRC it is safe to adjust >>>> the return type of clone here. >>> >>> It's not binary compatible because the return type is part of the >>> method signature. >>> >>> I think it may well be source compatible. >> >> No, because the exception is no longer thrown (error depends on the compiler >> settings) > > Huh? The commit did not change the throws clauses (there were none) > >> or if someone has overloaded the method with return type Object. > > Here I agree. > >> Cheers, >> Jörg >> >> >> --------------------------------------------------------------------- >> 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
