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<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 -- http://robert.muntea.nu/ _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
