Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[chris . gray]

> On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave  wrote:
>
>> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-
>> 13.html#jls-13.4.15.
>>
>> If an API is released and then you change the API such that the return
>> type is different, e.g. List to Collection, that is a binary
>> incompatible
>> change. The user of the API may expect it to be a List and invoke List
>> methods on it.
>>
>
> Changing the return type from a more specific type (e.g. List ) to a more
> general type (e.g. Collection) is an intrinsically breaking change, for
> the
> reasons you note.
>
> Changing in the other direction from a more general type to a more
> specific
> one is not intrinsically breaking, since we know the value returned by the
> new method must be assignment compatible with the old code:
>
> If the method returns a reference type, only an *areturn* instruction may
> be used, and the type of the returned value must be assignment compatible
> with the return descriptor of the method (JLS §5.2, §4.3.3
> 
> ).
>
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.9.2
>
> [...]

Yes, it should be possible to fit the round peg into the elliptical hole
by means of "bytecode manipulation" (or rather constant-pool manipulation,
as you point out). However I doubt that it is worth the trouble (and there
will surely be some 'interesting' corner cases to deal with). As BJ
pointed out, OSGi is all about binary compatibility not source
compatibility, and I don't think it is helpful to blur this distinction.

> [ Alternatively, I believe it might technically be possible to have two
> methods in a class file that differ only in return type.
>  The JVMS states that "No two methods in one class file may have the same
> name and descriptor", and the prolog code doesn't seem to parse the
> descriptor in places that one would expect it to (e.g. checking for
> non-override of final methods).
>
>  https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6
>
>
> I am pretty sure that this would not end well :)  ]

That would be an example of the exotic category "legal class file which
could not be generated by a correct Java compiler from a valid Java
program". Maybe not so exotic these days, with so many other languages
being compiled to the JVM target.


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Simon Spero]

On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave  wrote:

> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-
> 13.html#jls-13.4.15.
>
> If an API is released and then you change the API such that the return
> type is different, e.g. List to Collection, that is a binary incompatible
> change. The user of the API may expect it to be a List and invoke List
> methods on it.
>

Changing the return type from a more specific type (e.g. List ) to a more
general type (e.g. Collection) is an intrinsically breaking change, for the
reasons you note.

Changing in the other direction from a more general type to a more specific
one is not intrinsically breaking, since we know the value returned by the
new method must be assignment compatible with the old code:

If the method returns a reference type, only an *areturn* instruction may
be used, and the type of the returned value must be assignment compatible
with the return descriptor of the method (JLS §5.2, §4.3.3

).

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.9.2

The reason that the change is  not binary compatible in the JVM due to the
way that linkage is specified. The parameter and return types that combine
with the class and method name to be invoked are mangled into a method
descriptor, which is as a utf8 constant, and matching for linkage is done
using that constant.

Converting a class file to invoke the method with the new return type
simply requires replacing the appropriate thing in the constant pool. This
 may require changes to up to three constants, depending on whether there
are other method references that share the old descriptor.
 Metadata could be associated with a bundle indicating that if a specific
 set of method refs / name and types / descriptors  are updated in the byte
code, the updated bundle can be consider to have only undergone a minor
change, rather than a major.

[ Alternatively, I believe it might technically be possible to have two
methods in a class file that differ only in return type.
 The JVMS states that "No two methods in one class file may have the same
name and descriptor", and the prolog code doesn't seem to parse the
descriptor in places that one would expect it to (e.g. checking for
non-override of final methods).

 https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6


I am pretty sure that this would not end well :)  ]

Simon
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[BJ Hargrave]

Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15.
 
If an API is released and then you change the API such that the return type is different, e.g. List to Collection, that is a binary incompatible change. The user of the API may expect it to be a List and invoke List methods on it.
 
You seem to be referring to covariant return types [1]. Binary compatibility does not care that the return type is covariant to the return type of the overridden method. If you change the return type, you break binary compatibility. It may be source compatible, but not binary compatible.
 
[1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#d5e11368
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Neil Bartlett <njbartl...@gmail.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Thu, May 4, 2017 4:51 PM 
BJ, is that still the case if we change the return type to a subtype of the original return type?
 
Ever since Java 5 it has been legal to implement an interface method and return a more specialised type than the interface demands… this would suggest a Minor API change (as long as we’re talking about a Provider Type interface).
 
Neil 

On 4 May 2017, at 15:02, BJ Hargrave <hargr...@us.ibm.com> wrote: 

This is not true from a binary compatibility point of view. See https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15. Changing the return type is the equivalent of deleting the old method and adding a new method. So it is in fact a binary incompatible change: A major change (method delete).
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Robert Munteanu <robert.munte...@gmail.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Thu, May 4, 2017 5:40 AM 
Hi Simon,On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:> I'm trying to clarify some thoughts in my own mind about how different kinds> of backwards compatibility interact with different kinds of version> numbering.>> There are at least two dimensions of backwards compatibility of relevance:> binary v. source, and provider v. consumer. Not all combinations are> important  to OSGI , but there do to seem to be some situations where> different use types suggest different potential version numbers (rather than> ranges).>> 1. Source compatible but binary incompatible changes.> In Java, the most commonly discussed  changes of this kind are specializing> a method return types (e.g. Collection  => List). I>> Under standard Java linkage rules, this will cause the methods to have> different signatures, making them incompatible, and requiring a major> version change.Not to detract from your main point, but method return types are notpart of the method's signature in Java.  https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2Robert>> Older source can be compiled against the newer library without changes,> either to the source code, or a hypothetical range of return specialized> (RS) versions ; if the source were changed to use the more specialized> return type,  it would require the increasing the minimum RS  version> number. Thus, only a minor RS bump is required.>> Where this becomes interesting is if an OSGI  framework is extended to be> able to rewrite calls from older bundles to use the newer method signature> (quasi-recompiling). That would allow the newer package to satisfy more> constraints.>> 2. Provider vs. Consumer : default methods>> One of the primary use cases for default methods is to allow for new methods> to be added to interfaces without requiring changes to existing providers.> These might be convenience methods, be optional with reasonable defaults, or> be implementable using existing methods, with more performant> implementations possible but not mandatory.>> Early experiments handling default methods in OSGI using micro versions> showed that that  approach was not viable.>> A different approach might be to consider changes that only add default> methods to be neutral to invisible to an implementation of the previous> version of the class (excluding accidental signature clash).>> To packages calling the new methods there has been a minor increase;> similarly for packages 

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Neil Bartlett]

BJ, is that still the case if we change the return type to a subtype of the 
original return type?

Ever since Java 5 it has been legal to implement an interface method and return 
a more specialised type than the interface demands… this would suggest a Minor 
API change (as long as we’re talking about a Provider Type interface).

Neil

> On 4 May 2017, at 15:02, BJ Hargrave <hargr...@us.ibm.com> wrote:
> 
> This is not true from a binary compatibility point of view. See 
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15 
> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15>. 
> Changing the return type is the equivalent of deleting the old method and 
> adding a new method. So it is in fact a binary incompatible change: A major 
> change (method delete).
> --
> 
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>  
>  
> - Original message -
> From: Robert Munteanu <robert.munte...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Different conceptual version numbers for different 
> forms of backwards compatibility?
> Date: Thu, May 4, 2017 5:40 AM
>  
> Hi Simon,
> 
> On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:
> > I'm trying to clarify some thoughts in my own mind about how different kinds
> > of backwards compatibility interact with different kinds of version
> > numbering.
> >
> > There are at least two dimensions of backwards compatibility of relevance:
> > binary v. source, and provider v. consumer. Not all combinations are
> > important  to OSGI , but there do to seem to be some situations where
> > different use types suggest different potential version numbers (rather than
> > ranges).
> >
> > 1. Source compatible but binary incompatible changes.
> > In Java, the most commonly discussed  changes of this kind are specializing
> > a method return types (e.g. Collection  => List). I
> >
> > Under standard Java linkage rules, this will cause the methods to have
> > different signatures, making them incompatible, and requiring a major
> > version change.
> 
> Not to detract from your main point, but method return types are not
> part of the method's signature in Java.
> 
>   https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2 
> <https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2>
> 
> Robert
> 
> >
> > Older source can be compiled against the newer library without changes,
> > either to the source code, or a hypothetical range of return specialized
> > (RS) versions ; if the source were changed to use the more specialized
> > return type,  it would require the increasing the minimum RS  version
> > number. Thus, only a minor RS bump is required.
> >
> > Where this becomes interesting is if an OSGI  framework is extended to be
> > able to rewrite calls from older bundles to use the newer method signature
> > (quasi-recompiling). That would allow the newer package to satisfy more
> > constraints.
> >
> > 2. Provider vs. Consumer : default methods
> >
> > One of the primary use cases for default methods is to allow for new methods
> > to be added to interfaces without requiring changes to existing providers.
> > These might be convenience methods, be optional with reasonable defaults, or
> > be implementable using existing methods, with more performant
> > implementations possible but not mandatory.
> >
> > Early experiments handling default methods in OSGI using micro versions
> > showed that that  approach was not viable.
> >
> > A different approach might be to consider changes that only add default
> > methods to be neutral to invisible to an implementation of the previous
> > version of the class (excluding accidental signature clash).
> >
> > To packages calling the new methods there has been a minor increase;
> > similarly for packages that implement one or more of the default methods.
> >
> > It seems to me as if there is a separate conceptual version number is
> > default aware, and  that need not have the minor bump required in the
> > primary version number.
> >
> > [I'm getting ready to run analysis over a mostly complete set of all bundles
> > in the index on the ibiblio maven central mirror, which is mostly complete
> > through 11/2016, where a bundle is defined to be any artifact that had a

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Robert Munteanu]

On Wed, May 3, 2017 at 10:46 PM, Simon Spero  wrote:
> Where this becomes interesting is if an OSGI  framework is extended to be
> able to rewrite calls from older bundles to use the newer method signature
> (quasi-recompiling). That would allow the newer package to satisfy more
> constraints.

How would see this happen in practice? The current requirements and
constraints are based on the binary compatibility - both when trying
to wire package imports and when generating package versions.

Do you suggest that the process of resolving package dependencies
disregard certain kinds of constraints and try to recompile the source
if available and then re-resolve?

Robert

-- 
http://robert.muntea.nu/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Robert Munteanu]

On Thu, May 4, 2017 at 5:02 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:
> This is not true from a binary compatibility point of view. See
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15.
> Changing the return type is the equivalent of deleting the old method and
> adding a new method. So it is in fact a binary incompatible change: A major
> change (method delete).

I see, thank you.

Robert


> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Robert Munteanu <robert.munte...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Different conceptual version numbers for different
> forms of backwards compatibility?
> Date: Thu, May 4, 2017 5:40 AM
>
> Hi Simon,
>
> On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:
>> I'm trying to clarify some thoughts in my own mind about how different
>> kinds
>> of backwards compatibility interact with different kinds of version
>> numbering.
>>
>> There are at least two dimensions of backwards compatibility of relevance:
>> binary v. source, and provider v. consumer. Not all combinations are
>> important  to OSGI , but there do to seem to be some situations where
>> different use types suggest different potential version numbers (rather
>> than
>> ranges).
>>
>> 1. Source compatible but binary incompatible changes.
>> In Java, the most commonly discussed  changes of this kind are
>> specializing
>> a method return types (e.g. Collection  => List). I
>>
>> Under standard Java linkage rules, this will cause the methods to have
>> different signatures, making them incompatible, and requiring a major
>> version change.
>
> Not to detract from your main point, but method return types are not
> part of the method's signature in Java.
>
>   https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2
>
> Robert
>
>>
>> Older source can be compiled against the newer library without changes,
>> either to the source code, or a hypothetical range of return specialized
>> (RS) versions ; if the source were changed to use the more specialized
>> return type,  it would require the increasing the minimum RS  version
>> number. Thus, only a minor RS bump is required.
>>
>> Where this becomes interesting is if an OSGI  framework is extended to be
>> able to rewrite calls from older bundles to use the newer method signature
>> (quasi-recompiling). That would allow the newer package to satisfy more
>> constraints.
>>
>> 2. Provider vs. Consumer : default methods
>>
>> One of the primary use cases for default methods is to allow for new
>> methods
>> to be added to interfaces without requiring changes to existing providers.
>> These might be convenience methods, be optional with reasonable defaults,
>> or
>> be implementable using existing methods, with more performant
>> implementations possible but not mandatory.
>>
>> Early experiments handling default methods in OSGI using micro versions
>> showed that that  approach was not viable.
>>
>> A different approach might be to consider changes that only add default
>> methods to be neutral to invisible to an implementation of the previous
>> version of the class (excluding accidental signature clash).
>>
>> To packages calling the new methods there has been a minor increase;
>> similarly for packages that implement one or more of the default methods.
>>
>> It seems to me as if there is a separate conceptual version number is
>> default aware, and  that need not have the minor bump required in the
>> primary version number.
>>
>> [I'm getting ready to run analysis over a mostly complete set of all
>> bundles
>> in the index on the ibiblio maven central mirror, which is mostly complete
>> through 11/2016, where a bundle is defined to be any artifact that had a
>> BSN
>> in the manifest when processed by the nexus (now maven) indexer.  I may
>> augment this set with output of any PAX wrap: URLs mentioned in Karaf
>> feature files.
>>
>> Some of my primary hypotheses is that the majority of these bundles do not
>> follow semantic versioning rules, and that some, but not all, of the set
>> of
>> importing bundleswill have detectable possible linkage errors (e.g a
>> reference to a removed cl

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Simon Spero]

void is an odd case; changing from void to non-void can be seen
generalizing not specializing; however, since a void value can't be used,
the set of SOM reasonable uses in older classes is empty.

A transform would be on the older, using, compiled classes, and is only
licensed  by source compatibility rules (though it doesn't have to care
about things like  checked exceptions being removed :)

Simon

On May 4, 2017 10:56 AM, "Matt Sicker" <boa...@gmail.com> wrote:

> Yeah, I was about to bring that up as well. Changing something from void
> to an object return type breaks binary compatibility, so you can't make an
> old void API into a fluent builder-style API without breaking the ABI. The
> difference between binary and source compatibility is rather fun to deal
> with, and that doesn't even delve into the API versus SPI contract of
> compatibility.
>
> On 4 May 2017 at 09:02, BJ Hargrave <hargr...@us.ibm.com> wrote:
>
>> This is not true from a binary compatibility point of view. See
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15.
>> Changing the return type is the equivalent of deleting the old method and
>> adding a new method. So it is in fact a binary incompatible change: A major
>> change (method delete).
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> <(386)%20848-1781>
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> <(386)%20848-3788>
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: Robert Munteanu <robert.munte...@gmail.com>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
>> Cc:
>> Subject: Re: [osgi-dev] Different conceptual version numbers for
>> different forms of backwards compatibility?
>> Date: Thu, May 4, 2017 5:40 AM
>>
>> Hi Simon,
>>
>> On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:
>> > I'm trying to clarify some thoughts in my own mind about how different
>> kinds
>> > of backwards compatibility interact with different kinds of version
>> > numbering.
>> >
>> > There are at least two dimensions of backwards compatibility of
>> relevance:
>> > binary v. source, and provider v. consumer. Not all combinations are
>> > important  to OSGI , but there do to seem to be some situations where
>> > different use types suggest different potential version numbers (rather
>> than
>> > ranges).
>> >
>> > 1. Source compatible but binary incompatible changes.
>> > In Java, the most commonly discussed  changes of this kind are
>> specializing
>> > a method return types (e.g. Collection  => List). I
>> >
>> > Under standard Java linkage rules, this will cause the methods to have
>> > different signatures, making them incompatible, and requiring a major
>> > version change.
>>
>> Not to detract from your main point, but method return types are not
>> part of the method's signature in Java.
>>
>>   https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2
>>
>> Robert
>>
>> >
>> > Older source can be compiled against the newer library without changes,
>> > either to the source code, or a hypothetical range of return specialized
>> > (RS) versions ; if the source were changed to use the more specialized
>> > return type,  it would require the increasing the minimum RS  version
>> > number. Thus, only a minor RS bump is required.
>> >
>> > Where this becomes interesting is if an OSGI  framework is extended to
>> be
>> > able to rewrite calls from older bundles to use the newer method
>> signature
>> > (quasi-recompiling). That would allow the newer package to satisfy more
>> > constraints.
>> >
>> > 2. Provider vs. Consumer : default methods
>> >
>> > One of the primary use cases for default methods is to allow for new
>> methods
>> > to be added to interfaces without requiring changes to existing
>> providers.
>> > These might be convenience methods, be optional with reasonable
>> defaults, or
>> > be implementable using existing methods, with more performant
>> > implementations possible but not mandatory.
>> >
>> > Early experiments handling default methods in OSGI using micro versions
>> > showed that that  approach was not viable.
>> >
>> > A different approach might be to consid

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Simon Spero]

On May 4, 2017 5:40 AM, "Robert Munteanu"  wrote:

Hi Simon,


Not to detract from your main point, but method return types are not
part of the method's signature in Java.

  https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2

Robert


"You are technically correct- the best kind of correct!" :)

The relevant JLS binary compatibility rule combines the result type and
signature:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.4.15

The JVMS  talks in terms of "method descriptors", which are where the link
lossage happens:
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.3.3

It does have a concept of method signatures, which are attributes used to
support reflection on parameterized methods. The definition in the JVMS
includes (amongst other things) the result type... However, this isn't
relevant to what I was talking about, so you're still right.

Simon
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[Matt Sicker]

Yeah, I was about to bring that up as well. Changing something from void to
an object return type breaks binary compatibility, so you can't make an old
void API into a fluent builder-style API without breaking the ABI. The
difference between binary and source compatibility is rather fun to deal
with, and that doesn't even delve into the API versus SPI contract of
compatibility.

On 4 May 2017 at 09:02, BJ Hargrave <hargr...@us.ibm.com> wrote:

> This is not true from a binary compatibility point of view. See
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15.
> Changing the return type is the equivalent of deleting the old method and
> adding a new method. So it is in fact a binary incompatible change: A major
> change (method delete).
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> <(386)%20848-1781>
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> <(386)%20848-3788>
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Robert Munteanu <robert.munte...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Different conceptual version numbers for different
> forms of backwards compatibility?
> Date: Thu, May 4, 2017 5:40 AM
>
> Hi Simon,
>
> On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:
> > I'm trying to clarify some thoughts in my own mind about how different
> kinds
> > of backwards compatibility interact with different kinds of version
> > numbering.
> >
> > There are at least two dimensions of backwards compatibility of
> relevance:
> > binary v. source, and provider v. consumer. Not all combinations are
> > important  to OSGI , but there do to seem to be some situations where
> > different use types suggest different potential version numbers (rather
> than
> > ranges).
> >
> > 1. Source compatible but binary incompatible changes.
> > In Java, the most commonly discussed  changes of this kind are
> specializing
> > a method return types (e.g. Collection  => List). I
> >
> > Under standard Java linkage rules, this will cause the methods to have
> > different signatures, making them incompatible, and requiring a major
> > version change.
>
> Not to detract from your main point, but method return types are not
> part of the method's signature in Java.
>
>   https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2
>
> Robert
>
> >
> > Older source can be compiled against the newer library without changes,
> > either to the source code, or a hypothetical range of return specialized
> > (RS) versions ; if the source were changed to use the more specialized
> > return type,  it would require the increasing the minimum RS  version
> > number. Thus, only a minor RS bump is required.
> >
> > Where this becomes interesting is if an OSGI  framework is extended to be
> > able to rewrite calls from older bundles to use the newer method
> signature
> > (quasi-recompiling). That would allow the newer package to satisfy more
> > constraints.
> >
> > 2. Provider vs. Consumer : default methods
> >
> > One of the primary use cases for default methods is to allow for new
> methods
> > to be added to interfaces without requiring changes to existing
> providers.
> > These might be convenience methods, be optional with reasonable
> defaults, or
> > be implementable using existing methods, with more performant
> > implementations possible but not mandatory.
> >
> > Early experiments handling default methods in OSGI using micro versions
> > showed that that  approach was not viable.
> >
> > A different approach might be to consider changes that only add default
> > methods to be neutral to invisible to an implementation of the previous
> > version of the class (excluding accidental signature clash).
> >
> > To packages calling the new methods there has been a minor increase;
> > similarly for packages that implement one or more of the default methods.
> >
> > It seems to me as if there is a separate conceptual version number is
> > default aware, and  that need not have the minor bump required in the
> > primary version number.
> >
> > [I'm getting ready to run analysis over a mostly complete set of all
> bundles
> > in the index on the ibiblio maven central mirror, which is mostly
> complete
> > through 11/2016, where a bundle is defined to be any artifact that had a
> BSN
> > in the manifest

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[BJ Hargrave]

This is not true from a binary compatibility point of view. See https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.15. Changing the return type is the equivalent of deleting the old method and adding a new method. So it is in fact a binary incompatible change: A major change (method delete).
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Robert Munteanu <robert.munte...@gmail.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Thu, May 4, 2017 5:40 AM 
Hi Simon,On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:> I'm trying to clarify some thoughts in my own mind about how different kinds> of backwards compatibility interact with different kinds of version> numbering.>> There are at least two dimensions of backwards compatibility of relevance:> binary v. source, and provider v. consumer. Not all combinations are> important  to OSGI , but there do to seem to be some situations where> different use types suggest different potential version numbers (rather than> ranges).>> 1. Source compatible but binary incompatible changes.> In Java, the most commonly discussed  changes of this kind are specializing> a method return types (e.g. Collection  => List). I>> Under standard Java linkage rules, this will cause the methods to have> different signatures, making them incompatible, and requiring a major> version change.Not to detract from your main point, but method return types are notpart of the method's signature in Java.  https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2Robert>> Older source can be compiled against the newer library without changes,> either to the source code, or a hypothetical range of return specialized> (RS) versions ; if the source were changed to use the more specialized> return type,  it would require the increasing the minimum RS  version> number. Thus, only a minor RS bump is required.>> Where this becomes interesting is if an OSGI  framework is extended to be> able to rewrite calls from older bundles to use the newer method signature> (quasi-recompiling). That would allow the newer package to satisfy more> constraints.>> 2. Provider vs. Consumer : default methods>> One of the primary use cases for default methods is to allow for new methods> to be added to interfaces without requiring changes to existing providers.> These might be convenience methods, be optional with reasonable defaults, or> be implementable using existing methods, with more performant> implementations possible but not mandatory.>> Early experiments handling default methods in OSGI using micro versions> showed that that  approach was not viable.>> A different approach might be to consider changes that only add default> methods to be neutral to invisible to an implementation of the previous> version of the class (excluding accidental signature clash).>> To packages calling the new methods there has been a minor increase;> similarly for packages that implement one or more of the default methods.>> It seems to me as if there is a separate conceptual version number is> default aware, and  that need not have the minor bump required in the> primary version number.>> [I'm getting ready to run analysis over a mostly complete set of all bundles> in the index on the ibiblio maven central mirror, which is mostly complete> through 11/2016, where a bundle is defined to be any artifact that had a BSN> in the manifest when processed by the nexus (now maven) indexer.  I may> augment this set with output of any PAX wrap: URLs mentioned in Karaf> feature files.>> Some of my primary hypotheses is that the majority of these bundles do not> follow semantic versioning rules, and that some, but not all, of the set of> importing bundleswill have detectable possible linkage errors (e.g a> reference to a removed class or method).>> A secondary hypotheses is that applying recommended bndlib Baseline> renumbering to all (non qualified?)  versions in a sequence, mapping> external referencing import ranges to the appropriate rebased range will> result in a non-trivial set of unsatisfiable dependencies.>> There are other hypotheses that I'm trying to refine; what I'm hoping to> find are indica that can be used to predict  more reliable import ranges for> given maven artifact sequences, and to identify opportunities for safely> relaxing constraints.]>> Simon>>>>>> ___>

Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?

[BJ Hargrave]

Semantic Versioning in OSGi is about binary compatibility and not source compatibility.
 
Adding a default method to an interface is always a minor version increment. For provider type interfaces, the consumer can depend upon the new method and must declare that by requiring the higher minor version. For consumer type interfaces, the consumer does not have to implement the default method, so it is not a major version change but the provider can depend upon the new method and must declare that by requiring the higher minor version. A micro version bump is insufficient as there is a new API which API users can depend upon being available.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Simon Spero Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Wed, May 3, 2017 6:45 PM I'm trying to clarify some thoughts in my own mind about how different kinds of backwards compatibility interact with different kinds of version numbering. 
 
There are at least two dimensions of backwards compatibility of relevance: binary v. source, and provider v. consumer. Not all combinations are important  to OSGI , but there do to seem to be some situations where different use types suggest different potential version numbers (rather than ranges). 
 
1. Source compatible but binary incompatible changes. 
In Java, the most commonly discussed  changes of this kind are specializing a method return types (e.g. Collection  => List). I 
 
Under standard Java linkage rules, this will cause the methods to have different signatures, making them incompatible, and requiring a major version change. 
 
Older source can be compiled against the newer library without changes, either to the source code, or a hypothetical range of return specialized  (RS) versions ; if the source were changed to use the more specialized return type,  it would require the increasing the minimum RS  version number. Thus, only a minor RS bump is required. 
 
Where this becomes interesting is if an OSGI  framework is extended to be able to rewrite calls from older bundles to use the newer method signature (quasi-recompiling). That would allow the newer package to satisfy more constraints. 
 
2. Provider vs. Consumer : default methods 
 
One of the primary use cases for default methods is to allow for new methods to be added to interfaces without requiring changes to existing providers. 
These might be convenience methods, be optional with reasonable defaults, or be implementable using existing methods, with more performant implementations possible but not mandatory. 
 
Early experiments handling default methods in OSGI using micro versions showed that that  approach was not viable. 
 
A different approach might be to consider changes that only add default methods to be neutral to invisible to an implementation of the previous version of the class (excluding accidental signature clash). 
 
To packages calling the new methods there has been a minor increase; similarly for packages that implement one or more of the default methods. 
 
It seems to me as if there is a separate conceptual version number is default aware, and  that need not have the minor bump required in the primary version number. 
 
[I'm getting ready to run analysis over a mostly complete set of all bundles in the index on the ibiblio maven central mirror, which is mostly complete through 11/2016, where a bundle is defined to be any artifact that had a BSN in the manifest when processed by the nexus (now maven) indexer.  I may augment this set with output of any PAX wrap: URLs mentioned in Karaf feature files.  
 
Some of my primary hypotheses is that the majority of these bundles do not follow semantic versioning rules, and that some, but not all, of the set of importing bundleswill have detectable possible linkage errors (e.g a reference to a removed class or method). 
 
A secondary hypotheses is that applying recommended bndlib Baseline renumbering to all (non qualified?)  versions in a sequence, mapping external referencing import ranges to the appropriate rebased range will result in a non-trivial set of unsatisfiable dependencies. 
 
There are other hypotheses that I'm trying to refine; what I'm hoping to find are indica that can be used to predict  more reliable import ranges for given maven artifact sequences, and to identify opportunities for safely relaxing constraints.] 
 
Simon
 
 
 
 
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://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] Different conceptual version numbers for different forms of backwards compatibility?

[Robert Munteanu]

Hi Simon,

On Wed, May 3, 2017 at 10:46 PM, Simon Spero  wrote:
> I'm trying to clarify some thoughts in my own mind about how different kinds
> of backwards compatibility interact with different kinds of version
> numbering.
>
> There are at least two dimensions of backwards compatibility of relevance:
> binary v. source, and provider v. consumer. Not all combinations are
> important  to OSGI , but there do to seem to be some situations where
> different use types suggest different potential version numbers (rather than
> ranges).
>
> 1. Source compatible but binary incompatible changes.
> In Java, the most commonly discussed  changes of this kind are specializing
> a method return types (e.g. Collection  => List). I
>
> Under standard Java linkage rules, this will cause the methods to have
> different signatures, making them incompatible, and requiring a major
> version change.

Not to detract from your main point, but method return types are not
part of the method's signature in Java.

  https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2

Robert

>
> Older source can be compiled against the newer library without changes,
> either to the source code, or a hypothetical range of return specialized
> (RS) versions ; if the source were changed to use the more specialized
> return type,  it would require the increasing the minimum RS  version
> number. Thus, only a minor RS bump is required.
>
> Where this becomes interesting is if an OSGI  framework is extended to be
> able to rewrite calls from older bundles to use the newer method signature
> (quasi-recompiling). That would allow the newer package to satisfy more
> constraints.
>
> 2. Provider vs. Consumer : default methods
>
> One of the primary use cases for default methods is to allow for new methods
> to be added to interfaces without requiring changes to existing providers.
> These might be convenience methods, be optional with reasonable defaults, or
> be implementable using existing methods, with more performant
> implementations possible but not mandatory.
>
> Early experiments handling default methods in OSGI using micro versions
> showed that that  approach was not viable.
>
> A different approach might be to consider changes that only add default
> methods to be neutral to invisible to an implementation of the previous
> version of the class (excluding accidental signature clash).
>
> To packages calling the new methods there has been a minor increase;
> similarly for packages that implement one or more of the default methods.
>
> It seems to me as if there is a separate conceptual version number is
> default aware, and  that need not have the minor bump required in the
> primary version number.
>
> [I'm getting ready to run analysis over a mostly complete set of all bundles
> in the index on the ibiblio maven central mirror, which is mostly complete
> through 11/2016, where a bundle is defined to be any artifact that had a BSN
> in the manifest when processed by the nexus (now maven) indexer.  I may
> augment this set with output of any PAX wrap: URLs mentioned in Karaf
> feature files.
>
> Some of my primary hypotheses is that the majority of these bundles do not
> follow semantic versioning rules, and that some, but not all, of the set of
> importing bundleswill have detectable possible linkage errors (e.g a
> reference to a removed class or method).
>
> A secondary hypotheses is that applying recommended bndlib Baseline
> renumbering to all (non qualified?)  versions in a sequence, mapping
> external referencing import ranges to the appropriate rebased range will
> result in a non-trivial set of unsatisfiable dependencies.
>
> There are other hypotheses that I'm trying to refine; what I'm hoping to
> find are indica that can be used to predict  more reliable import ranges for
> given maven artifact sequences, and to identify opportunities for safely
> relaxing constraints.]
>
> Simon
>
>
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
http://robert.muntea.nu/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev