Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
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 MINORbaseline 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms=03qLQLtoV6C-ROVud69V3ylfqKPTgb75RHT44N2MDN0=aMhF9Peul2ok8PFZTlIG42rzXQY1za2F24iRJva3Plg=
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
Thanks All!
- Ray
On Tue, Dec 5, 2017 at 9:03 AM, Timothy Ward <tim.w...@paremus.com> wrote:
> 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>
> 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 do
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
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 >>>
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
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)
> Se
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
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 <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 | 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 do
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
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 <http://www.bosch.com/>
> Tel. +49 7153 666-1155 | 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]
> 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
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
You’re right. Since the impact is so low we did consider making this a MICRO
change.
However, in bnd we remove the micro qualifier to prevent the static transitive
graph that Maven requires. I.e. the MICRO is the ‘oil’ between the modules, it
may not signal incompatibility. However, this implies that a MICRO change is
not only backward compatible but also forward compatible. Turning an interface
method into a default method is, however, not forward compatible. A bundle
compiled against the later MICRO version does require that version to be
present in runtime, unlike a bug fix or documentation fix but does not require
this micro version because the MICRO is stripped.
Kind regards,
Peter Kriens
> On 5 Dec 2017, at 07: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 <http://www.bosch.com/>
> Tel. +49 7153 666-1155 | 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]
> 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
Re: [osgi-dev] making an existing interface method default causes MINOR baseline change
Hi,
IMHO it is a MINOR change because it is not a breaking change. ☺
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 | 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] 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-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://mail.osgi.org/mailman/listinfo/osgi-dev
