On 05/26/2011 12:54 PM, Niels Thykier wrote:
Turns out I cannot think of an example of an ABI breakage in Java that
is not also an API breakage (in some sense or another). Maybe someone
else on list can think of one (where symbols/shlibs tracking would be
helpful).
Maybe narrowing the return type of a primitive? Or generalizing an
object type paramenter?
I know at least 6 kinds of API changes that can break binary/behavioral
(ABI) compatibility and don't break source (API) compatibility:
1. Change a non-final class field to be static (causes
IncompatibleClassChangeError exception)
2. Change the value of a final class constant field (behavioral, the
old value inlined at compile-time to the client code and will be
used instead of the new one)
3. Change a class field to be non-final (behavioral, the same effect
as in the previous one)
4. Change a class method to be non-abstract (behavioral)
5. Override a class method (behavioral)
6. Move a class method up class hierarchy (behavioral)
Also you might be interested to read about the clirr tool [1],
"Achieving API Binary Compatibility" article [2] or about the
upstream-tracker service for Java [3].
[1] Clirr Tool <http://clirr.sourceforge.net/> - checks Java libraries
for binary and source compatibility
[2] "Achieving API Binary Compatibility"
<http://wiki.eclipse.org/Evolving_Java-based_APIs_2> - article about
binary compatibility with notes about source compatibility
[3] Upstream Tracker for Java
<http://linuxtesting.org/upstream-tracker/java/> - looking for new
releases of various libraries and checking them for backward binary and
source compatibility
--
Andrey Ponomarenko
Department for Operating Systems at ISPRAS
web: http://www.LinuxTesting.org
mail: [email protected]
