[lang] Time Package: Binary Breaking Changes Between 3.4 and Master

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Pascal Schumacher
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

sebb-2-2
On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Benedikt Ritter-4
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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:

> On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

garydgregory
On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>
> > On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Charles Honton
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 <[hidden email]> wrote:
>
> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>
>>> On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

sebb-2-2
On 13 June 2016 at 01:00, Charles Honton <[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>
>>>> On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]>
>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Charles Honton
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 <[hidden email]> wrote:
>
> On 13 June 2016 at 01:00, Charles Honton <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>>
>>>>> On 12 June 2016 at 08:41, Pascal Schumacher <[hidden email]>
>>>>> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

garydgregory
Should these be package private then?

G
On Jun 12, 2016 5:32 PM, "Charles Honton" <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On 13 June 2016 at 01:00, Charles Honton <[hidden email]> 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 <[hidden email]>
> wrote:
> >>>
> >>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
> >>>>
> >>>>> On 12 June 2016 at 08:41, Pascal Schumacher <
> [hidden email]>
> >>>>> 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: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

dbrosIus
In reply to this post by Pascal Schumacher
+1 better now than latter

-------- Original message --------
From: Gary Gregory <[hidden email]>
Date: 06/12/2016  8:56 PM  (GMT-05:00)
To: Commons Developers List <[hidden email]>
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" <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On 13 June 2016 at 01:00, Charles Honton <[hidden email]> 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 <[hidden email]>
> wrote:
> >>>
> >>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email]> 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 <[hidden email]> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
> >>>>
> >>>>> On 12 June 2016 at 08:41, Pascal Schumacher <
> [hidden email]>
> >>>>> 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: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Charles Honton
No, these are the interfaces that the end user should use.  (but not implement)

> On Jun 12, 2016, at 6:10 PM, dbrosIus <[hidden email]> wrote:
>
> +1 better now than latter
>
> -------- Original message --------
> From: Gary Gregory <[hidden email] <mailto:[hidden email]>>
> Date: 06/12/2016  8:56 PM  (GMT-05:00)
> To: Commons Developers List <[hidden email] <mailto:[hidden email]>>
> 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" <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> On 13 June 2016 at 01:00, Charles Honton <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>>>>
>>>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>>>>
>>>>>>> On 12 June 2016 at 08:41, Pascal Schumacher <
>> [hidden email] <mailto:[hidden email]>>
>>>>>>> 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: [hidden email] <mailto:[hidden email]>
>>>>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>>
>>>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Charles Honton
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 <[hidden email]> wrote:
>
> No, these are the interfaces that the end user should use.  (but not implement)
>
>> On Jun 12, 2016, at 6:10 PM, dbrosIus <[hidden email]> wrote:
>>
>> +1 better now than latter
>>
>> -------- Original message --------
>> From: Gary Gregory <[hidden email] <mailto:[hidden email]>>
>> Date: 06/12/2016  8:56 PM  (GMT-05:00)
>> To: Commons Developers List <[hidden email] <mailto:[hidden email]>>
>> 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" <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> On 13 June 2016 at 01:00, Charles Honton <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>>> wrote:
>>>>>>
>>>>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> schrieb am So., 12. Juni 2016 um 13:22 Uhr:
>>>>>>>
>>>>>>>> On 12 June 2016 at 08:41, Pascal Schumacher <
>>> [hidden email] <mailto:[hidden email]>>
>>>>>>>> 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: [hidden email] <mailto:[hidden email]>
>>>>>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>