Does it matter that I'm getting a MINOR change while Foo and Bar are in the same, exported package?
- Ray On Dec 5, 2017 03:05, "Peter Kriens via osgi-dev" <osgi-dev@mail.osgi.org> wrote: > Great minds think alike (and it helped we were both in this discussion) :-) > > P > > On 5 Dec 2017, at 09:03, Timothy Ward via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > Ray - I assume that you’re asking why this is a MINOR change, rather than > a MICRO change? It’s obviously not a major change because the method exists > with the same signature everywhere both before and after. > > The reason that it’s a MINOR change is to do with the forward (rather than > backward) guarantees that the semantic versioning rules must make. > > In your example you end up deleting the original doFoo() implementation > from the Bar class. From this point on the Bar class has no knowledge of > this method, and the implementation *must* come from either a super type > (there aren’t any) or as a default method on the implemented interface. If > this doesn’t happen then the whole type hierarchy of Bar is broken - the > concrete types which subclass Bar simply don’t have an implementation of > the interface method that the contract says they must have! > > The only way to enforce this is to ensure that the updated Bar class > imports a version of Foo which is guaranteed to have the “default doFoo() > feature”. In semantic versioning new features always require at least a > MINOR bump so that people can reliably depend on them (depending on a MICRO > is not a good idea). That is what is happening here. > > Tim > > PS - I have just seen Peter’s email come in, which thankfully agrees with > what I’m saying! > > On 5 Dec 2017, at 06:43, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > > Hi, > > IMHO it is a MINOR change because it is not a breaking change. J > > With that change neither implementations of the Foo interface, nor classes > that extend the abstract Bar class will break. > > Implementations of the Foo interface can still implement the doFoo() > method and by doing this override the default behavior. Overriding a > default is not a breaking change as you neither add a new public method or > field, you just give a default implementation. > > Classes that extend Bar did not need to implement doFoo() before, as it > was implemented in Bar. Removing that method would be typically a breaking > change. But you are moving it as default method to the Foo interface. > Therefore Bar still has the doFoo() method implemented, as it is provided > by the Foo interface. > > I have to admit that I am not 100% sure about the byte code in the end and > if that matters. But as a user of the interface and abstract class, nothing > breaks. > > Mit freundlichen Grüßen / Best regards > > > *Dirk Fauth* > Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) > Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | > www.bosch.com > Tel. +49 7153 666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com > > Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; > Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar > Denner, > Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, > Dr. Markus Heyn, Dr. Dirk Hoheisel, > Christoph Kübel, Uwe Raschke, Peter Tyroller > > > *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail. > osgi.org <osgi-dev-boun...@mail.osgi.org>] *Im Auftrag von *Raymond Auge > via osgi-dev > *Gesendet:* Dienstag, 5. Dezember 2017 00:26 > *An:* OSGi Developer Mail List <osgi-dev@mail.osgi.org> > *Betreff:* [osgi-dev] making an existing interface method default causes > MINOR baseline change > > > Hey All, > I think the answer is "Yes it's a MINOR change", but I wanted to clarify. > > Assume I have the following interface in an exported package: > > public interface Foo { > public void doFoo(); > } > > And in the same package I have abstract class Bar which implements Foo: > > public abstract class Bar implements Foo { > public void doFoo() {...} > public abstract void doBar(); > } > > And I want to migrate to a default method because doFoo() logic rarely > changes: > > public interface Foo { > public default void doFoo() {...} > } > > public abstract class Bar implements Foo { > //public void doFoo() {...} > public abstract void doBar(); > } > > Can someone explain why this is a MINOR change? > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> > (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
