Skip to content

Remove commons-collection4 from the project#7561

Merged
karianna merged 6 commits into
PCGen:masterfrom
Vest:optimize-deps
May 19, 2026
Merged

Remove commons-collection4 from the project#7561
karianna merged 6 commits into
PCGen:masterfrom
Vest:optimize-deps

Conversation

@Vest

@Vest Vest commented May 18, 2026

Copy link
Copy Markdown
Contributor

I have gone through multiple dependencies, and this particular dependency is not heavily used within the project. Using a modern Java JDK and existing API, I was able to eliminate some checks and make the code shorter + as I mentioned, I have removed commons-collection4.

ps. please apply this PR after #7560.

Vest added 6 commits May 18, 2026 12:20
Two call sites used CollectionUtils.emptyIfNull() to guard against null
collections before streaming. Both are replaced with explicit null checks:

- VariableChannel.checkForVeto(): a stream-then-findAny-isPresent chain
  collapses to a single anyMatch() with a null guard.
- VisionDisplay.getVision(): early return on null preserves the same
  empty-string output without constructing an empty collection.

Step 1 of removing the commons-collections4 dependency.
The single call site converted an Iterator into a List via
IteratorUtils.toList(). Replaced with StreamSupport.stream() over a
Spliterator wrapper of the Iterator and Stream.toList(), which is the
idiomatic JDK pattern for the same conversion.

Step 2 of removing the commons-collections4 dependency.
Four call sites in CDOMObjectUtilities used ListUtils.emptyIfNull() to
guard a forEach against null. Replaced with explicit null checks: skip
the iteration if the list is null, otherwise call forEach directly.

This was the last remaining commons-collections4 import after the prior
two commits removed CollectionUtils and IteratorUtils, so this change
also drops the dependency from build.gradle and the requires clause
from module-info.java.

Step 3 of removing the commons-collections4 dependency. Saves ~880 KB
from the runtime classpath.
BiPredicate<T, T> is the specialized functional interface for boolean-returning two-argument functions, so call sites use .test() rather than .apply() and Sonar's "use the most specialized functional interface" warning goes away. Also tighten getVariableID() to return VariableID<T> instead of VariableID<?>.

The veto API itself (VetoableReferenceFacade, addVetoToChannel) has no in-tree callers and PR PCGen#5577 (2019) proposed removing it. The original author (thpr) pushed back, asking that cdom/formula code not be changed without discussion since "it is rarely unused completely" — third-party plugins may rely on it. Keeping the API; only modernizing the signature.

Signed-off-by: Vest <Vest@users.noreply.github.com>
…line UI logic

Fix SonarLint errors/warnings.

Signed-off-by: Vest <Vest@users.noreply.github.com>
…stFor

Signed-off-by: Vest <Vest@users.noreply.github.com>
@Vest

Vest commented May 18, 2026

Copy link
Copy Markdown
Contributor Author

you can squash the changes.

@karianna karianna merged commit 71423dc into PCGen:master May 19, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants