Spring Avoid wasted memory on empty maps and sets

Empty LinkedHashMaps waste quite a lot of memory (250kb) for a medium size project

The PR introduces a simple fix

A screen from yourkit profiler:

Comment From: jhoeller

Any specific reason to use Set/Map.of() over Collections.emptySet/Map()? The latter seems even more efficient implementation-wise.

Comment From: Dunemaster

Any specific reason to use Set/Map.of() over Collections.emptySet/Map()? The latter seems even more efficient implementation-wise.

Would you be so kind to explain the difference? Both methods return a static instance of an empty map/set.

I used Set/Map.of() for the sake of brevity, and do not see any performance benefit in using either Set/Map.of() or Collections.emptySet/Map()

Comment From: vlsi

The difference between Map.of and Collections.emptyMap is that Map.of().contains(null) would throw exception while Collections.emptyMap().contains(null) would return false.

See https://stackoverflow.com/a/46406203/1261287

Comment From: Dunemaster

The difference between Map.of and Collections.emptyMap is that Map.of().contains(null) would throw exception while Collections.emptyMap().contains(null) would return false.

See https://stackoverflow.com/a/46406203/1261287

wow, thanks. I will change to Collections.emptyMap, if you think that is better

Comment From: jhoeller

Aside from the contains(null) benefit, the footprint of Collections.emptySet/Map() should also be slightly better since those implementations are actually designed for emptiness (not just initialized without any elements as with Set/Map.of()).

Comment From: vlsi

Can you elaborate?

AFAIK Map.of returns a static instance that is optimised for empty case: https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/java/util/Map.java#L1333

Comment From: Dunemaster

Replaced Set.of() and Map.of with Collections.emptyXXX in order to avoid possible compatibility breaks

Comment From: sbrannen

This has been merged into main in 3738a45658426d7caa976021f01f94c125d9e4ef and revised in d5fb5d029bdc32fa00fa45660d07438a41b57206.

Thanks

Comment From: Dunemaster

Should this change be ported to 5.3?

Comment From: sbrannen

Should this change be ported to 5.3?

We do not intend to backport minor enhancements such as this to 5.3.x.