No, these are the interfaces that the end user should use. (but not implement)
> On Jun 12, 2016, at 6:10 PM, dbrosIus <dbros...@baybroadband.net> wrote: > > +1 better now than latter > > -------- Original message -------- > From: Gary Gregory <garydgreg...@gmail.com <mailto:garydgreg...@gmail.com>> > Date: 06/12/2016 8:56 PM (GMT-05:00) > To: Commons Developers List <dev@commons.apache.org > <mailto: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 > <mailto: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 >>> <mailto:seb...@gmail.com>> wrote: >>> >>> On 13 June 2016 at 01:00, Charles Honton <c...@honton.org >>> <mailto: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 >>>>> <mailto:garydgreg...@gmail.com>> >> wrote: >>>>> >>>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <brit...@apache.org >>>>> <mailto: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 <mailto: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 <mailto: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 >>>>>>>> <mailto:dev-unsubscr...@commons.apache.org> >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> <mailto:dev-h...@commons.apache.org> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> <mailto:dev-unsubscr...@commons.apache.org> >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> <mailto:dev-h...@commons.apache.org> >>>>>>> >>>>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> <mailto:dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> <mailto:dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> <mailto:dev-h...@commons.apache.org>
