¿Por qué la gente todavía usa tipos primitivos en Java?
Desde Java 5, hemos boxeado/unboxing de tipos primitivos para que intse envuelvan para ser java.lang.Integer, y así sucesivamente.
Últimamente veo muchos proyectos Java nuevos (que definitivamente requieren un JRE de al menos la versión 5, si no 6) que usan inten lugar de java.lang.Integer, aunque es mucho más conveniente usar este último, ya que tiene algunos métodos auxiliares para convertir. a longvalores et al.
¿ Por qué algunos todavía usan tipos primitivos en Java? ¿Hay algún beneficio tangible?
En Effective Java de Joshua Bloch , punto 5: "Evitar la creación de objetos innecesarios", publica el siguiente ejemplo de código:
public static void main(String[] args) {
Long sum = 0L; // uses Long, not long
for (long i = 0; i <= Integer.MAX_VALUE; i++) {
sum += i;
}
System.out.println(sum);
}
y tarda 43 segundos en ejecutarse. Al incorporar el Long a la primitiva, se reduce a 6,8 segundos... Si eso es una indicación de por qué usamos primitivas.
La falta de igualdad de valores nativos también es una preocupación ( .equals()es bastante detallada en comparación con ==)
para biziclop:
class Biziclop {
public static void main(String[] args) {
System.out.println(new Integer(5) == new Integer(5));
System.out.println(new Integer(500) == new Integer(500));
System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
}
}
Resultados en:
false
false
true
false
EDITAR ¿Por qué (3) regresa truey (4) regresa false?
Porque son dos objetos diferentes. Los 256 números enteros más cercanos a cero [-128; 127] son almacenados en caché por la JVM, por lo que devuelven el mismo objeto para ellos. Sin embargo, más allá de ese rango, no se almacenan en caché, por lo que se crea un nuevo objeto. Para complicar más las cosas, el JLS exige que se almacenen en caché al menos 256 pesos mosca. Los implementadores de JVM pueden agregar más si lo desean, lo que significa que esto podría ejecutarse en un sistema donde los 1024 más cercanos están almacenados en caché y todos devuelven verdadero... #awkward
El autounboxing puede generar NPE difíciles de detectar
Integer in = null;
...
...
int i = in; // NPE at runtime
En la mayoría de las situaciones, la asignación nula a ines mucho menos obvia que la anterior.
Los tipos en caja tienen un rendimiento inferior y requieren más memoria.
