On Mon, 18 May 2026 13:43:44 GMT, Per Minborg <[email protected]> wrote:
>> src/java.management/share/classes/java/lang/management/DefaultPlatformMBeanProvider.java
>> line 81:
>>
>>> 79: return Map.of(
>>> 80: ManagementFactory.CLASS_LOADING_MXBEAN_NAME,
>>> 81:
>>> ManagementFactoryHelper.getClassLoadingMXBean());
>>
>> In this case and in the two singleton (set) cases above, there's really no
>> advantage of Set.of() over singleton/singletonMap.
>>
>> Oh... there are additional occurrences of singleton/singletonMap below to
>> which this comment also applies.
>
> The unmodifiables are trusted, whereas the singleton*s are not. But maybe
> that is not super relevant here?
Ah, I would guess that you mean "trusted" in the sense of "trusted by the JVM
not to be modified" thus enabling constant-folding optimizations? Hm, yes, good
point. Not sure that makes a difference here. Up to you. There's a tradeoff
with behavioral compatibility though regarding serialization and strict
unmodifiability. As an example of the latter, Collections.singleton isn't
strict:
Collections.singleton("a").removeAll(List.of())
returns false, whereas Set.of("a") throws UOE.
Another point, probably for another time, is to investigate whether
Collections.singletonX could be made trusted.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31135#discussion_r3260749684
