API changes report for Fast Classpath Scanner

[lvc]

Hi,

I'd like to share my results on API changes analysis of the library: https://abi-laboratory.pro/java/tracker/timeline/fast-classpath-scanner/

The report is generated by the https://github.com/lvc/japi-compliance-checker tool for jars found at http://central.maven.org/maven2/io/github/lukehutch/fast-classpath-scanner/ according to https://wiki.eclipse.org/Evolving_Java-based_APIs_2.

Thank you.

[lukehutch]

Thanks, this is useful, but most of the removed methods are not part of the user-facing API. Is there an appropriate way to have only the public API checked for API changes? Should I be using some sort of method annotation to denote which methods should be considered public? (Some classes and methods are public even when the API is not intended for use, because the methods need to be visible outside the package to other subpackages of my library, but they are not supposed to be public to users of the library. Java does not have fine enough visibility controls to allow this out of the box.)

[lukehutch]

Also, @lvc, are you really opening a bug in every single Java and Scala project on GitHub to share these results?

[johnou]

@lukehutch most likely automated (at least to some degree), I have seen similar things like automatically opening pull requests based on squid violations... https://github.com/m-ezzat?tab=overview&from=2016-01-01&to=2016-01-31&utf8=%E2%9C%93 :)

[lukehutch]

@johnou oh, for sure this is automated, and it's shameless promotion, I just want them to respond so I can get them to admit that that's what it is, and so that they address the shortcoming that is in their product (born out of a Java shortcoming) that they assume every public method is part of the public API.

[lvc]

Hi,

Is there an appropriate way to have only the public API checked for API changes?

There is a way to specify packages that should be checked or skipped by a regexp pattern (like org\.X\.(Y|Z).*). Also there is a way to filter annotated classes and methods (like @PublicAPI).

are you really opening a bug in every single Java and Scala project on GitHub to share these results

No. Only for most important ones. Not automated. And this is not a "product" since it's a free and open-source project.

Opened issues allows to get a review from developers of a library and discuss how to properly filter symbols, what modules should be included to the tracker and other things before sharing reports to the community.

Thank you.

--
Andrey

[lvc]

Sorry for disturbing you. Please just skip and close the issue if you are not interested.

Thank you.

--
Andrey

[lukehutch]

@lvc that's OK, you're not disturbing me, this is actually a super useful project you have put together. To be honest though, it is just a bit spammy to file bugs in github as a way of announcing your project, since you are neither reporting a bug nor filing a feature request. I recommend for other projects, first trying to find a mailing list for the project and posting there. You still reach the same audience, but through a more appropriate communication channel. Nevertheless, I'm glad to know this project exists.

API compatibility checks are of limited use to me right now, unfortunately, because annotations like @PublicAPI, @PublicApi, @API, @Api etc. are not standard, and due to the subpackage structure of my project, I have to make some things public that are not part of the API. I wish Java had an "export" keyword, that would solve the problem.