I think these results are highly misleading. The codebase the analysis is run on is a server codebase which has only a very small amount of publicly facing APIs. Those are mainly Client APIs which make a very small percentage of the codebase. Our primary API is rest and with the added REST client and the upcoming removal of the transport client we will further reduce the public API facing footprint. I am not sure that there is any takeaways from this rather than we are having major changes in major releases and almost non changes in bugfix releases.
Like Simon said, I think this is more useful for people working on Elasticsearch then it is for folks working with Elasticsearch because I think it includes all the internal APIs.
I think it'd be useful for Java users if we had a jar for the high level REST client rather than depending on Elasticsearch core and we generated the report for that jar. And we do want to do that, we just haven't got to it because it is a lot of work to decouple all the things.
It'd also be the useful if we had a plugin API jar. We don't and that is even further away from happening. At this point we don't consider any of the plugin interfaces set in stone though. So I expect them to change in minor releases. At least for a while. I've been saying for a few years now that a real, semvered plugin API is at least two years away. It still is, I think.
I think it'd be useful to point it at the low level rest client right now but that is about the only part of Elasticsearch that'd give reasonable results.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.