guava

Use Java 19 or later and call the standard static factory methods:

HashMap<K, V> map = HashMap.newHashMap(expectedSize);
HashSet<E> set = HashSet.newHashSet(expectedSize);

These replace:

Maps.newHashMapWithExpectedSize(expectedSize);
Sets.newHashSetWithExpectedSize(expectedSize);

The argument is the expected number of entries, unlike new HashMap<>(capacity), which accepts the underlying table capacity. On Java 18 or older, keep using the Guava methods or manually calculate the initial capacity.

This is a Guava bug in versions including 33.5.0-jre. Lists.transform() returns an AbstractList view whose spliterator() does not delegate to the backing list, so it loses the backing spliterator's CONCURRENT characteristic and uses a fail-fast spliterator instead.

The upstream fix overrides spliterator() in TransformingRandomAccessList and TransformingSequentialList to use CollectSpliterators.map(fromList.spliterator(), ...). Upgrade to a Guava release containing the fix for issue #8165 when available.

Until then, stream the original CopyOnWriteArrayList and apply the mapping on the stream:

// Instead of:
Lists.transform(cow, function).stream().forEach(...);

// Use:
cow.stream().map(function).forEach(...);

Alternatively, use Iterables.transform(cow, function), whose traversal delegates to the source iterable, or iterate it with a for-each loop:

for (Integer value : Iterables.transform(cow, function)) {
    // ...
}

CopyOnWriteArrayList iterators and spliterators are weakly consistent, so direct traversal of the source list should not throw ConcurrentModificationException.

Yes. FluentIterable.toSortedList(Comparator) delegates to Ordering.from(comparator).immutableSortedCopy(...), which delegates to ImmutableList.sortedCopyOf(...). Those methods document a stable sort, so elements that compare equal retain their original encounter order. The missing statement on toSortedList was only a Javadoc gap; use a current Guava version where this guarantee is explicitly documented.

Run Maven with install instead of package from the Guava project root, for example:

mvn clean install -DskipTests

The guava-gwt module uses maven-dependency-plugin:unpack-dependencies, which requires reactor dependencies to be installed in the local Maven repository. Running only mvn package triggers MDEP-98. If the earlier modules have already been installed, you can resume with:

mvn install -rf :guava-gwt

Guava 33.7.0-jre declares Multi-Release: true in its manifest but does not contain META-INF/versions/, triggering a bug in old jdk.zipfs versions. The confirmed workaround is to downgrade to Guava 33.6.0-jre.

Maven:

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.6.0-jre</version>
</dependency>

Gradle:

implementation 'com.google.guava:guava:33.6.0-jre'

Verify the older JAR contains the expected multi-release files:

unzip -l guava-33.6.0-jre.jar | grep META-INF/versions

Avoid Guava 33.7.0-jre when compiling with JDK 9.x or JDK 10.0.1 until a fixed Guava release is used.