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
