Andrey, In which case compatibility is broken? If there is a method that returns void and you change it to return some type, it doesn't break anything, because currently nobody can assign the result of this method to a variable. I.e. in old code the returned value will be always ignored, therefore it can be of any type.
Is there anything else that I'm missing? -Val On Thu, Feb 2, 2017 at 3:49 AM, Andrey Mashenkov <andrey.mashen...@gmail.com > wrote: > Hi Igniters, > > > I'm working on IGNITE-4564 [1] to make our configuration classes and SPI > classes more convenient. > > There is no problem to change return type in setter method signatures > and override methods in child child classes to make them return more > accurate type. > > But, I found that we have set methods in some of our interfaces and > changing its signature may broke compatibility with user implementations. > > Here are example interfaces with setters: > org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean > org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyMXBean > org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean > org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean > org.apache.ignite.spi.checkpoint.CheckpointSpi > org.apache.ignite.spi.collision.CollisionSpi > org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean > > However we have interfaces with NO setters > org.apache.ignite.spi.loadbalancing.adaptive. > AdaptiveLoadBalancingSpiMBean. > > What can we do with it? > Change signature of setters without regarding compatibility? Or may be it > is possible to remove setters from some interfaces? > > Thought? > > > [1] https://issues.apache.org/jira/browse/IGNITE-4564 >
