No, because other people may be implementing the Foo interface in their bundles.
Tim > On 5 Dec 2017, at 12:42, Raymond Auge <raymond.a...@liferay.com> wrote: > > 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 > <mailto: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 >> <mailto: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 <mailto: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 <http://www.bosch.com/> >>> Tel. +49 7153 666-1155 <tel:+49%207153%206661155> | dirk.fa...@de.bosch.com >>> <mailto: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-boun...@mail.osgi.org> >>> [mailto:osgi-dev-boun...@mail.osgi.org >>> <mailto: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 >>> <mailto: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 <mailto:osgi-dev@mail.osgi.org> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
