UnmodifiableMap(Colecciones Java) vs ImmutableMap(Google)

collections guava

Question

Esta pregunta ya tiene una respuesta aquí:

• Colección inmutable vs no modificable 6 respuestas

Contexto

Necesito devolver una referencia a un mapa que estoy usando para un caché de datos, y me gustaría asegurarme de que nadie pueda modificar su referencia.

Pregunta

He visto muchas referencias a UnmodifiableMap e ImmutableMap en línea, pero no veo nada que las compare o las contraste. Me imagino que hay una buena razón por la que Google / Guava creó su propia versión. ¿Puede alguien decirme qué es?

Answer 1

Eche un vistazo a ImmutableMap JavaDoc: doc

Hay información sobre eso allí:

A diferencia de Collections.unmodifiableMap (java.util.Map), que es una vista de un mapa separado que aún puede cambiar, una instancia de ImmutableMap contiene sus propios datos y nunca cambiará. ImmutableMap es conveniente para los mapas finales estáticos públicos ("mapas constantes") y también le permite hacer fácilmente una "copia defensiva" de un mapa proporcionado a su clase por un llamador.

Answer 2

ImmutableMap no acepta valores null mientras que Collections.unmodifiableMap() sí lo hace. Además, nunca cambiará después de la construcción, mientras que UnmodifiableMap lo hará. Desde JavaDoc:

Un mapa inmutable basado en hash con un orden de iteración confiable especificado por el usuario. No permite claves nulas o valores.

A diferencia de Collections.unmodifiableMap (java.util.Map), que es una vista de un mapa separado que aún puede cambiar, una instancia de ImmutableMap contiene sus propios datos y nunca cambiará. ImmutableMap es conveniente para los mapas finales estáticos públicos ("mapas constantes") y también le permite hacer fácilmente una "copia defensiva" de un mapa proporcionado a su clase por un llamador.

Answer 3

Un mapa no modificable aún puede cambiar. Es solo una vista en un mapa modificable, y los cambios en el mapa de respaldo serán visibles a través del mapa no modificable. El mapa no modificable solo evita modificaciones para aquellos que solo tienen la referencia a la vista no modificable:

Map<String, String> realMap = new HashMap<String, String>();
realMap.put("A", "B");
Map<String, String> unmodifiableMap = Collections.unmodifiableMap(realMap);
// This is not possible: It would throw an
// UnsupportedOperationException
//unmodifiableMap.put("C", "D");
// This is still possible:
realMap.put("E", "F");
// The change in the "realMap" is now also visible
// in the "unmodifiableMap". So the unmodifiableMap
// has changed after it has been created.
unmodifiableMap.get("E"); // Will return "F".

En contraste con eso, el ImmutableMap of Guava es realmente inmutable : es una copia fiel de un mapa dado, y nadie puede modificar este ImmutableMap de ninguna manera.

Actualización :

Como se señala en un comment , también se puede crear un mapa inmutable con la API estándar usando

Map<String, String> immutableMap =
Collections.unmodifiableMap(new LinkedHashMap<String, String>(realMap));

Esto creará una vista inmodificable en una copia verdadera del mapa dado, y así emula muy bien las características de ImmutableMap sin tener que agregar la dependencia a Guava.

Answer 4

Documentación Guava

El JDK proporciona métodos Collections.unmodifiableXXX , pero en nuestra opinión, estos pueden ser difíciles de manejar y prolijos; desagradable de usar donde quiera que quiera hacer copias defensivas inseguras: las colecciones devueltas son realmente inmutables si nadie tiene una referencia ineficiente a la colección original: las estructuras de datos aún tienen toda la sobrecarga de colecciones mutables, incluyendo verificaciones de modificación concurrentes, espacio adicional en tablas hash, etc.