API Tools: Package Exports from JARs on Local ClassPath Still Seem to Be Analysed After Bumping Major Version of Bundle

[ingomohr]

Scenario

GIVEN a bundle with a number of JARs on the local classpath
AND there are packages from the JARs that are exported by the bundle (via MANIFEST.MF)
WHEN I raise the major version of the bundle
THEN...

• expected: the exported packages are no longer scanned (because the new major version allows any change anyway)
• actual: all the exported packages are still scanned

[HannesWell]

In general the API tools do more than just checking API-breakages and the required version increment for an API change, for example check if classes from other plug-ins are referenced that are marked with @noreference etc.
But since jars are already compiled and cannot change there is nothing that can be done.
Or @merks or @laeubi can you think of anything that needs to be checked in a jar if the major version is already incremented?

• actual: all the exported packages are still scanned

@ingomohr do you report this for performance reasons or did you encounter problems? If there is nothing else to check such optimization could be applied. If nothing speaks against it, would you be interested in providing a corresponding change?

[laeubi]

Its unclear to me what "all the exported packages are still scanned" should mean, even if the major version is incremented they need to be analyzed somehow otherwise one can't tell for example if the major bump is required at all...

[ingomohr]

@ingomohr do you report this for performance reasons or did you encounter problems?

Hi @HannesWell - Thank you for getting back to me! I reported this because of performance problems, yes. I had to work on a plugin project that had 1500 exported packages that all needed to go. So I raised the major version and wondered why the API tooling still required approximately half a minute to scan that former API. I worked around this by removing builder and nature from the project and - after the release - added them again.

If there is nothing else to check such optimization could be applied. If nothing speaks against it, would you be interested in providing a corresponding change?

From @laeubi 's answer (thank you for that, @laeubi) I think I can't decide how the change should look like. I was not aware that the API tooling also has the job of telling whether a major version raise is actually chosen correctly (but that makes sense)...