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:
>>>> I've just opened the new API changes tracker for Java libraries:
>>>> 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:
>>>> 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 :(
>> 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
>> 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
> tool work on jigsaw modules?
> Maybe also your tool can check about (fully classified) methods which actually
> 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)