J'étends un peu les réponses fournies (car jusqu'à présent, elles se concentrent sur leur "propre" / terminologie artificielle se concentrant sur la programmation d'un langage particulier au lieu de prendre soin de la vue d'ensemble derrière la scène de la création des langages de programmation , en général, c'est-à-dire lorsque les choses comme les considérations de sécurité de type par rapport à la mémoire font la différence):
int n'est pas booléen
Considérer
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);
avec sortie
Bar is true
Bar is 1
Baz is 1
Baz is true
Le code Java sur la 3ème ligne (bar)?1:0illustre que la barre ( booléenne ) ne peut pas être implicitement convertie (castée) en int . Je soulève cette question non pas pour illustrer les détails de l'implémentation derrière JVM, mais pour souligner qu'en termes de considérations de bas niveau (comme la taille de la mémoire), il faut préférer les valeurs à la sécurité des types. Surtout si ce type de sécurité n'est pas vraiment / pleinement utilisé comme dans les types booléens où les contrôles sont effectués sous forme de
si value \ in {0,1}, transtypez en type booléen, sinon lève une exception.
Tout cela pour dire que {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}. On dirait une exagération, non? La sécurité des types est vraiment importante dans les types définis par l'utilisateur, et non dans la conversion implicite des primitives (bien que les dernières soient incluses dans la première).
Les octets ne sont pas des types ou des bits
Notez qu'en mémoire, votre variable de la plage de {0,1} occupera toujours au moins un octet ou un mot (xbits selon la taille du registre) à moins que cela ne soit spécialement pris en charge (par exemple, bien emballé en mémoire - 8 "booléen" bits en 1 octet - d'avant en arrière).
En préférant la sécurité des types (comme pour mettre / envelopper des valeurs dans une boîte d'un type particulier) plutôt que des valeurs supplémentaires (par exemple en utilisant des décalages de bits ou de l'arithmétique), on choisit effectivement d'écrire moins de code plutôt que de gagner plus de mémoire. (D'un autre côté, on peut toujours définir un type d'utilisateur personnalisé qui facilitera toute la conversion ne valant pas que booléen).
mot-clé vs type
Enfin, votre question porte sur la comparaison du mot clé et du type . Je crois qu'il est important d'expliquer pourquoi ou comment vous obtiendrez exactement des performances en utilisant / préférant des mots clés ("marqués" comme primitifs ) par rapport aux types (classes composites normales définissables par l'utilisateur utilisant une autre classe de mots clés ) ou en d'autres termes
boolean foo = true;
contre.
Boolean foo = true;
La première "chose" (type) ne peut pas être étendue (sous-classée) et non sans raison. Terminologie Java efficace de la primitive classes et enveloppantes peut être simplement traduite en valeur en ligne (un LITERAL ou une constante qui est directement substituée par le compilateur chaque fois qu'il est possible d'inférer la substitution ou sinon - toujours de retour dans l'encapsulation de la valeur).
L'optimisation est obtenue en raison de trivial:
"Moins d'opérations de casting à l'exécution => plus de vitesse."
C'est pourquoi, lorsque l'inférence de type réelle est effectuée, elle peut (encore) aboutir à l'instanciation de la classe d'habillage avec toutes les informations de type si nécessaire (ou la conversion / conversion en une telle).
Ainsi, la différence entre booléen et booléen est exactement dans Compilation et Runtime (un peu loin mais presque comme instanceof vs getClass () ).
Enfin, l'autoboxing est plus lent que les primitives
Notez que Java peut faire de l' autoboxing n'est qu'un "sucre syntaxique". Il n'accélère rien, vous permet simplement d'écrire moins de code. C'est tout. La coulée et l'emballage dans le conteneur d'informations de type sont toujours effectués. Pour des raisons de performances, choisissez l'arithmétique qui ignorera toujours la gestion supplémentaire de la création d'instances de classe avec des informations de type pour implémenter la sécurité de type. Le manque de sécurité de type est le prix à payer pour gagner en performances. Pour le code avec des expressions à valeur booléenne, la sécurité du type (lorsque vous écrivez moins et donc du code implicite ) serait critique, par exemple pour les contrôles de flux if-then-else.