commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [configuration] Plan for 2.0
Date Tue, 11 Sep 2012 18:22:20 GMT
sebb wrote:

> 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:


>>>> 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.

Is not possible here. The Configuration interface throws a checked exception 
which is derived from one of lang. And because of this you need currently 
lang as compile dep - runtime is not enough :-/

> Do you really want that? Does not seem scalable.

At least we can now think about it to avoid such a situation in future. 
ConfigurationException in configuration-3 should derive now directly from 

> 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?
>> Not sure how to deal with this issue in general.
> Once the API dependency on Lang is removed, it won't be an issue.

We can always add a convenience wrapper for the "current" lang version, e.g. 
if we use in future an interfaces like
org.apache.commons.confiugration.text.Substitutor our implementation can 
still depend on lang3 code. We may even provide a wrapper class as 
convenience for custom implementations of the lang3 StrSubstitutor.

- Jörg

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

View raw message