You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Pascal Schumacher <pa...@gmx.net> on 2016/06/12 07:41:30 UTC
[lang] Time Package: Binary Breaking Changes Between 3.4 and Master
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
[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
[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
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
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by Gary Gregory <ga...@gmail.com>.
Should these be package private then?
G
On Jun 12, 2016 5:32 PM, "Charles Honton" <ch...@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 <se...@gmail.com> wrote:
> >
> > On 13 June 2016 at 01:00, Charles Honton <ch...@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 <ga...@gmail.com>
> wrote:
> >>>
> >>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <br...@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 <se...@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
>
>
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by Charles Honton <ch...@honton.org>.
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 <se...@gmail.com> wrote:
>
> On 13 June 2016 at 01:00, Charles Honton <ch...@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 <ga...@gmail.com> wrote:
>>>
>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <br...@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 <se...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>>
>>>>> On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by sebb <se...@gmail.com>.
On 13 June 2016 at 01:00, Charles Honton <ch...@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 <ga...@gmail.com> wrote:
>>
>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <br...@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 <se...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>
>>>> On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by Charles Honton <ch...@honton.org>.
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. 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, 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 <ga...@gmail.com> wrote:
>
> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <br...@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 <se...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>
>>> On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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
>>>
>>>
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by Gary Gregory <ga...@gmail.com>.
On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <br...@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 <se...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>
> > On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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
> >
> >
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by Benedikt Ritter <br...@apache.org>.
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.
Benedikt
sebb <se...@gmail.com> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
> On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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
>
>
Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Posted by sebb <se...@gmail.com>.
On 12 June 2016 at 08:41, Pascal Schumacher <pa...@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