Path: csiph.com!news.mixmin.net!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod
From: Ponomarenko Andrey <andrewponomarenko@yandex.ru>
Newsgroups: linux.debian.maint.java
Subject: Re: API changes tracker for Java libraries
Date: Tue, 29 Mar 2016 18:50:03 +0200
Message-ID: <ri507-wp-25@gated-at.bofh.it>
References: <rgYk2-2G4-3@gated-at.bofh.it> <rgYDo-2MQ-7@gated-at.bofh.it>
Old-Return-Path: <andrewponomarenko@yandex.ru>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8
Approved: robomod@news.nic.it
Lines: 27
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.java:8966

26.03.2016, 18:45, "Emmanuel Bourg":
> Hi Andrey,
>
> Le 26/03/2016 16:15, Ponomarenko Andrey a écrit :
>
>>  I've just opened the new API changes tracker for Java libraries: http://abi-laboratory.pro/java/tracker/
>>
>>  As the first step I've prepared reports for a random set of libraries: Android, Berkeley DB JE, Commons Collections, Hadoop, log4j and SLF4J.
>>
>>  The reports are generated by the new 1.5 version of the japi-compliance-checker tool. It's a big and useful update and it's highly recommended to update the tool if you are using it in your project: https://github.com/lvc/japi-compliance-checker
>>
>>  I'd like to ask the community what other libraries would you like to see in the tracker?
>
> Thank you for japi-compliance-checker, I often use it to check the
> compatibility when upgrading sensitive libraries. The Apache Commons
> libraries aren't very interesting to track because they almost never
> break the compatibility by policy (note that you should split
> commons-collections and commons-collections4, these are two distinct
> APIs that can coexist in the same classpath). Some libraries I'd like to
> see in the tracker are BouncyCastle, ASM, CGLIB, Guava, Jetty, ICU4J, JNA.
>

Added report for ASM library: http://abi-laboratory.pro/java/tracker/timeline/asm/

I need some time to add others. Seems that there are a lot of critical issues in the basic japi-compliance-checker tool that should be fixed first (performance, RAM usage, size of the report for big sets of changes, separating the code into modules, etc.).

Thank you.