On 11 September 2012 19:22, Jörg Schaible <joerg.schai...@gmx.de> wrote: > 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 :-/
Another unfortunate API dependency ... >> 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. [Existing custom implementations are likely to target lang2 rather than lang3, surely?] Configuration developers need to decide whether to maintain compatibility or break it. If the former, all talk of switching to Lang3 is irrelevant, as it cannot be done cleanly. The best one could do would be to use Lang3 internally, but still use lang2 for external APIs. Rather messy just to use lang3. If the latter, then make sure that the API is changed such that it depends only on code which is in Configuration. Otherwise this issue will recur. For obvious reasons, all breaking changes should be done in the same release if at all possible. > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
