commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Honton <c...@honton.org>
Subject Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master
Date Mon, 13 Jun 2016 01:18:33 GMT
No, these are the interfaces that the end user should use.  (but not implement)

> On Jun 12, 2016, at 6:10 PM, dbrosIus <dbrosIus@baybroadband.net> wrote:
> 
> +1 better now than latter
> 
> -------- Original message --------
> From: Gary Gregory <garydgregory@gmail.com <mailto:garydgregory@gmail.com>>

> Date: 06/12/2016  8:56 PM  (GMT-05:00) 
> To: Commons Developers List <dev@commons.apache.org <mailto:dev@commons.apache.org>>

> 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" <chas@honton.org <mailto: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 <mailto:sebbaz@gmail.com>>
wrote:
>>> 
>>> On 13 June 2016 at 01:00, Charles Honton <chas@honton.org <mailto: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
<mailto:garydgregory@gmail.com>>
>> wrote:
>>>>> 
>>>>> On Jun 12, 2016 4:25 AM, "Benedikt Ritter" <britter@apache.org <mailto: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 <mailto: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 <mailto: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
<mailto:dev-unsubscribe@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
<mailto:dev-help@commons.apache.org>
>>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
<mailto:dev-help@commons.apache.org>
>>>>>>> 
>>>>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

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