On Tue, 12 May 2026 13:00:07 GMT, Per Minborg <[email protected]> wrote:
> This PR proposes to replace older `Collection.unmodifiable` wrappers with > `Set.of()` instead. This can improve performance, reduce footprint, and > reduce maintenance. There is also occasional use of `Map.of()` in nearby > places where `Set.of()` was introduced. > > The PR also contains two optimizations in `PlatformMBeanProviderImpl` that > remove `synchronized` from two methods. > > --------- > - [X] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). General comments. `Set.of()` is not drop-in replacement for `C.unmodSet(hashSet)`. There are several behavioral differences, some of which have been noted previously. * A set from Set.of() will throw on `contains(null)` but an unmodifiable wrapper around a HashSet will return normally. * Set.of() will throw if any arguments are duplicates, whereas adding duplicates to a HashSet will deduplicate them. Prefer Set.copyOf() in such cases. * Set.of() encounter order is randomized; encounter order of a HashSet is unspecified but predictable. * Set.of() is serialization-incompatible with an unmod-wrapped HashSet. * Set.of() is strictly unmodifiable whereas C.singleton() is not. That is, Set.of("x").remove("y") will throw UOE, but Collections.singleton("x").remove("y") will return false. There are some space and performance considerations. Set.of() is generally slower than HashSet. However, Set.of() can consume significantly less space than the alternative. For example, with two elements, Set.of() is a single object with two fields. A two-element unmod-wrapped HashSet requires six objects: the wrapper, the HashSet, the HashMap, the table, and a Node for each element. However, a Set.of() with single element doesn't offer any space advantage over Collections.singleton(). This is not to say that this kind of cleanup shouldn't proceed, but instead that each case requires a fair bit of analysis. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31135#issuecomment-4456531265
