commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Date Mon, 13 Jun 2016 00:56:06 GMT
Should these be package private then?

G
On Jun 12, 2016 5:32 PM, "Charles Honton" <chas@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 <sebbaz@gmail.com> wrote:
> >
> > On 13 June 2016 at 01:00, Charles Honton <chas@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 <garydgregory@gmail.com>
> wrote:
> >>>
> >>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <britter@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 <sebbaz@gmail.com> schrieb am So., 12. Juni 2016 um 13:22
Uhr:
> >>>>
> >>>>> On 12 June 2016 at 08:41, Pascal Schumacher <
> pascalschumacher@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-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message