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 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: Neil Bartlett <njbartl...@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 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 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<String> => List<String>). 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

_______________________________________________
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

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

Reply via email to