Estoy extendiendo un poco las respuestas proporcionadas (ya que hasta ahora se concentran en su terminología "propia" / artificial centrándose en la programación de un lenguaje en particular en lugar de ocuparse de la imagen más amplia detrás de la escena de la creación de los lenguajes de programación , en general, es decir, cuando las cosas como las consideraciones de seguridad de tipo versus memoria hacen la diferencia):
int no es booleano
Considerar
boolean bar = true;
System.out.printf("Bar is %b\n", bar);
System.out.printf("Bar is %d\n", (bar)?1:0);
int baz = 1;
System.out.printf("Baz is %d\n", baz);
System.out.printf("Baz is %b\n", baz);
con salida
Bar is true
Bar is 1
Baz is 1
Baz is true
El código Java en la tercera línea (bar)?1:0ilustra que la barra ( booleana ) no se puede convertir (convertir) implícitamente en un int . Menciono esto no para ilustrar los detalles de la implementación detrás de JVM, sino para señalar que, en términos de consideraciones de bajo nivel (como el tamaño de la memoria), uno tiene que preferir los valores sobre la seguridad de tipo. Especialmente si ese tipo de seguridad no se usa verdadera / totalmente como en los tipos booleanos donde los controles se realizan en forma de
si el valor \ en {0,1} se convierte al tipo booleano, de lo contrario arroje una excepción.
Todo para indicar que {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}. Parece una exageración, ¿verdad? La seguridad de tipo es realmente importante en los tipos definidos por el usuario, no en la conversión implícita de primitivas (aunque las últimas se incluyen en la primera).
Los bytes no son tipos o bits
Tenga en cuenta que en la memoria su variable del rango de {0,1} seguirá ocupando al menos un byte o una palabra (xbits dependiendo del tamaño del registro) a menos que esté especialmente cuidado (por ejemplo, bien guardado en la memoria - 8 "booleano" bits en 1 byte - adelante y atrás).
Al preferir la seguridad de tipo (como poner / envolver el valor en una caja de un tipo particular) sobre el empaquetado de valor adicional (por ejemplo, usar cambios de bits o aritmética), se elige escribir menos código en lugar de ganar más memoria. (Por otro lado, siempre se puede definir un tipo de usuario personalizado que facilitará toda la conversión que no valga más que booleana).
palabra clave versus tipo
Finalmente, su pregunta es sobre la comparación de palabras clave versus tipo . Creo que es importante explicar por qué o cómo exactamente obtendrá rendimiento al usar / preferir palabras clave ("marcadas" como primitivas ) sobre los tipos (clases compuestas definibles por el usuario normales que usan otra clase de palabras clave ) o en otras palabras
boolean foo = true;
vs.
Boolean foo = true;
La primera "cosa" (tipo) no se puede extender (subclasificar) y no sin una razón. Efectivamente, la terminología de Java de las clases primitivas y envolventes se puede traducir simplemente en un valor en línea (un LITERAL o una constante que se sustituye directamente por el compilador cada vez que es posible inferir la sustitución o, de lo contrario, recurrir al ajuste del valor).
La optimización se logra debido a trivial:
"Menos operaciones de lanzamiento de tiempo de ejecución => más velocidad".
Es por eso que cuando se realiza la inferencia de tipo real, puede (todavía) terminar instanciando la clase de ajuste con toda la información de tipo si es necesario (o convertir / convertir en tal).
Entonces, la diferencia entre boolean y Boolean está exactamente en Compilation y Runtime (un poco lejos pero casi como una instancia de vs. getClass () ).
Finalmente, el autoboxing es más lento que los primitivos.
Tenga en cuenta que Java puede hacer autoboxing es solo un "azúcar sintáctico". No acelera nada, solo le permite escribir menos código. Eso es. Aún se realiza la conversión y el ajuste en el contenedor de información de tipo. Por razones de rendimiento, elija la aritmética, que siempre omitirá la limpieza adicional al crear instancias de clase con información de tipo para implementar la seguridad de tipo. La falta de seguridad de tipo es el precio que paga para obtener rendimiento. Para el código con expresiones de valor booleano, la seguridad de tipo (cuando escribe menos y, por lo tanto, código implícito ) sería crítica, por ejemplo, para los controles de flujo if-then-else.