Why does the compiler not give an error for this addition operation?

Question

I know that the compiler does implicit type conversion for integer literals. For example:

byte b = 2; // implicit type conversion, same as byte b = (byte)2;

The compiler gives me an error if the range overflows:

byte b = 150; // error, it says cannot convert from int to byte

The compiler gives the same error when the variable is passed an expression:

byte a = 3;
byte b = 5;
byte c = 2 + 7; // compiles fine
byte d = 1 + b; // error, it says cannot convert from int to byte
byte e = a + b; // error, it says cannot convert from int to byte

I came to the conclusion that the result of an expression that involves variables cannot be guaranteed. The resulting value can be within or outside the byte range so compiler throws off an error.

What puzzles me is that the compiler does not throw an error when I put it like this:

byte a = 127;
byte b = 5;
byte z = (a+=b); // no error, why ?

Why does it not give me an error?

Answer 1

While decompiling your code will explain what Java is doing, the reason why it's doing it can be generally found in the language specification. But before we go into that, we have to establish a few important concepts:

• A literal numeral is always interepreted as an int.

  An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1).

• A byte can only hold an integer value between -128 and 127, inclusive.

• An attempt to assign a literal that is larger than the type that can hold it will result in a compilation error. This is the first scenario you're encountering.

So we're back to this scenario: why would adding two bytes that are clearly more than what a byte can handle not produce a compilation error?

It won't raise a run-time exception because of overflow.

This is the scenario in which two numbers added together suddenly produce a very small number. Due to the small size of byte's range, it's extremely easy to overflow; for example, adding 1 to 127 would do it, resulting in -128.

The chief reason it's going to wrap around is due to the way Java handles primitive value conversion; in this case, we're talking about a narrowing conversion. That is to say, even though the sum produced is larger than byte, the narrowing conversion will cause information to be discarded to allow the data to fit into a byte, as this conversion never causes a run-time exception.

To break down your scenario step by step:

• Java adds a = 127 and b = 5 together to produce 132.
• Java understands that a and b are of type byte, so the result must also be of type byte.
• The integer result of this is still 132, but at this point, Java will perform a cast to narrow the result to within a byte - effectively giving you (byte)(a += b).
• Now, both a and z contain the result -124 due to the wrap-around.

Answer 2

The answer is provided by JLS 15.26.2:

For example, the following code is correct:

short x = 3;

x += 4.6;

and results in x having the value 7 because it is equivalent to:

short x = 3;

x = (short)(x + 4.6);

So, as you can see, the latest case actually work because the addition assignment (as any other operator assignment) performs an implicit cast to the left hand type (and in your case a is a byte). Extending, it is equivalent to byte e = (byte)(a + b);, which will compile happily.

Answer 3

I came to the conclusion that the result of an expression that involves variables cannot be guaranteed. The resulting value can be within or outside the byte range so compiler throws off an error.

No, that's not the reason. The compilers of a staticly-typed language work in this way: Any variable must be declared and typed, so even if its value is not known at compile-time, its type is known. The same goes for implicit constants. Based upon this fact, the rules to compute scales are basically these:

• Any variable must have the same or higher scale than the expression at its right side.
• Any expression has the same scale of the maximum term involved on it.
• An explicit cast forces, of corse, the scale of the right-side expression.

(These are in fact a simplified view; actually might be a little more complex).

Apply it to your cases:

byte d = 1 + b

The actual scales are:

byte = int + byte

... (because 1 is considered as an implicit int constant). So, applying the first rule, the variable must have at least int scale.

And in this case:

byte z = (a+=b);

The actual scales are:

byte = byte += byte

... which is OK.

Update

Then, why byte e = a + b produce a compile-time error?

As I said, the actual type rules in java are more complex: While the general rules apply to all types, the primitive byte and short types are more restricted: The compiler assumes that adding/substracting two or more bytes/shorts is risking to cause an overflow (as @Makoto stated), so it requires to be stored as the next type in scale considered "safer": an int.

Answer 4

The basic reason is that the compiler behaves a little differently when constants are involved. All integer literals are treated as int constants (unless they have an L or l at the end). Normally, you can't assign an int to a byte. However, there's a special rule where constants are involved; see JLS 5.2. Basically, in a declaration like byte b = 5;, 5 is an int, but it's legal to do the "narrowing" conversion to byte because 5 is a constant and because it fits into the range of byte. That's why byte b = 5 is allowed and byte b = 130 is not.

However, byte z = (a += b); is a different case. a += b just adds b to a, and returns the new value of a; that value is assigned to a. Since a is a byte, there is no narrowing conversion involved--you're assigning a byte to a byte. (If a were an int, the program would always be illegal.)

And the rules say that a + b (and therefore a = a + b, or a += b) won't overflow. If the result, at runtime, is too large for a byte, the upper bits just get lost--the value wraps around. Also, the compiler will not "value follow" to notice that a + b would be larger than 127; even though we can tell that the value will be larger than 127, the compiler won't keep track of the previous values. As far as it knows, when it sees a += b, it only knows that the program will add b to a when it runs, and it doesn't look at previous declarations to see what the values will be. (A good optimizing compiler might actually do that kind of work. But we're talking about what makes a program legal or not, and the rules about legality don't concern themselves with optimization.)

Answer 5

I have encountered this before in one project and this is what I learned:

unlike c/c++, Java is always use signed primitives. One byte is from -128 to +127 so if you assign anything behind this range it will give you compile error.

If you explicitly convert to byte like (byte) 150 still you won't get what you want (you can check with debugger and see it will convert to something else).

When you use variables like x = a + b because the compiler doesn't know the values at run time and cannot calculate whether -128 <= a+b <= +127 it will give error.

Regarding your question about why compiler doesn't give error on something like a+=b :

I dig into java compiler available from openjdk at

http://hg.openjdk.java.net/jdk9/jdk9/langtools.

I traced the tree processing of operands and came to an interesting expression in one of the compiler files Lower.java which partially responsible for traversing the compiler tree. here is a part of the code that would be interesting (Assignop is for all of the operands like += -= /= ...)

public void visitAssignop(final JCAssignOp tree) {
                        ...
                        Symbol newOperator = operators.resolveBinary(tree,
                                                                      newTag,
                                                                      tree.type,
                                                                      tree.rhs.type);
                        JCExpression expr = lhs;
                        //Interesting part:
                        if (expr.type != tree.type)
                            expr = make.TypeCast(tree.type, expr);
                        JCBinary opResult = make.Binary(newTag, expr, tree.rhs);
                        opResult.operator = newOperator;:

                        ....

as you can see if the rhs has different type than the lhs, the type cast would take place so even if you declare float or double on the right hand side (a+=2.55) you will get no error because of the type cast.

Answer 6

/*
 * Decompiled Result with CFR 0_110.
 */
class Test {
    Test() {
    }

    public static /* varargs */ void main(String ... arrstring) {
        int n = 127;
        int n2 = 5;
        byte by = (byte)(n + n2);
        n = by;
        byte by2 = by;
    }
}

After decompilation of your Code

class Test{
public static void main(String... args){
byte a = 127;
byte b = 5;
byte z = (a+=b); // no error, why ?
}
}

Internally, Java replaced your a+=b operator with (byte)(n+n2) the code.

Answer 7

The expression byte1+byte2 is equivalent to (int)byte1+(int)byte2, and has type int. While the expression x+=y; would generally be equivalent to var1=var1+var2;, such an interpretation would make it impossible to use += with values smaller than int, so the compiler will treat byte1+=byte2 as byte1=(byte)(byte1+byte2);.

Note that Java's type system was designed first and foremost for simplicity, and its rules were chosen to as to make sense in many cases, but because making the rules simple was more important than making them consistently sensible, there are many cases where the type system rules yield nonsensical behavior. One of the more interesting ones is illustrated via:

long l1 = Math.round(16777217L)
long l2 = Math.round(10000000000L)

In the real world, one wouldn't try to round long constants, of course, but the situation might arise if something like:

long distInTicks = Math.round(getDistance() * 2.54);

were changed to eliminate the scale factor [and getDistance() returned long]. What values would you expect l1 and l2 should receive? Can you figure out why they might receive some other value?