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