Please look at https://github.com/apache/commons-lang/pull/165/files <https://github.com/apache/commons-lang/pull/165/files> for the suggested javadoc changes.
regards, chas > On Jun 12, 2016, at 6:18 PM, Charles Honton <c...@honton.org> wrote: > > 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>
