commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
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 <oliver.heger@oliver-heger.de>
> wrote:
>> Am 09.09.2012 14:26, schrieb sebb:
>>
>>> On 8 September 2012 15:45, Oliver Heger <oliver.heger@oliver-heger.de>
>>> wrote:

[snip]

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

> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message