+1 better now than latter -------- Original message -------- From: Gary Gregory <garydgreg...@gmail.com> Date: 06/12/2016 8:56 PM (GMT-05:00) To: Commons Developers List <dev@commons.apache.org> Subject: Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Should these be package private then? G On Jun 12, 2016 5:32 PM, "Charles Honton" <c...@honton.org> wrote: > DateParser and DatePrinter interfaces are not just for internal use. I > will gladly add javadoc to the effect that end users are not expected to > implement these interfaces and that methods may be added in any release. > > I think you are correct about this being a source incompatibility rather > than a binary incompatibility. So, if a developer has implemented this > interface and published the class; and another developer uses the new > method against this older published class, then a LinkageError will be > thrown. > > In my mind, this makes the compatibility issue even less of a concern. > > regards, > chas > > > On Jun 12, 2016, at 5:09 PM, sebb <seb...@gmail.com> wrote: > > > > On 13 June 2016 at 01:00, Charles Honton <c...@honton.org> wrote: > >> I added DateParser and DatePrinter interfaces in 3.2. These are not > expected to be implemented by end users, only by > org.apache.commons.lang3.time classes. > > > > However the Javadoc does not warn people not to implement the interfaces. > > > > In future such internal interfaces should probably be added to a > > .internal package, as well as being documented as for internal use > > only > > > >> The interfaces exist to hide the actual implementation classes. Please > look at FastDateFormat javadoc for the factory pattern that developers use > to obtain an instance of DateParser or DatePrinter. > >> > >> I should have added an @since marker in Lang-1154. I‘ll add @since 3.5 > marker to the added method. > >> > >> Yes, binary compatibility is broken if we expect some non-apache code > to implement this interface. > > > > No, binary compat is not broken when methods are added to an > > interface, but source compat will be. > > > >> No, I do not expect non-apache code to implement this interface. > >> > >> I ask that Lang-1154 not be reverted. > >> > >> regards > >> chas > >> > >>> On Jun 12, 2016, at 7:43 AM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >>> > >>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <brit...@apache.org> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I think we should simply revert LANG-1154. It has broken several > classes > >>>> and blocks a release. We can discuss how to implement the requirement > >>>> described in LANG-1154 after 3.5. > >>> > >>> +1 and RERO. > >>> > >>> Gary > >>> > >>>> > >>>> Benedikt > >>>> > >>>> sebb <seb...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr: > >>>> > >>>>> On 12 June 2016 at 08:41, Pascal Schumacher < > pascalschumac...@gmx.net> > >>>>> wrote: > >>>>>> Hello everybody, > >>>>>> > >>>>>> as I understand it lang is currently not in releasable state. Clirr > >>>>> reports > >>>>>> these errors: > >>>>>> > >>>>>> [ERROR] 7012: org.apache.commons.lang3.time.DateParser: Method > 'public > >>>>>> boolean parse(java.lang.String, java.text.ParsePosition, > >>>>>> java.util.Calendar)' added to Interface > >>>>> > >>>>> Doesn't have @since marker... > >>>>> > >>>>> Also it seems a strange method to add to the interface. > >>>>> Maybe it could just be dropped from the interface? > >>>>> > >>>>>> [ERROR] 7012: org.apache.commons.lang3.time.DatePrinter: Methode > >>> 'public > >>>>>> java.lang.Appendable format(long, java.lang.Appendable)' added to > >>>>> Interface > >>>>>> [ERROR] 7012: org.apache.commons.lang3.time.DatePrinter: Methode > >>> 'public > >>>>>> java.lang.Appendable format(java.util.Date, java.lang.Appendable)' > >>> added > >>>>> to > >>>>>> Interface > >>>>>> [ERROR] 7012: org.apache.commons.lang3.time.DatePrinter: Methode > >>> 'public > >>>>>> java.lang.Appendable format(java.util.Calendar, > java.lang.Appendable)' > >>>>> added > >>>>>> to Interface > >>>>> > >>>>> Interface method additions break source compatibility, not binary > >>> compat. > >>>>> > >>>>> There's no default abstract implementation of the interface, so it is > >>>>> possible that end users may have implemented the interface. > >>>>> If that seems very unlikely we could just document the change. > >>>>> > >>>>> Or the additions could go into a separate interface or subinterface > >>>>> (this tends to get messy). > >>>>> > >>>>> Or the code could be updated to Java 8, which allows interfaces to > >>>>> have implementations. > >>>>> > >>>>>> [ERROR] 7005: org.apache.commons.lang3.time.FastDatePrinter: > Parameter > >>>>> type > >>>>>> 2 changed from 'protected java.lang.StringBuffer > >>>>>> applyRules(java.util.Calendar, java. lang.StringBuffer)' to > >>>>>> java.lang.Appendable > >>>>>> [ERROR] 7006: org.apache.commons.lang3.time.FastDatePrinter: Return > >>> type > >>>>> of > >>>>>> method 'protected java.lang.StringBuffer > >>> applyRules(java.util.Calendar, > >>>>>> java.lang.StringBuffer)' changed to java.lang.Appendable > >>>>> > >>>>> This could be fixed by adding a new method with a new name and > >>>>> deprecating the old method. > >>>>> > >>>>> This does affect binary compat. > >>>>> > >>>>>> Any ideas on how to fix this? > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Pascal > >>>>>> > >>>>>> > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
