On 10 September 2015 at 01:07, Dave Brosius <[email protected]> wrote: > Revert if you like.
Thanks! > I'm not sure how it breaks anything. The return type is > not part of a method signature, so it doesn't break reflection. The return type *is* part of the method signature. You cannot for example replace "int fileSize() with long fileSize()" and maintain binary compat. The loader won't find the method. You can replace void with something else and retain source compat, but not binary compat. Even though the return is not used by the code, the loader won't find the method. > You can > override with a method that returns Object. I just tried, and the compiler complained "The return type is incompatible with Attribute.clone()" > You can assign to object. so not > sure the issue. But it's not a big deal so, whatever. I agree that at present the issue is moot as there is no previous version with which to be compatible. However *if* we can release an updated version of BCEL which is compatible, that would be much better for downstream users. So I am trying to minimise API changes that are not essential to fixing bugs. As such I have reverted many of the changes I made to tidy up the code in 6.0. I shall probably have to revert more. > On 09/09/2015 01:41 PM, sebb wrote: >> >> On 9 September 2015 at 17:57, Gary Gregory <[email protected]> wrote: >>> >>> On Wed, Sep 9, 2015 at 1:19 AM, sebb <[email protected]> wrote: >>> >>>> PING. >>>> >>>> If I don't hear any response in the next few days I will revert. >>>> >>> Would it be helpful to post a link to what a -1 on a commit means as a >>> refresher? >> >> By all means. >> >>> Gary >>> >>> >>>> On 3 September 2015 at 14:43, sebb <[email protected]> wrote: >>>>> >>>>> @[email protected] >>>>> >>>>> This commit still needs to be reverted please. >>>>> >>>>> Whilst it makes calling clone slightly easier, it breaks binary and >>>>> source compatibility. >>>>> The downsides are not worth the convenience. >>>>> >>>>> On 24 August 2015 at 11:18, sebb <[email protected]> wrote: >>>>>> >>>>>> 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 <[email protected]> wrote: >>>>>>> >>>>>>> On 24 August 2015 at 10:57, Jörg Schaible < >>>> >>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Hi Sebb, >>>>>>>> >>>>>>>> sebb wrote: >>>>>>>> >>>>>>>>> On 24 August 2015 at 08:04, Jörg Schaible < >>>> >>>> [email protected]> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Sebb, >>>>>>>>>> >>>>>>>>>> sebb wrote: >>>>>>>>>> >>>>>>>>>>> On 23 August 2015 at 23:19, <[email protected]> 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
