29.03.2016, 14:49, "Jiri Vanek": > 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. > Thanks for suggested libraries. I've added OpenJDK and Lucene to my TODO list (there are about 10 pending libraries already suggested by the community). The Java code parser is the easiest and smallest part of the tool (and it should be rewritten in Java or any other language in the future because there is a lack of performance here). The hardest part is to compare API versions and generate report. So Perl is the best choice for this task. Also the tool is only one small part of the project. I'll release complete source code of the project a little bit later. You'll find modules there) Thank you. -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
