Estou um pouco ampliando as respostas fornecidas (já que até agora elas se concentram em sua terminologia "própria" / artificial, concentrando-se em programar uma linguagem específica, em vez de cuidar da visão geral por trás da criação das linguagens de programação , em geral, ou seja, quando as coisas como considerações de segurança de tipo vs. memória fazem a diferença):
int não é 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);
com saída
Bar is true
Bar is 1
Baz is 1
Baz is true
O código Java na terceira linha (bar)?1:0ilustra que a barra ( booleana ) não pode ser implicitamente convertida (convertida) em um int . Estou trazendo isso à tona não para ilustrar os detalhes da implementação por trás da JVM, mas para salientar que, em termos de considerações de baixo nível (como tamanho da memória), é preciso preferir valores à segurança do tipo. Especialmente se esse tipo de segurança não for verdadeira / totalmente utilizado como nos tipos booleanos em que as verificações são feitas na forma de
se o valor \ in {0,1}, em seguida, converter para o tipo booleano, caso contrário, lance uma exceção.
Tudo apenas para afirmar que {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}. Parece um exagero, certo? A segurança do tipo é realmente importante nos tipos definidos pelo usuário, não na conversão implícita de primitivos (embora o último esteja incluído no primeiro).
Bytes não são tipos ou bits
Observe que na memória sua variável do intervalo {0,1} ainda ocupará pelo menos um byte ou uma palavra (xbits, dependendo do tamanho do registro), a menos que seja especialmente cuidado (por exemplo, compactado na memória - 8 "booleano" bits em 1 byte - para frente e para trás).
Ao preferir a segurança do tipo (como colocar / embalar o valor em uma caixa de um tipo específico) em vez de empacotar um valor extra (por exemplo, usar troca de bits ou aritmética), escolhe-se efetivamente escrever menos código e ganhar mais memória. (Por outro lado, sempre é possível definir um tipo de usuário personalizado que facilitará toda a conversão que não valha mais que Boolean).
palavra-chave x tipo
Por fim, sua pergunta é sobre a comparação de palavra-chave x tipo . Eu acredito que é importante explicar por que ou como exatamente você obterá desempenho usando / preferindo palavras-chave ("marcadas" como primitivas ) sobre tipos (classes compostas normais definidas pelo usuário usando outra classe de palavras-chave ) ou em outras palavras
boolean foo = true;
vs.
Boolean foo = true;
A primeira "coisa" (tipo) não pode ser estendida (subclasse) e não sem um motivo. Efetivamente, a terminologia Java de classes primitivas e de quebra automática pode ser simplesmente traduzida em valor embutido (uma LITERAL ou uma constante que é diretamente substituída pelo compilador sempre que é possível inferir a substituição ou, se não for - ainda é uma alternativa para quebrar o valor).
A otimização é alcançada devido a trivial:
"Menos operações de conversão de tempo de execução => mais velocidade."
É por isso que, quando a inferência de tipo real é feita, ela pode (ainda) acabar instanciando a classe de quebra automática com todas as informações de tipo, se necessário (ou convertendo / convertendo em tal).
Portanto, a diferença entre booleano e booleano está exatamente em Compilation e Runtime (um pouco longe, mas quase como exemplo de vs getClass () ).
Por fim, a caixa automática é mais lenta que as primitivas
Observe que o Java pode fazer autoboxing é apenas um "açúcar sintático". Não acelera nada, apenas permite escrever menos código. É isso aí. A transmissão e o empacotamento no contêiner de informações de tipo ainda são executados. Por motivos de desempenho, escolha aritmética que sempre ignorará a limpeza extra da criação de instâncias de classe com informações de tipo para implementar a segurança de tipo. Falta de segurança de tipo é o preço que você paga para obter desempenho. Para código com expressões com valor booleano, digite safety (quando você escreve menos e, portanto, código implícito ) seria crítico, por exemplo, para controles de fluxo if-then-else.