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
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
