API changes tracker for Java libraries

[Andrey Ponomarenko]

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/

[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?
>
>  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(a)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.

[Andrey Ponomarenko]

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.

[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.


All best!
   J.

ps: is https://github.com/lvc/abi-compliance-checker/blob/master/abi-compliance-...
ti 23 000 
lines long perl code?

I admire your perl knowledge, but you should made your work modular and so .. readable a
maintainable..

[Andrey Ponomarenko]

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.

[Andrey Ponomarenko]

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.

[Andrey Ponomarenko]

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.

[Jiri Vanek]

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.

[Michal Srb]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/java-devel

[Andrey Ponomarenko]

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...