Autoboxing parece reducirse al hecho de que yo pueda escribir:Autoboxing: entonces puedo escribir: Integer i = 0; en lugar de: Integer i = new Integer (0);
Integer i = 0;
en lugar de:
Integer i = new Integer(0);
Por lo tanto, el compilador puede convertir automáticamente una primitiva a un objeto.
¿Es esa la idea? ¿Porque es esto importante?
Lo simplificaste un poco demasiado.
Autoboxing también entra en juego cuando se usan colecciones. Como se explica en la documentación de Java de Sun:
Colecciones sólo pueden contener referencias a objetos, por lo que tiene a la caja de valores primitivos en la clase de contenedor apropiado. ... Cuando saca el objeto de la colección, obtiene el número entero que ingresa; si necesita un int, debe desagrupar el entero utilizando el método intValue. Todo este boxeo y unboxing es un dolor, y desordena su código. La característica de autoboxing y unboxing automatiza el proceso, eliminando el dolor y el desorden.
Entonces, ¿cuándo debería usar el autoboxing y el desempaquetado? Úselos solo cuando haya una "falta de coincidencia de impedancia" entre los tipos de referencia y las primitivas, por ejemplo, cuando tenga que poner valores numéricos en una colección. No es apropiado usar autoboxing y unboxing para computación científica u otro código numérico sensible al rendimiento. Un entero no es un sustituto de un int; el autoboxing y unboxing borran la distinción entre tipos primitivos y tipos de referencia, pero no lo eliminan.
Hace que el código sea más legible y ordenado. Especialmente si está realizando operaciones (ya que Java no tiene sobrecarga del operador).
Con mi sombrero cínica en: a maquillaje para limitaciones en el original de Java (me refiero aquí roble) las especificaciones. No solo la primera vez.
Esa es la idea, sí. Sin embargo, es aún más conveniente poder asignar un entero a un int.
Se podría argumentar que el autoboxing aborda un síntoma en lugar de una causa. La verdadera fuente de confusión es que el sistema de tipos de Java es inconsistente: la necesidad de primitivas y referencias de objetos es artificial e incómoda. Autoboxing lo mitiga un tanto.
¿Qué tiene de incómodo tener primitivos? ¿Quiere decir que desvirtúa la naturaleza puramente orientada a objetos del lenguaje? En Ruby, por ejemplo, incluso los enteros son objetos. ¿Es eso lo que quieres decir? –
Realmente no veo por qué es tan importante. Creo que deberían haberse ido lo suficientemente bien solos. Esto no parece agregar mucho, por lo que puedo decir hasta ahora. Por supuesto, acabo de enterarme de esta característica hace aproximadamente cinco minutos. –
Sí, eso es lo que quiero decir. No soy un purista de OO de ninguna manera, pero no es obvio por qué un programador se beneficia de tener a la vez un int y un entero. Creo que una abstracción debería ser suficiente para cubrir el "número entero". – jcrossley3
Por lo que recuerdo al leer el Java Efectivo de Joshua Bloch, debes considerar los primitivos sobre sus contrapartidas encuadradas. Autoboxing sin tener en cuenta sus efectos secundarios puede producir problemas.
¿Qué quieres decir? –
Porque las primitivas siempre se copian cuando se pasan. No creo que esto sea cierto de sus contrapartes en caja. – CookieOfFortune
Añadiendo al comentario de Lim, las primitivas se almacenan en la pila, y las envolturas primitivas, como objetos, se almacenan en el montón ... Esto tiene sutiles implicaciones.
La principal ventaja sería la legibilidad, azúcar sintáctica básicamente. Java ya es muy detallado, Sun está intentando todo tipo de formas para acortar la sintaxis.
Por cierto
Integer i = 0;
es equivalente a
Integer i = Integer.valueOf(0);
La distinción es que valueOf() no crea un nuevo objeto para valores comprendidos entre -128 y 127 (Al parecer este será sintonizable si Java 6u14)
¡Gracias! Estaba muy confundido por qué solo a veces se creaba un objeto nuevo. – DustByte
@DustByte porque solo puede almacenar en caché los objetos comunes. El almacenamiento en caché de cada entero utilizaría 40 GB de memoria (solo para enteros) –
existe por lo que se puede escribir código como
List<Integer> is = new ArrayList<Integer>();
is.add(1); // auto-boxing
is.add(2);
is.add(3);
int sum = 0;
for (int i : is) // auto-unboxing
{
sum += i;
}
Para enteros enteros, debe usar de forma predeterminada el tipo int, no Integer. Integer es principalmente para uso en colecciones.
Tenga en cuenta que un Largo es diferente del mismo valor que un Entero (usando iguales()), pero como un largo es igual a un int (usando ==).
¿Qué limitaciones? –
¿Por dónde empezar? La API de fecha y hora, la falta de una API de colecciones desde el principio, las matrices como objetos "ligeros" y no reemplazan a Object.equals(), la falta de genéricos desde el principio, el mecanismo de clonación "extraño" ... Con el tiempo encuentre sutiles crujidos en el lenguaje, o lea sobre ellos y cómo fueron parcheados. Al final del día, Java fue un lenguaje incrustado revivido para el boom de las puntocom, y se nota. Prefiero C#, a pesar de ser de Microsoft. –