Skip to content

Y20240131-0220

Y20240131-0220: API tooling reports 300 false positive errors on SWT
@iloveeclipse iloveeclipse tagged this 30 Jan 21:13 
Before the change ApiBaseline.resolveSystemLibrary() did following:
1) Collected all JVM installs matching all given execution environments
id's
2) Iterated over all found installs **in random order**
3) For every JVM install ApiBaseline tried to initialize itself from
that install
4) The condition used to stop the loop (almost) never worked as it
always compared either null or previously initialized JVM with the
current one, so for all **different** JVM's ApiBaseline  initialized
itself from that JVM - and that in random order.
5) The **last** iterated JVM install defined the maximal "supported"
execution environment. In case of installed Java 1.8, 11, 17, 21 it
could be **any one** if the target platform contained bundles required
different execution environments.

With that, SWT bundle (that requires 17 environment) from saved API
baseline was not resolved with given baseline if any of lower
environments "won the race" in resolveSystemLibrary().

Because SWT bundle was not resolved, none of SWT classes were found in
the baseline and so not considered "API" in
ApiComparator.internalCompare(). Because there were no API classes in
the baseline, ALL public API types from workspace SWT project were
considered as new API and "missing @since tags" errors were created.

With the change ApiBaseline.resolveSystemLibrary() does following:
1) Collects all JVM installs matching all given execution environments
id's
2) Sorts them by their Java version, with highest version first
3) Iterates over all found installs **in descending order**
4) The first (highest Java version) matching JVM install will be used to
initialize ApiBaseline
5) The loop continues only if the API baseline fails to initialize from
given JVM

With that, the **highest supported** JVM install that is required by
given execution environments defines the maximal "supported" execution
environment for the baseline.

Additional changes:

1) ApiBaselineManager.readBaselineComponents() will sort bundles to get
more stable behavior of the API tooling.
2) ApiBaseline.rebindVM() will use same ApiBaselineManagerRule that is
used by ApiBaselineManager to dispose baselines. This will prevent that
API analysis jobs may run in parallel with JVM re-initialization of the
baseline or baseline JVM update will interfere with baseline disposal.

Fixes https://github.com/eclipse-pde/eclipse.pde/issues/1073
Assets 2
Loading