Re: Symbols/shlibs files for Java

[Andrey Ponomarenko <aponomarenko@ispras.ru>]

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 - checks Java libraries for binary and source compatibility
[2] "Achieving API Binary Compatibility" - article about binary compatibility with notes about source compatibility
[3] Upstream Tracker for 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:   aponomarenko@ispras.ru