sebb wrote: > On 10 September 2012 20:33, Oliver Heger <oliver.he...@oliver-heger.de> > wrote: >> Am 09.09.2012 14:26, schrieb sebb: >> >>> On 8 September 2012 15:45, Oliver Heger <oliver.he...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
