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<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 > -- Matt Sicker <boa...@gmail.com>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
