commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ponomarenko Andrey <>
Subject Re: Binary compatibility report
Date Mon, 06 Jun 2016 11:36:34 GMT

Thanks for reporting this bug. It's fixed for now.

The yellow background is used if there is at least one compatibility warning found or compatibility
rate is between 90 and 100 percents. Orange color is used when compatibility rate is between
80 and 90 percents. Red color is used when the rate is less than 80 percents and for removed
symbols. Blue color is used for added symbols.

The rules that are used to determine compatibility problems are taken from

The Clirr tool can't identify at least two compatibility problems:

* if a method became abstract in the class (may lead to InstantiationError exception)
* if a method became static/non-static (may lead to NoSuchMethodError exception)

... and two compatibility warnings:

* change of a final field value (e.g. string value from "A" to "B")
* added/removed exceptions of a method

Other differences from Clirr:

* report format
* 4 severity levels (High/Medium/Low/Safe vs ERROR/WARNING/INFO)
* counts affected symbols and compatibility rate
* separates binary- and source-compatibility problems in the report
* shows exact compiler error message, so one can google the report and understand that the
issue was happened due to incompatibility of versions
* lists added/removed symbols separately from other problems
* has an option to filter annotated/deprecated classes and methods
* detects renamed fields
* and more ...

Thank you.

05.06.2016, 11:31, "sebb":
> On 4 June 2016 at 15:19, Ponomarenko Andrey wrote:
>>  Hello,
>>  I've just prepared the report on backward compatibility for the Commons IO library
(BC — binary compatibility, SC — source compatibility):
> Thanks for the links.
> However I found it difficult to understand the output.
> For example, why are some backgrounds green and some yellow?
> Also, what are the rules that are used to determine whether or not a
> change affects compatibility?
> How do these compare with Clirr?
> I think there's a bug:
> The low level warning here
> says that it was caused by the change:
> "Added super-class java.lang.Object."
> That's not possible as a change.
>>  The report is generated daily by the japi-compliance-checker and japi-tracker tools:
>> (generates individual reports for
particular versions of the library)
>> (generates the timeline report)
>>  I can add more libraries to the tracker if somebody is interested (just reply this
Email with the list of library names to add). Current list of maintained libraries:
>>  Thank you.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message