Are the &, |, ^ bitwise operators or logical operators?

Question

Firstly I learnt that &, |, ^ are the bitwise operators, and now somebody mentioned them as logical operators with &&, ||, I am completely confused - the same operator has two names? There are already logical operators &&, ||, then why use &, |, ^?

Answer 1

The Java operators &, | and ^ are EITHER bitwise operators OR logical operators ... depending on the types of the operands. If the operands are integers, the operators are bitwise. If they are booleans, then the operators are logical.

And this is not just me saying this. The JLS describes these operators this way too; see JLS 15.22.

(This is just like + meaning EITHER addition OR string concatenation ... depending on the types of the operands. Or just like a "rose" meaning either a flower or a shower attachment. Or "cat" meaning either a furry animal or a UNIX command. Words mean different things in different contexts. And this is true for the symbols used in programming languages too.)

---

There are already logical operators &&, ||, why use &, |, ^?

In the case of the first two, it is because the operators have different semantics with regards to when / whether the operands get evaluated. The two different semantics are needed in different situations; e.g.

    boolean res = str != null && str.isEmpty();

versus

    boolean res = foo() & bar();  // ... if I >>need<< to call both methods.

The ^ operator has no short-circuit equivalent because it simply doesn't make sense to have one.

Answer 2

Having a language reference is one thing, interpreting it correctly is another.

We need to interpret things correctly.

Even if Java documented that & is both bitwise and logical, we could make an argument that & really didn't lost its logical-operator-ness mojo since time immemorial, since C. That is, & is first and foremost, an inherently logical operator(albeit a non-short-circuited one at that)

& parses lexically+logically as logical operation.

To prove the point, both of these lines behaves the same, eversince C and upto now(Java, C#, PHP, etc)

if (a == 1 && b)

if (a == 1 & b)

That is, the compiler will interpret those as these:

if ( (a == 1) && (b) )

if ( (a == 1) & (b) )

And even if both variables a and b are both integers. This...

if (a == 1 & b)

... will still be interpereted as:

if ( (a == 1) & (b) )

Hence, this will yield a compilation error on languages which doesn't facilitate integer/boolean duality, e.g. Java and C#:

if (a == 1 & b)

In fact, on the compilation error above, we could even make an argument that & didn't lost its logical(non-short-circuit) operation mojo, and we can conclude that Java continues the tradition of C making the & still a logical operation. Consequently, we could say it's the other way around, i.e. the & can be repurposed as bitwise operation (by applying parenthesis):

if ( a == (1 & b) )

So there we are, in another parallel universe, someone could ask, how to make the & expression become a bitmask operation.

How to make the following compile, I read in JLS that & is a bitwise operation. Both a and b are integers, but it eludes me why the following bitwise operation is a compilation error in Java:

if (a == 1 & b)

Or this kind of question:

Why the following didn't compile, I read in JLS that & is a bitwise operation when both its operands are integers. Both a and b are integers, but it eludes me why the following bitwise operation is a compilation error in Java:

if (a == 1 & b)

In fact, I would not be surprised if there's already an existing stackoverflow questions similar to above questions that asked how to do that masking idiom in Java.

To make that logical operation interpretation by the language become bitwise, we have to do this (on all languages, C, Java, C#, PHP, etc):

if ( a == (1 & b) )

So to answer the question, it's not because JLS defined things such way, it's because Java(and other languages inspired by C)'s & operator is for all intents and purposes is still a logical operator, it retained C's syntax and semantics. It's the way it is since C, since time immemorial, since before I was even born.

Things just don't happen by chance, JLS 15.22 didn't happen by chance, there's a deep history around it.

In another parallel universe, where && was not introduced to the language, we will still be using & for logical operations, one might even ask a question today:

Is it true, we can use the logical operator & for bitwise operation?

& doesn't care if its operands are integers or not, booleans or not. It's still a logical operator, a non-short-circuited one. And in fact, the only way to force it to become a bitwise operator in Java(and even in C) is to put parenthesis around it. i.e.

if ( a == (1 & b) )

Think about it, if && was not introduced to C language(and any language who copied its syntax and semantics), anyone could be asking now:

how to use & for bitwise operations?

To sum it up, first and foremost Java & is inherently a logical operator(a non-short-circuited one), it doesn't care about its operands, it will do its business as usual(applying logical operation) even if both operands are integers(e.g. masking idiom). You can only force it to become bitwise operation by applying parenthesis. Java continues the C tradition

If Java's & really is a bitwise operation if its operands(integer 1 and integer variable b on example code below) are both integers, this should compile:

 int b = 7;
 int a = 1;

 if (a == 1 & b) ...

Answer 3

They(& and |) were used for two purposes long time ago, logical operator and bitwise operator. If you'll check out the neonatal C (the language Java was patterned after), & and | were used as logical operator.

But since disambiguating the bitwise operations from logical operations in the same statement is very confusing, it prompted Dennis Ritchie to create a separate operator(&& and ||) for logical operator.

Check the Neonatal C section here: http://cm.bell-labs.com/who/dmr/chist.html

You can still use the bitwise operators as logical operators, its retained operator precedence is the evidence of that. Read out the history of bitwise operator's past life as logical operator on Neonatal C

Regarding the evidence, I made a blog post on comparing the logical operator and bitwise operator. It will be self-evident that the so called bitwise operators are still logical operators if you try contrasting them in an actual program: http://www.anicehumble.com/2012/05/operator-precedence-101.html

I also answered a question related to your question on What is the point of the logical operators in C?

So it's true, bitwise operators are logical operators too, albeit non-short-circuited version of short-circuited logical operators.

---

Regarding

There are already logical operators &&, ||, then why use &, |, ^?

The XOR can be easily answered, it's like a radio button, only one is allowed, code below returns false. Apology for the contrived code example below, the belief that drinking both beer and milk at the same time is bad was debunked already ;-)

String areYouDiabetic = "Yes";
String areYouEatingCarbohydrate = "Yes";


boolean isAllowed = areYouDiabetic == "Yes" ^ areYouEatingCarbohydrate == "Yes";

System.out.println("Allowed: " + isAllowed);

There's no short-circuit equivalent to XOR bitwise operator, as both sides of the expression are needed be evaluated.

Regarding why the need to use & and | bitwise operators as logical operators, frankly you'll be hard-pressed to find a need to use bitwise operators(a.k.a. non-short-circuit logical operators) as logical operators. A logical operation can be non-short-circuited (by using the bitwise operator, aka non-short-circuited logical operator) if you want to achieve some side effect and make your code compact(subjective), case in point:

while ( !password.isValid() & (attempts++ < MAX_ATTEMPTS) ) {

    // re-prompt

}

The above can re-written as the following(removing the parenthesis), and still has exactly the same interpretation as the preceding code.

while ( !password.isValid() & attempts++ < MAX_ATTEMPTS ) {

    // re-prompt

}

Removing the parenthesis and yet it still yields the same interpretation as the parenthesized one, can make the logical operator vestige of & more apparent. To run the risk of sounding superfluous, but I have to emphasize that the unparenthesized expression is not interpreted as this:

while ( ( !password.isValid() & attempts++ ) < MAX_ATTEMPTS ) {

    // re-prompt

}

To sum it up, using & operator (more popularly known as bitwise operator only, but is actually both bitwise and logical(non-short-circuited)) for non-short-circuit logical operation to achieve side effect is clever(subjective), but is not encouraged, it's just one line of savings effect in exchange for readability.

Example sourced here: Reason for the exsistance of non-short-circuit logical operators

Answer 4

The Java type byte is signed which might be a problem for the bitwise operators. When negative bytes are extended to int or long, the sign bit is copied to all higher bits to keep the interpreted value. For example:

byte b1=(byte)0xFB; // that is -5
byte b2=2;
int i = b1 | b2<<8;
System.out.println((int)b1); // This prints -5
System.out.println(i);       // This prints -5

Reason: (int)b1 is internally 0xFFFB and b2<<8 is 0x0200 so i will be 0xFFFB

Solution:

int i = (b1 & 0xFF) | (b2<<8 & 0xFF00);
System.out.println(i); // This prints 763 which is 0x2FB