On 03/29/2016 01:33 PM, Ponomarenko Andrey wrote:
29.03.2016, 13:12, "Jiri Vanek":
On 03/26/2016 04:19 PM, Ponomarenko Andrey wrote:
Hello,
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 libraries would you like to see in the tracker?
Hello! It is very nice tool.. however...
Is it just my imagination that it is one 8000 lines perl script?
You can do the same in five java classes, 20lines code each....
As perl exercise? You beat most of us....:) But I doubt anybody will be ever able to maintain that :(
J.
Hello,
There is no better tool yet, so I've used it as the first step. The best alternative is the Clirr tool that contains 7k lines of Java code but it is not flexible enough and doesn't detect all compatibility issues. However I'll probably add reports of the Clirr too in order to compare results.
This is not a request to package the tool (actually, there is nothing to package — it works anywhere without the need to compile anything, so I'll maintain it by myself). I just want to ask for what libraries you would like to see compatibility reports?
Thanks for your feedback.
You may add openjdk itself.
It would be rally nice to see how java api evolves during the lifecycle of single jdk (eg 7 or 8
[and there should be 100% backward comaptibility1) ) but much more interesting would be to see the
api changes in major jdk updates (from 6->7, and from 7->8 (or also from 6->8!) ) however... Jdk9 is
coming, and there are modules. So although I would really like to see 8->9 api change...Will your
tool work on jigsaw modules?
Maybe also your tool can check about (fully classified) methods which actually changed classapth
origin (more simple words - from one jar/module to another jar/module x module/jar)
From other lucene crossed my mind
Still - I would strongly advice you to move the implementation to java. Unlike native, java have api
to check for api. You can learn java on this, and it will make same effect just in much smaller effort.
All best!
J.
ps: is https://github.com/lvc/abi-compliance-checker/blob/master/abi-compliance-checker.pl ti 23 000
lines long perl code?
I admire your perl knowledge, but you should made your work modular and so .. readable a maintainable..
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
