Booleano vs booleano en Java

Boolean envuelve el tipo primitivo booleano. En JDK 5 y superiores, Oracle (o Sun antes de que Oracle los comprara) introdujo autoboxing / unboxing , que esencialmente le permite hacer esto

boolean result = Boolean.TRUE;

O

Boolean result = true; 

Que esencialmente el compilador hace,

Boolean result = Boolean.valueOf(true);

Así que, para su respuesta, es SÍ.

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 grande detrás de la escena de creando los lenguajes de programación , en general, es decir, cuando cosas como la seguridad de tipo vs. consideraciones de memoria hacen la diferencia):

Int no es booleano

Considere

    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

Código Java en 3ra línea (bar)?1:0 ilustra que barra (booleano ) no puede ser convertido implícitamente (fundido) en un int. Lo menciono 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 utiliza realmente/completamente como en los tipos booleanos donde los controles se realizan en forma de

Si el valor \in {0,1} entonces tipo booleano, de lo contrario lanzar una excepción.

Todo solo para decir que {0,1}

Los bytes no son tipos o bits

Tenga en cuenta que en la memoria su variable de rango de {0,1} seguirá ocupando al menos un byte o una palabra (xbits dependiendo del tamaño del registro) a menos que especialmente cuidado (por ejemplo, embalado muy bien en memoria - 8 bits "booleanos" en 1 byte-hacia adelante y hacia atrás).

Al preferir la seguridad de tipo (como poner/envolver el valor en una caja de un tipo particular) sobre el embalaje de valor adicional (por ejemplo, usando desplazamientos de bits o aritmética), uno efectivamente 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 no vale más que booleano).

Palabras Clave vs tipo

Finalmente, tu pregunta es acerca de comparar palabra clave vs. tipo. Creo que es importante explicar por qué o cómo exactamente obtendrá rendimiento usando / prefiriendo palabras clave ("marcado" como primitivo) sobre tipos (clases compuestas normales definibles por el usuario usando otra palabra clave clase ) o en otras palabras

boolean foo = true;

Vs.

Boolean foo = true;

La primera "cosa" (tipo) no se puede extender (subclase) y no sin una razón. Efectivamente Java la terminología de las clases primitive y wrapping se puede traducir simplemente a inline value (un LITERAL o una constante que se sustituye directamente por el compilador siempre que sea posible inferir la sustitución o, si no, aún se puede recurrir a envolver el valor).

La optimización se logra debido a trivial:

"Menos operaciones de casting en tiempo de ejecución => más velocidad."

Es por eso que cuando se realiza la inferencia de tipo real, puede (still) terminar en instanciación de la clase wrapping con toda la información de tipo si es necesario (o convertir/fundir en tal).

Entonces, la diferencia entre booleany Booleanestá exactamente en Compilationy Runtime (un poco lejos, pero casi como instanceofvs. getClass()).

Finalmente, autoboxing es más lento que primitivos

Tenga en cuenta el hecho de que Java puede hacer autoboxing es solo un "syntactic sugar" (en inglés). No acelera nada, solo te permite escribir menos código. Eso es. Aún se realiza la colada y envoltura en el contenedor de información de tipo. Por razones de rendimiento, elija aritmética que siempre omitirá la administración adicional de la creación de instancias de clase con información de tipo para implementar la seguridad de tipo. La falta de tipo de seguridad es el precio que pagas para ganar rendimiento. Para código con expresiones con valor booleano escriba safety (cuando escribe menos y por lo tanto código implícito) sería crítico, por ejemplo, para los controles de flujo if-then-else.

Puede usar las constantes booleanas - Boolean.TRUE y Boolean.FALSE en lugar de 0 y 1. Puede crear su variable como de tipo boolean si lo que busca es primitivo. De esta manera no tendrá que crear nuevos objetos Boolean.

Básicamente, los booleanos representan un tipo de datos primitivo donde los booleanos representan un tipo de datos de referencia. esta historia se inicia cuando Java quiere llegar a ser puramente orientada a objetos que se proporciona concepto de clase de envoltura para llegar a utilizar el tipo de datos primitivo.

boolean b1;
Boolean b2;

b1 y b2 no son lo mismo.