Boolean vs booléen en Java

Question

Il y a discussion autour d'Entiers vs int en Java. La valeur par défaut est null alors que dans le plus tard, c'est 0. Comment sur les vs boolean?

Une variable dans mon application peut avoir 0/1 valeurs. Je voudrais utiliser boolean/Boolean et préférez ne pas utiliser int. Puis-je utiliser Boolean/boolean à la place?

Merci.

Answer 1

oui vous pouvez utiliser Boolean/boolean à la place.

Premier est l'Objet et le second est de type primitif

Sur la première, vous obtiendrez plus de méthodes qui seront utiles

Seconde est bon marché compte tenu de la mémoire de frais.

Maintenant, choisissez votre chemin

Answer 2

Boolean encapsule le booléen de type primitif. Dans le JDK 5 et vers le haut, Oracle (ou au Soleil avant d'Oracle acheté) introduit l'autoboxing/unboxing, qui vous permet de le faire

boolean result = Boolean.TRUE;

ou

Boolean result = true; 

Qui est essentiellement le compilateur ne,

Boolean result = Boolean.valueOf(true);

Donc, pour votre réponse, c'est OUI.

Answer 3

Je suis un peu l'extension fourni des réponses (car jusqu'à présent, ils se concentrent sur leur "propre"/artificiel de la terminologie en se concentrant sur la programmation d'une langue en particulier, au lieu de s'occuper de la plus grande image derrière la scène de la création des langages de programmation, en général, c'est à dire quand les choses comme type de sécurité contre la mémoire des considérations de faire la différence):

int n'est pas booléenne

Envisager

    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 la sortie

    Bar is true
    Bar is 1
    Baz is 1
    Baz is true

Code Java sur la 3e ligne, (bar)?1:0 montre que la barre (boolean) ne peut pas être implicitement converti (coulé) dans un int. Je vais de ce pas pour illustrer les détails de mise en œuvre derrière la JVM, mais de constater qu'en termes de faible niveau considérations (comme la taille de la mémoire) on ne fait préférer des valeurs de type de sécurité. Surtout si ce type de sécurité n'est pas vraiment/entièrement utilisé que dans les types boolean, où les contrôles sont faits en forme de

si la valeur de \dans {0,1}, puis en fonte de type booléen, sinon de lever une exception.

Tout juste à l'état que {0,1} < {-2^31, .. , 2^31 -1}. Semble exagéré, non? Type de la sécurité qui est vraiment important dans les types définis par l'utilisateur, pas de conversion implicite de primitives (bien que les derniers sont inclus dans le premier).

Octets ne sont pas les types de bits

Notez que dans la mémoire de votre variable de gamme de {0,1} occupera encore au moins un octet ou un mot (xbits en fonction de la taille du registre), sauf spécialement pris en charge (par exemple, joliment emballé dans la mémoire - 8 "boolean" bits 1 octet - et-vient).

En préférant la sécurité de type (comme d'/conditionnement valeur dans une case d'un type particulier) sur la valeur supplémentaire d'emballage (par ex. à l'aide de peu de postes ou de l'arithmétique), on n'a effectivement choisit d'écrire moins de code sur gagner plus de mémoire. (Sur l'autre main, on peut toujours définir un personnalisé du type d'utilisateur qui permettra de faciliter la conversion n'en vaut pas que Booléen).

mot-clé vs type

Enfin, votre question est au sujet de la comparaison clé vs type. Je crois qu'il est important d'expliquer pourquoi ou comment exactement vous obtiendrez des performances à l'aide de/préférant les mots-clés ("marqué" comme primitive) sur les types (normal composite définissables par l'utilisateur classes à l'aide d'un autre mot-clé de la classe) ou en d'autres termes

boolean foo = true;

vs

Boolean foo = true;

La première "chose" (type) ne peut pas être prolongé (sous-classé) et pas sans raison. Effectivement Java terminologie de primitif et d'emballage des classes peuvent être simplement traduit en inline valeur (un LITTÉRAL ou une constante qui obtient directement remplacé par le compilateur lorsqu'il est possible de déduire de la substitution, ou si ce n'est pas toujours de secours dans l'emballage de la valeur).

L'optimisation est réalisée en raison triviale:

"Moins runtime activités de fonte => plus de vitesse."

C'est pourquoi, lorsque le réel de l'inférence de type est fait, il peut (encore) la fin de l'instanciation d'emballage de classe avec toutes les informations de type si nécessaire (ou de la conversion/moulage en exemple).

Donc, la différence entre les booléens et Booléen est exactement dans la Compilation et de l' Exécution (un peu loin mais c'est presque comme instanceof vs getClass()).

Enfin, l'autoboxing est plus lent que les primitives

Remarque le fait que Java peut faire l'autoboxing est juste un "sucre syntaxique". Il ne permet pas d'accélérer quoi que ce soit, permet d'écrire moins de code. C'est tout. Moulage et d'emballage dans les informations de type de conteneur est toujours pratiquée. Pour des raisons de performances, choisissez l'arithmétique qui sera toujours ignorer un service de ménage supplémentaire de créer des instances de classe avec des informations de type pour mettre en œuvre le type de sécurité. Le manque de sécurité de type est le prix à payer pour le gain de performance. Pour le code avec boolean-valeur des expressions de type de sécurité (lorsque vous écrivez moins et donc implicite code) serait critique par exemple, pour si-alors-sinon de flux de contrôle.

Answer 4

Vous pouvez utiliser les constantes de type Boolean - Boolean.TRUE et Boolean.FALSE au lieu de 0 et 1. Vous pouvez créer votre variable de type boolean si primitive est ce que vous êtes après. De cette façon, vous n'aurez pas à créer de nouveaux Boolean objets.