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?
Thanks for your feedback.
BTW: The old tracker reports are still hosted by the ROSA Linux team but not updated anymore: http://upstream.rosalinux.ru/java/
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?
Thanks for your feedback.
BTW: The old tracker reports are still hosted by the ROSA Linux team but not updated anymore: http://upstream.rosalinux.ru/java/
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
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.
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.
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-che... ti 23 000 lines long perl code?
I admire your perl knowledge, but you should made your work modular and so .. readable a maintainable..
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.
29.03.2016, 16:06, "Ponomarenko Andrey":
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)
The report for Lucene library is ready: http://abi-laboratory.pro/java/tracker/timeline/lucene/
Thank you.
29.03.2016, 14:49, "Jiri Vanek":
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?
The report for OpenJDK is ready: http://abi-laboratory.pro/java/tracker/timeline/openjdk/
The report for Oracle JRE: http://abi-laboratory.pro/java/tracker/timeline/jre/
I'll add reports for Jdk9 soon.
Thank you.
On 04/08/2016 06:58 PM, Ponomarenko Andrey wrote:
29.03.2016, 14:49, "Jiri Vanek":
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?
The report for OpenJDK is ready: http://abi-laboratory.pro/java/tracker/timeline/openjdk/
The report for Oracle JRE: http://abi-laboratory.pro/java/tracker/timeline/jre/
I'll add reports for Jdk9 soon.
Thank you.
Well They *are* interesting. TY!
btw - you wrote that you would like to replace he part which is getting the methods out of jars/classes. I did similar task in past .. several times... So if you wont to replace your perl chunk by call to java, let me know offlist and we can agree on api where we will meet.
J.
Hi,
On Tue, 2016-03-29 at 14:33 +0300, Ponomarenko Andrey wrote:
<snip>
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.
There is also Revapi [1]. I am not saying it's better, I just wanted to mention it for completeness.
Thanks, Michal
[1]: http://revapi.org/
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.
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
01.04.2016, 11:14, "Michal Srb":
There is also Revapi [1]. I am not saying it's better, I just wanted to mention it for completeness.
Hello,
Thanks for the link. The tool looks very interesting. I've added it to the list of alternative tools: http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker#Similar_To...
java-devel@lists.fedoraproject.org
-
Andrey Ponomarenko -
Jiri Vanek -
Michal Srb