commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Plan for 2.0
Date Tue, 11 Sep 2012 19:27:35 GMT
Am 11.09.2012 00:08, schrieb sebb:
> On 10 September 2012 20:33, Oliver Heger <> wrote:
>> Am 09.09.2012 14:26, schrieb sebb:
>>> On 8 September 2012 15:45, Oliver Heger <>
>>> wrote:
>>>> Am 08.09.2012 03:44, schrieb sebb:
>>>>> On 7 September 2012 20:46, Oliver Heger <>
>>>>> wrote:
>>>>>> Hi all,
>>>>>> the pom was updated to make 2.0-SNAPSHOT the current development
>>>>>> version.
>>>>>> This means we are free to implement major changes without having
>>>>>> enforce
>>>>>> binary backwards compatibility.
>>>>> BC breakage will require package and Maven coordinate changes at some
>>>>> point just before release.
>>>> Yes, I am aware of this.
>>>>>> The question is: What are the goals for version 2.0? I would recommend
>>>>>> to
>>>>>> define a clear focus so that the next release will not take too long.
>>>>>> Obviously there are already people waiting for a [configuration]
>>>>>> version
>>>>>> compatible with [lang3].
>>>>>> Some points I have in mind are the following ones:
>>>>>> - Switch to [lang3]. This is the main reason for going to version
>>>>>> because this cannot be done in a binary compatible way.
>>>>> Not sure I follow that.
>>>>> Why would changing a dependency affect the API for Configuration?
>>>>> Does not make sense to me.
>>>> Some classes of [lang] are exposed in the public API of [configuration].
>>>> For
>>>> instance, variable substitution in configuration files is done by a
>>>> org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to
>>>> use can be set. So switching to [lang3] will effectively change the
>>>> public
>>>> API of [configuration] in an incompatible way.
>>> That seems very fragile. There has to be a better way to handle that.
>>> Fixing it will break the API (once), but at least the API will then be
>>> stable, regardless of what happens with LANG.
>> Do you mean all interfaces or classes from 3rd party libraries should be
>> wrapped so that they do not leak in the public API?
> Not sure it's necessary to wrap all 3rd party library APIs, just don't
> expose their classes in the Configuration API.
>> I agree that using 3rd party classes in the public API is obviously fragile
>> and should be avoided as much as possible. But I am not sure whether a
>> radical wrapping approach works in all cases.
>> Also, it might make reuse of classes harder for client code. Take for
>> instance the StrSubstitutor example. A client may already have a custom
>> implementation to be used with the corresponding [lang] classes. Now this
>> implementation cannot be used together with [configuration] because here a
>> slightly different interface is required - although the functionality is the
>> same.
> If you update Configuration to use lang3, then the custom
> implementation will break anyway - unless Configuration is updated to
> work with both Lang and Lang3.
> Do you really want that? Does not seem scalable.
> If custom classes in future have to implement a Configuration
> interface, rather than something from Lang, then at least the custom
> class is then only dependent on the Config. API.
> Whatever happens, custom classes are going to need to be changed if
> support for Lang is dropped in favour of Lang3.
> Or am I missing something here?

Yes, sure, client code will be affected by this change.

>> Not sure how to deal with this issue in general.
> Once the API dependency on Lang is removed, it won't be an issue.
My point was if we use functionality from a library like [lang] to 
implement concepts in [configuration], it might be natural to somehow 
pass objects from this library to [configuration] objects. Then they 
become part of the public API of [configuration]. Avoiding this will 
take some effort and may be less straight-forward from a user's point of 


>> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message