¿Por qué SparseIntArray no implementa Map <Integer, Integer>?

JavaDoc para SparseIntArray también dice

SparseIntArrays mapea enteros a enteros. A diferencia de una matriz normal de enteros, puede haber vacíos en los índices. Se pretende que sea más eficiente en la memoria que usar un HashMap para asignar números enteros a enteros , ya que evita las claves y los valores de autococking y su estructura de datos no se basa en un objeto de entrada adicional para cada correlación.

Podemos derivar las siguientes razones para la elección de SparseIntArray sobre Map <Integer, Integer>:

• Dado que queríamos tener mapping entre primitivas, sería bueno evitar el autoboxing.
• En Map, tener un objeto como clave / valor viene con pesadez de cálculo de hash, resolución de colisión de hash, vinculación de múltiples entradas en un solo cubo, etc. Esto no será necesario ya que estamos tratando con pares clave / valor primitivos. Tenga en cuenta que SparseIntArray viene con advertencia de rendimiento. Dado que los valores se almacenan en la estructura de datos binarios de la matriz de árbol de búsqueda, las inserciones y eliminaciones serán operaciones costosas. Por lo tanto, su una buena opción para el pequeño conjunto de datos.

Como un punto secundario, yo diría que JavaDoc debería ser más específico diciendo

"SparseIntArrays mapea enteros primitivos a enteros."

En lugar de decir

"SparseIntArrays mapea enteros a enteros."

• Implementar Map es muy pesado. Necesita métodos como entrySet y keySet que no es conveniente en SparseIntArray .

• Las claves de mapa son Objetos, por lo que se necesita un encajonamiento / descompresión constante.

• SparseIntArray sugiere una forma diferente de enumerar a través de un Map , utilizando su keyAt específico y valueAt , que son muy rápidos.

Si SparseIntArray implementó Map<Integer, Integer> se sentiría tentado a escribir:

 Map<Integer, Integer> intMap = new SparseIntArray(); 

Pero entonces usted estaría atascado con sólo qué capacidad de enumeración Map proporciona.

Si implementó Map<Integer,Integer> , tendría que tratar con objetos Integer como valores de entrada y salida en lugar de valores int primitivos, de modo que se perdería el punto completo de esta clase que es evitar el boxeo.