By polygenelubricants

2010-02-24 08:25:17 8 Comments

So for binary operators on booleans, Java has &, |, ^, && and ||.

Let's summarize what they do briefly here:

For &, the result value is true if both operand values are true; otherwise, the result is false.

For |, the result value is false if both operand values are false; otherwise, the result is true.

For ^, the result value is true if the operand values are different; otherwise, the result is false.

The && operator is like & but evaluates its right-hand operand only if the value of its left-hand operand is true.

The || operator is like |, but evaluates its right-hand operand only if the value of its left-hand operand is false.

Now, among all 5, 3 of those have compound assignment versions, namely |=, &= and ^=. So my question is obvious: why doesn't Java provide &&= and ||= as well? I find that I need those more than I need &= and |=.

And I don't think that "because it's too long" is a good answer, because Java has >>>=. There must be a better reason for this omission.

From 15.26 Assignment Operators:

There are 12 assignment operators; [...] = *= /= %= += -= <<= >>= >>>= &= ^= |=

A comment was made that if &&= and ||= were implemented, then it would be the only operators that do not evaluate the right hand side first. I believe this notion that a compound assignment operator evaluates the right hand side first is a mistake.

From 15.26.2 Compound Assignment Operators:

A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.

As proof, the following snippet throws a NullPointerException, not an ArrayIndexOutOfBoundsException.

    int[] a = null;
    int[] b = {};
    a[0] += b[-1];


@Marcono1234 2020-08-16 14:08:40

Brian Goetz (Java Language Architect at Oracle) wrote: [this question] shows that there is interest in having these operators and there are no clear arguments why they don't exist yet. The question is therefore: Has the JDK team discussed adding these operators in the past and if so what where the reasons against adding them?

I'm not aware of any specific discussion on this particular issue, but if someone were to propose it, the answer would likely be: it's not an unreasonable request, but it doesn't carry its weight.

"Carrying its weight" needs to be judged by its costs and benefits, and by its cost-benefit ratio relative to other candidate features.

I think you are implicitly assuming (by the phrase "there is interest") that the cost is near zero and the benefit is greater than zero, so it seems an obvious win. But this belies an incorrect understanding of cost; a feature like this affects the language spec, the implementation, the JCK, and every IDE and Java textbook. There are no trivial language features. And the benefit, while nonzero, is pretty small.

Secondarily, there are infinitely many features we could do, but we only have capacity to do a handful every few years (and users have a limited capacity to absorb new features.) So we have to be very careful as to which we pick, as each feature (even a trivial-seeming one) consumes some of this budget, and invariably takes it away from others.
It's not "why not this feature", but "what other features will we not do (or delay) so we can do this one, and is that a good trade?" And I can't really imagine this being a good trade against anything else we're working on.

So, it clears the bar of "not a terrible idea" (which is already pretty good, a lot of feature requests don't even clear that), but seems unlikely to ever clear the bar of "a better use of our evolution budget than anything else."

@olibre 2012-03-29 15:30:09


The operators &&= and ||= are not available on Java because for most of the developers these operators are:

  • error-prone
  • useless

Example for &&=

If Java allowed &&= operator, then that code:

bool isOk = true; //becomes false when at least a function returns false
isOK &&= f1();
isOK &&= f2(); //we may expect f2() is called whatever the f1() returned value

would be equivalent to:

bool isOk = true;
if (isOK) isOk = f1();
if (isOK) isOk = f2(); //f2() is called only when f1() returns true

This first code is error-prone because many developers would think f2() is always called whatever the f1() returned value. It is like bool isOk = f1() && f2(); where f2() is called only when f1() returns true.

If the developer wants f2() to be called only when f1() returns true, therefore the second code above is less error-prone.

Else &= is sufficient because the developer wants f2() to be always called:

Same example but for &=

bool isOk = true;
isOK &= f1();
isOK &= f2(); //f2() always called whatever the f1() returned value

Moreover, the JVM should run this above code as the following one:

bool isOk = true;
if (!f1())  isOk = false;
if (!f2())  isOk = false;  //f2() always called

Compare && and & results

Are the results of operators && and & the same when applied on boolean values?

Let's check using the following Java code:

public class qalcdo {

    public static void main (String[] args) {
        test (true,  true);
        test (true,  false);
        test (false, false);
        test (false, true);

    private static void test (boolean a, boolean b) {
        System.out.println (counter++ +  ") a=" + a + " and b=" + b);
        System.out.println ("a && b = " + (a && b));
        System.out.println ("a & b = "  + (a & b));
        System.out.println ("======================");

    private static int counter = 1;


1) a=true and b=true
a && b = true
a & b = true
2) a=true and b=false
a && b = false
a & b = false
3) a=false and b=false
a && b = false
a & b = false
4) a=false and b=true
a && b = false
a & b = false

Therefore YES we can replace && by & for boolean values ;-)

So better use &= instead of &&=.

Same for ||=

Same reasons as for &&=:
operator |= is less error-prone than ||=.

If a developer wants f2() not to be called when f1() returns true, then I advice the following alternatives:

// here a comment is required to explain that 
// f2() is not called when f1() returns false, and so on...
bool isOk = f1() || f2() || f3() || f4();


// here the following comments are not required 
// (the code is enough understandable)
bool isOk = false;
if (!isOK) isOk = f1();
if (!isOK) isOk = f2(); //f2() is not called when f1() returns false
if (!isOK) isOk = f3(); //f3() is not called when f1() or f2() return false
if (!isOK) isOk = f4(); //f4() is not called when ...

@olibre 2012-04-03 08:31:05

Hi @StriplingWarrior. I have checked with my colleague Yannick, our best Java expert. I have updated my answer using the Java code source used to check that point. As you said & and &&give the same results. Thank you very much for your feedback. Do you like my answer? Cheers.

@adventurerOK 2012-06-18 17:55:32

What if I want to do this very fast? &&= would be faster than &=, if it existed, so you should use if (a) a = b for speed

@olibre 2012-06-25 13:08:12

Hi @adventurerOK. Sorry I am not sure to understand what you mean... I think a&=b; is faster than if(a) a=b; when using values stored within the CPU registers. However, if b is in external memory (not cached), then if(a) a=b; is faster. Is it what you mean? Please provide more example code ;-) I am curious about your opinion. See you. Cheers

@Tor Klingberg 2013-06-04 13:32:43

I don't agree when you say "And this is not what we want." If I write isOK &&= f2(); I would want it to short circuit just like && does.

@olibre 2013-06-04 14:05:08

Thanks @TorKlingberg for your feedback. I am just realizing that people may think different! All right, I update my answer ;) Cheers

@Franz B. 2015-07-17 14:26:27

I do not agree with your claim that the operators would be error-prone or useless. Using compound assignments is something you do to take a shortcut for the usual A = A op B, so everyone perfectly knows what they are doing and can care for the implications themselves. If your reasons were indeed the cause for its absence, I would see it as unwanted patronizing. However, I wanna thank you for adding the line bool isOk = f1() || f2() || f3() || f4(); because that's what I was to blind to see myself.

@olibre 2015-07-18 10:53:07

Thanks @FranzB. for your feedback: you are right. I will update the answer soon (no enough time at the moment to deeply enter in this topic) Cheers ;-)

@fishinear 2017-05-07 11:30:12

Your multiple lines with if statements are a lot LESS understandable: it is not clear anymore that it is a simple or-expression. For the same reason, if (!f1()) isOk = false; is less understandable than isOk &&= f1();

@Ely 2015-06-12 13:20:56


verifies both operands, it's a bitwise operator. Java defines several bitwise operators, which can be applied to the integer types, long, int, short, char, and byte.


stops evaluating if the first operand evaluates to false since the result will be false, it's a logical operator. It can be applied to booleans.

The && operator is similar to the  & operator, but can make your code a bit more efficient. Because both expressions compared by the & operator must be true for the entire expression to be true, there’s no reason to evaluate the second expression if the first one returns false. The & operator always evaluates both expressions. The && operator evaluates the second expression only if the first expression is true.

Having a &&= assignment operator wouldn't really add new functionality to the language. The bitwise operator's arithmetic is much more expressive, you can do integer bitwise arithmetic, which includes Boolean arithmetic. The logical operators can merely do Boolean arithmetic.

@zanfilip 2013-02-21 16:03:56

For Boolean vars, && and || would use short circuit evaluation while & and | don't, so you would expect &&= and ||= to also use short circuit evaluation. There is a good use case for this. Especially if you are iterating over a loop, you want to be fast, efficient and terse.

Instead of writing

foreach(item in coll)
   bVal = bVal || fn(item); // not so elegant

I want to write

foreach(item in coll)
  bVal ||= fn(item);    // elegant

and know that once bVal is true, fn() will not be called for the remainder of the iterations.

@Radiodef 2015-06-12 13:19:17

For that loop you probably just want to do if (fn(item)) { bVal = true; break; }.

@Josh Lee 2010-02-24 08:33:31

Probably because something like

x = false;
x &&= someComplexExpression();

looks like it ought to be assigning to x and evaluating someComplexExpression(), but the fact that the evaluation hinges on the value of x isn't apparent from the syntax.

Also because Java's syntax is based on C, and no one saw a pressing need to add those operators. You'd probably be better off with an if statement, anyway.

@polygenelubricants 2010-02-24 08:41:55

I think this is not a good answer, because one can argue that x() && y() looks like it ought to evaluate both sides of the expression. Obviously people accept that && is short-circuiting, so that should also follows to &&= as well.

@PSpeed 2010-02-24 08:46:42

@jleedev, agreed. I believe in these situations it's important to remember that this isn't the equivalent of x = x && someComplexExpression() but the equivalent of x = someComplexExpression() && x. The right-hand side will/should be evaluated first to be consistent with every other assignment operator. And given that, &&= would have no different behavior than &=.

@Josh Lee 2010-02-24 08:47:22

@polygene That's fair. How something looks is based on what you're familiar with, though, and I guess they didn't want to add anything new. One thing I like about C/C++/Java/C# is that the basic syntax of expressions is nearly identical.

@polygenelubricants 2010-02-24 08:52:13

@PSpeed, you are mistaken. The JLS is very clear on what the compound assignment is supposed to do. See my addition above.

@polygenelubricants 2010-02-24 09:52:02

I think saying that they aren't there because the designers simply followed the precedence set by C is misleading, since they did add >>> and >>>=, which are entirely new.

@David Thornley 2010-03-22 14:09:52

@PSpeed: In that case, a -= b; would work entirely differently from a &&= b;.

@p00ya 2010-02-24 08:31:06

Largely because Java syntax is based on C (or at least the C family), and in C all those assignment operators get compiled to arithmetic or bitwise assembly instructions on a single register. The assignment-operator version avoids temporaries and may have produced more efficient code on early non-optimising compilers. The logical operator (as they are termed in C) equivalents (&&= and ||=) don't have such an obvious correspondence to single assembly instructions; they usually expand to a test and branch sequence of instructions.

Interestingly, languages like ruby do have ||= and &&=.

Edit: terminology differs between Java and C

@polygenelubricants 2010-02-24 08:40:42

I believe you mean the conditional operator equivalents don't have such obvious correspondence. In JLS terminology, the boolean logical operators are &, | and ^; && and || are the conditional operators.

@p00ya 2010-02-24 09:29:51

In C terminology, && and || are "logical operators", s6.5.13-14 in ISO 9899:1999. The bitwise operators are only "logical" when applied to a single bit (a boolean in java); there is no single-bit type in C and the logical operators there apply to all scalar types.

@v.oddou 2020-04-02 08:05:48

before C99, C didn't even have a bool type. That's 20 years in the language history with no bool. There was no reason to have &&=. bitwise operations were enough.

@EFraim 2009-10-01 17:39:22

It is this way in Java, because it is this way in C.

Now the question why it is so in C is because when & and && became different operators (sometime preceding C's descent from B), the &= variety of operators was simply overlooked.

But the second part of my answer does not have any sources to back it up.

@UKMonkey 2019-03-13 15:10:20

On the funny side - the question was recently asked in the C forum; and this answer was linked (though not marked duplicate) Which makes completes the circular argument!

@Yishai 2009-10-01 17:59:54

One of Java's original aims was to be "Simple, Object Oriented, and Familiar." As applied to this case, &= is familiar (C, C++ have it and familiar in this context meant familiar to someone who knows those two).

&&= would not be familiar, and it would not be simple, in the sense that the language designers were not looking to think of every operator they could add to the language, so less extra operators are simpler.

@NawaMan 2009-10-01 17:50:24

'&' and '&&' are not the same as '&&' is a short cut operation which will not do if the first operand is false while '&' will do it anyway (works with both number and boolean).

I do agree that it make more sense to exist but it is not that bad if it is not there. I guess it was not there because C does not have it.

Really can't think of why.

@Daniel Brückner 2009-10-01 17:40:14

I cannot think of any better reason then 'It looks incredible ugly!'

@EFraim 2009-10-01 17:45:45

But then C/Java was never meant to be beautiful.

@asgs 2017-05-17 07:32:33

I'd barely consider &&= to be ugly

@Omry Yadan 2009-10-01 17:40:00

a&b and a && b are not the same thing.

a && b is a boolean expression that returns a boolean, and a & b is a bitwise expression that returns an int (if a and b are ints).

whare do you think they are the same?

@Daniel Brückner 2009-10-01 17:47:25

a & b should unlike a && b always evaluate b.

@zzawaideh 2009-10-01 17:39:55

It is allowed in Ruby.

If I were to guess, I would say that it is not frequently used so it wasn't implemented. Another explanation could be that the parser only looks at the character before the =

@Yishai 2009-10-01 18:01:14

Java supports <<=, >>= and >>>=, so that isn't strictly true.

@zzawaideh 2009-10-05 14:41:00

true. I didn't think of those. I guess the only explanation is then how frequently it is used.

Related Questions

Sponsored Content

32 Answered Questions

[SOLVED] Why doesn't RecyclerView have onItemClickListener()?

26 Answered Questions

[SOLVED] Does Python have a ternary conditional operator?

15 Answered Questions

[SOLVED] Why does Java have transient fields?

  • 2009-05-26 12:11:36
  • Animesh
  • 702939 View
  • 1500 Score
  • 15 Answer
  • Tags:   java field transient

11 Answered Questions

16 Answered Questions

[SOLVED] Why doesn't Java offer operator overloading?

5 Answered Questions

1 Answered Questions

1 Answered Questions

Sponsored Content