We migrated some of this kind of type system to java.util.function.* for Apache 
Jena in the following way (I'll use ConfigOperator for the example):

1. Change all acceptor sites (params, ctor slots, wherever this type is being 
used) to use UnaryOperator<Configuration> and simultaneously

2. Deprecate ConfigOperator and make it extend UnaryOperator<Configuration>, 
with something like:

default Configuration apply(Configuration c) {
    return operate(c);
}

Users needn't change anything right away, but they are being informed that they 
can simply use java.util.function.* instead. I was in favor of this for Jena 
(in fact I made many of the commits) because I think that in the long run, a 
smaller footprint with the same semantics is worth more than super-tight 
back-compatibility _if_ the community can handle the change. After another 
release or so, Tamaya could excise the old types entirely.

Tamaya is still in incubation, and hasn't released 1.0. I think this is a good 
time to think long-term and make the API what it should be, even if us users 
have to tap-dance a bit to keep up. We'll all be better for it down the road.

My 2ยข... unless, of course, I'm completely misunderstanding what you mean by 
"API incompatibilities", which is certainly possible.

ajs6f

> On Jan 13, 2019, at 3:43 PM, Anatole Tresch <atsti...@gmail.com> wrote:
> 
> Hi all
> 
> in the current branch we deprecated *ConfigOperator, ConfigQuery* in favour
> of *UnaryOperator<Configuration> and Function<Configuration,T>. *This would
> allow us to reduce the
> API footprint in the midterm, but introduces API incompatibilities.
> 
> Since both interfaces are functional already, I could also *revert this
> change and stay with the interfaces above and therefore not introduce any
> incompatibilities on API side* (only on SPI side we have some).
> 
> WDYT? Agree reverting this API change, including adaptation on the
> extensions, mostly tamaya-functions ?
> 
> J Anatole
> 
> 
> -- 
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter:  @atsticks, @tamayaconf*

Reply via email to