Why byte and short division results in int in Java?

Question

In Java, if we divide bytes, shorts or ints, we always get an int. If one of the operands is long, we'll get long.

My question is - why does byte or short division not result in byte or short? Why always int?

Apparently I'm not looking for the "because JLS says so" answer, I am asking about the technical rationale for this design decision in the Java language.

Consider this code sample:

    byte byteA = 127;
    byte byteB = -128;
    short shortA = 32767;
    short shortB = -32768;
    int intA = 2147483647;
    int intB = - -2147483648;
    long longA = 9223372036854775807L;
    long longB = -9223372036854775808L;


    int byteAByteB = byteA/byteB;
    int byteAShortB = byteA/shortB;
    int byteAIntB = byteA/intB;
    long byteALongB = byteA/longB;

    int shortAByteB = shortA/byteB;
    int shortAShortB = shortA/shortB;
    int shortAIntB = shortA/intB;
    long shortALongB = shortA/longB;

    int intAByteB = intA/byteB;
    int intAShortB = intA/shortB;
    int intAIntB = intA/intB;
    long intALongB = intA/longB;

    long longAByteB = longA/byteB;
    long longAShortB = longA/shortB;
    long longAIntB = longA/intB;
    long longALongB = longA/longB;

byteA divided by byteB can't be anything but a byte, can it?
So why must byteAByteB be an int? Why can't shortALongB be short?
Why does intALongB have to be long, the result will always fit int, will it not?

Update

As @Eran pointed out, (byte)-128/(byte)-1 results in 128 which does not fit a byte. But why not short then?

Update 2

Next, as @Eran pointed out (again), (int) -2147483648 / (int) -1 also does not fit int but the result is nevertheless int, not long.

The rule is the same in any C-like languages. Moreover JVM is written in C and C++ so it follows the same rule [Why are integer types promoted during addition in C?](https://stackoverflow.com/q/29817927/995714) — phuclv, Aug 05 '18 at 02:27

Eran · Answer 1 · 2016-12-08T08:08:06.317

8

byteA divided by byteB can't be anything but a byte, can it?

It can be other than byte :

byteA = -128;
byteB = -1;
int div = byteA/byteB; // == 128, not a byte

edited Dec 08 '16 at 08:08

answered Dec 08 '16 at 08:05

Eran

387,369
54
702
768

Point taken. Why not `short` then? – lexicore Dec 08 '16 at 08:06
`not a byte` .. in Java because it has no notion of unsigned .. 128 is still just a byte (`char`) in other languages that support unsigned – txtechhelp Dec 08 '16 at 08:09
Note that `char` is a 16 bit *unsigned* type in Java. Nice. – Bathsheba Dec 08 '16 at 08:15
@lexicore You got a point, and my example doesn't work when dividing Integer.MIN_VALUE by -1 (you'll get an int overflow, since the operands won't be promoted to long). – Eran Dec 08 '16 at 08:16
@Eran `-2147483648/-1` results in `-2147483648`. Cool. Breaks my logic for today. – lexicore Dec 08 '16 at 08:23

Jean-Baptiste Yunès · Accepted Answer · 2016-12-08T13:42:42.797

The main reason is that machines usually have only add instructions for their native integer type (and floats). This is why for many languages the least used type in an arithmetic expression is int (usually the type that correspond in some way to the basic machine integer type).

For example, i386 spec says:

ADD performs an integer addition of the two operands (DEST and SRC). The result of the addition is assigned to the first operand (DEST), and the flags are set accordingly. When an immediate byte is added to a word or doubleword operand, the immediate value is sign-extended to the size of the word or doubleword operand.

This means that internally any byte value is extended to an integer (or similar). After all this is reasonable as the processor is 32/64 bits and then perform any arithmetic in these sizes. If it could be possible to make arithmetic in bytes this is generally not considered as useful.

The JVM specs says that (for addition) you have : iadd, ladd, fadd, dadd. This just reflect the fact that underlying machines usually behave such. Any other choice could have been possible, probably at the price of performance degradation.

Bathsheba · Answer 3 · 2016-12-08T08:14:16.817

I guess it's something that was adopted from C, possibly via C++.

In those languages, an argument or arguments are always promoted to int if they are narrower types than an int. This happens before the expression is evaluated. Quite often it goes unnoticed since the resulting operation is converted to the type to which it is being assigned, and a compiler may well optimise out all the intermediate steps if there are no side effects.

In Java though it's not too pernicious. (In C and C++ it can catch you out: a multiplication of two large unsigned shorts can overflow the int, the behaviour of which is undefined.)

Note that if one of the arguments is larger than an int, then the type of the expression is the largest of the arguments types.

Peter Lawrey · Answer 4 · 2016-12-08T08:13:52.347

3

I believe the justification is that a simple rules creates least surprise. The result is always the wider type of the two (minimum being int), it doesn't depend on the operation.

A better approach might be to always widen +, *, - unless explicitly (or perhaps implicitly) narrowed. i.e. don't do overflow or underflow unless you use a cast. / for example could always be a double or long operation unless casted.

But C and thus Java doesn't do this.

In short, it has one simple rule for dealing with this, for better or worse.

See my rant here http://vanillajava.blogspot.co.uk/2015/02/inconsistent-operation-widen-rules-in.html

edited Dec 08 '16 at 08:13

answered Dec 08 '16 at 08:10

Peter Lawrey

525,659
79
751
1,130

1

Are you sure it's the wider type of the two? My understanding is that that's the case if one of the arguments is larger than an `int`, but if both are `int`s or smaller, the result is always an `int`. But I'm not an expert on Java type promotion. – Bathsheba Dec 08 '16 at 08:13
At least though it doesn't introduce a truck load of UB in Java ;-) – Bathsheba Dec 08 '16 at 08:14
@Bathsheba UB...? – Peter Lawrey Dec 08 '16 at 08:15
1

Undefined Behaviour. – Bathsheba Dec 08 '16 at 08:16
1

In your blog post: `char * char isn't a meaningful operation even though it is allowed`---I strongly disagree there. `char` is the only unsigned integer type in Java, we should all learn to love and cherish it! – Marko Topolnik Dec 08 '16 at 08:31
@MarkoTopolnik char is useful but using it to store non characters could be confusing. – Peter Lawrey Dec 08 '16 at 08:33
Only until you get used to it. We're already using `byte` to store signed integers, so go figure :) – Marko Topolnik Dec 08 '16 at 08:34

score 1 · Answer 5 · edited Nov 28 '17 at 12:09

Whenever you're defining a variable of type byte, whatever you type across from it should be of type byte.

That means it can only be a number in the range of a byte (-128 to 127).

However, when you type in an expression, for ex. byteA/byteB that is not the same as typing in a literal, for ex. the number 127.

This is the nature of Java - the integer is the default data type used for whole numbers.

By default when you're making an assignment of an expression, Java converts that into the default data type (integer) despite the fact that the result of the expression might be a valid value for a byte.

So what happens is that when you define a byte and assign an expression as the value of that byte, Java will need to convert it into an integer:

int byteAByteB = byteA / byteB;

However, you can get around that by casting the assigned expression and thus forsing Java to treat it as a byte.

byte byteAByteB = (byte) (byteA / byteB);

This way you're telling Java to treat that as a byte. (Can also be done with short, etc.)

Why byte and short division results in int in Java?

5 Answers5

Linked