deps: EOL replace commons-collections 3.2.2 with commons-collections4 4.5.0 (closes 2 CVEs)

[natechadwick-intsof]

Summary

Replace commons-collections:commons-collections:3.2.2 (EOL since 2015) with org.apache.commons:commons-collections4:4.5.0 project-wide. commons-collections4:4.5.0 is already in the root pom's dependencyManagement (line 556-559) — only the 3.x line was in active use, so no new dep is added.

The 3.x line has been EOL since 2015 and has 2 CVEs in the analysis report. The 4.x line is the maintained successor with the same API surface (most class names are identical; the package is just collections4 instead of collections).

What changes

Bulk: package rename across the codebase

A mechanical s|org\.apache\.commons\.collections\.|org.apache.commons.collections4.|g over all .java files. Total: 71 files (per grep -rln of org.apache.commons.collections.).

This is a much smaller migration than #85 (commons-lang 2.x → 3.x was 1,396 files). Most files only change the import line(s); the API calls themselves don't change because the class names (CollectionUtils, MapUtils, ListUtils, MapIterator, Predicate, Transformer, etc.) are identical between the two lines.

Special case: MultiHashMap removed in 4.x (3 files)

In commons-collections 3.x, org.apache.commons.collections.MultiHashMap was a deprecated convenience class. It was removed in 4.x. The replacements are:

• org.apache.commons.collections4.multimap.ArrayListValuedHashMap<K, V> — when you need a list-valued map (multi-put returns a list)
• org.apache.commons.collections4.multimap.HashSetValuedHashMap<K, V> — when you need a set-valued map (no duplicate values per key)

The 3 call sites all use new MultiHashMap() and immediately add multiple values per key, so the closest behavior is ArrayListValuedHashMap. The API is slightly different — instead of mhm.put(key, value1); mhm.put(key, value2); you'd use mvm.put(key, value1); mvm.put(key, value2);, but MultiValuedMap.put(K, V) always returns the collection of values for that key, which is the same as the legacy MultiHashMap.put(K, V) returns. So the migration is a class rename + import change, with no call-site code changes.

Files affected:

• system/services/src/com/percussion/services/contentmgr/impl/legacy/PSContentRepository.java
• system/services/src/com/percussion/services/utils/jspel/PSItemUtilities.java
• modules/extensions-sfp/src/main/java/com/percussion/fastforward/calendar/PSCalendarMonthModel.java

Pom changes

• pom.xml: remove the <dependency>commons-collections:commons-collections:3.2.2</dependency> block (line 561-564)
• <commons.collections3.version>3.2.2</commons.collections3.version>: delete the property (no other consumer — verified)
• <commons.collections4.version>4.5.0</commons.collections4.version>: keep as-is (the 4.x version is already declared in dependencyManagement at line 556-559)

Risk

• Mechanical risk: the sed rename is mostly safe but may surface subtle API differences. The ./mvn-env.sh clean install -DskipTests build will catch any cannot find symbol errors at compile time.
• Behavioral risk: commons-collections4 ships some deprecation shims (e.g. Predicate.evaluate(T) is deprecated but still works) and a few new methods (e.g. MultiValuedMap.putAll(K, Iterable<V>)). The CollectionUtils / MapUtils / ListUtils API is unchanged for the methods this project uses.
• Test risk: 71 files, mostly small utility usages. Unit-test smoke run after the build is recommended (not run in this environment).

Verification

• ./mvn-env.sh clean install -DskipTests succeeds on Java 1.8
• ./mvn-env.sh spotless:check passes
• ./mvn-env.sh dependency:tree -Dincludes=commons-collections:commons-collections returns empty (the 3.x dep is gone)
• ./mvn-env.sh dependency:tree -Dincludes=org.apache.commons:commons-collections4 returns the 4.5.0 entry
• No UnsupportedClassVersionError in the build log (the 4.x library is Java 8 compatible)
• A grep for the old coordinate is empty: grep -rln 'org\.apache\.commons\.collections\.[A-Z]' --include='*.java' should return no files in the project source tree (allow target/ and .worktrees/)

Out of scope (separate issues under #73)

• commons-beanutils 1.11.0 -> beanutils2 EOL replacement (more complex; Jakarta migration)
• commons-httpclient 3.1 -> HttpClient 5 EOL replacement (the project already has HttpClient 5 from chore(deps): tier1 dependency upgrades for Java 1.8 (issue #72, 13 of 19 GAVs) #79; just remove the 3.1 dep)
• commons-configuration 1.10 -> commons-configuration2 EOL replacement (API changes; not just a package rename)
• Moving the project to Java 11+ (parent epic [epic] Mitigations for 117 GAVs that cannot be upgraded on Java 1.8 (closes 504 CVEs) #73, separate workstream)

References

• Parent epic: [epic] Mitigations for 117 GAVs that cannot be upgraded on Java 1.8 (closes 504 CVEs) #73
• commons-collections 3.x -> 4.x migration guide: https://commons.apache.org/proper/commons-collections/user-guide.html
• commons-collections4 4.5.0 Javadoc: https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/package-summary.html
• commons-collections 3.2.2 EOL: https://commons.apache.org/proper/commons-collections/

Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.

[natechadwick-intsof]

Fixed by the PR linked below. Bulk package rename across 71 .java files (org.apache.commons.collections.* -> org.apache.commons.collections4.*), removed the 3.2.2 dep from root pom and 13 module poms, and addressed 4 lang4 API differences (MultiHashMap removed, CollectionUtils.addAll(Iterator) removed, getCollection/getList renamed to decorated, MapUtils.getString 2-arg signature changed). Build passes on Java 1.8 in 3:41. Closing as fixed.