When doFoo() was implemented in Bar some user's class could have been compiled to make a direct method call to Bar.doFoo() instead of via the Foo interface's Foo.doFoo() signature. It depends upon how the compiler emits the invokevirtual call in the bytecode. So when you remove the method from Bar, you could potentially break users of Bar that directly referenced the concrete method Bar.doFoo(). In fact I would think removing doFoo() from Bar should be a major change. The safest thing is to leave doFoo() in Bar and implement it as calling the super method. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: "Fauth Dirk \(AA-AS/EIS2-EU\) via osgi-dev" <osgi-dev@mail.osgi.org> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2017/12/05 11:35 Subject: Re: [osgi-dev] making an existing interface method default causes MINOR baseline change Sent by: osgi-dev-boun...@mail.osgi.org 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 | 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 ] 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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=03qLQLtoV6C-ROVud69V3ylfqKPTgb75RHT44N2MDN0&s=aMhF9Peul2ok8PFZTlIG42rzXQY1za2F24iRJva3Plg&e=
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
