> On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: > >> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls- >> 13.html#jls-13.4.15. >> >> 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. >> > > Changing the return type from a more specific type (e.g. List ) to a more > general type (e.g. Collection) is an intrinsically breaking change, for > the > reasons you note. > > Changing in the other direction from a more general type to a more > specific > one is not intrinsically breaking, since we know the value returned by the > new method must be assignment compatible with the old code: > > If the method returns a reference type, only an *areturn* instruction may > be used, and the type of the returned value must be assignment compatible > with the return descriptor of the method (JLS §5.2, §4.3.3 > <https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.3.3> > ). > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.9.2 > > [...]
Yes, it should be possible to fit the round peg into the elliptical hole by means of "bytecode manipulation" (or rather constant-pool manipulation, as you point out). However I doubt that it is worth the trouble (and there will surely be some 'interesting' corner cases to deal with). As BJ pointed out, OSGi is all about binary compatibility not source compatibility, and I don't think it is helpful to blur this distinction. > [ Alternatively, I believe it might technically be possible to have two > methods in a class file that differ only in return type. > The JVMS states that "No two methods in one class file may have the same > name and descriptor", and the prolog code doesn't seem to parse the > descriptor in places that one would expect it to (e.g. checking for > non-override of final methods). > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6 > > > I am pretty sure that this would not end well :) ] That would be an example of the exotic category "legal class file which could not be generated by a correct Java compiler from a valid Java program". Maybe not so exotic these days, with so many other languages being compiled to the JVM target. _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
