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
