Primitive type 'short' - casting in Java

Question

I have a question about the primitive type short in Java. I am using JDK 1.6.

If I have the following:

short a = 2;
short b = 3;
short c = a + b;

the compiler does not want to compile - it says that it "cannot convert from int to short" and suggests that I make a cast to short, so this:

short c = (short) (a + b);

really works. But my question is why do I need to cast? The values of a and b are in the range of short - the range of short values is {-32,768, 32767}. I also need to cast when I want to perform the operations -, *, / (I haven't checked for others).

If I do the same for primitive type int, I do not need to cast aa+bb to int. The following works fine:

int aa = 2;
int bb = 3;
int cc = aa +bb;

I discovered this while designing a class where I needed to add two variables of type short, and the compiler wanted me to make a cast. If I do this with two variables of type int, I don't need to cast.

A small remark: the same thing also happens with the primitive type byte. So, this works:

byte a = 2;
byte b = 3;
byte c = (byte) (a + b);

but this not:

byte a = 2;
byte b = 3;
byte c = a + b;

For long, float, double, and int, there is no need to cast. Only for short and byte values.

Solution 1

As explained in short C# (but also for other language compilers as well, like Java)

There is a predefined implicit conversion from short to int, long, float, double, or decimal.

You cannot implicitly convert nonliteral numeric types of larger storage size to short (see Integral Types Table for the storage sizes of integral types). Consider, for example, the following two short variables x and y:

short x = 5, y = 12;

The following assignment statement will produce a compilation error, because the arithmetic expression on the right-hand side of the assignment operator evaluates to int by default.

short z = x + y;   // Error: no conversion from int to short

To fix this problem, use a cast:

short z = (short)(x + y);   // OK: explicit conversion

It is possible though to use the following statements, where the destination variable has the same storage size or a larger storage size:

int m = x + y;
long n = x + y;

---

A good follow-up question is:

"why arithmetic expression on the right-hand side of the assignment operator evaluates to int by default" ?

A first answer can be found in:

Classifying and Formally Verifying Integer Constant Folding

The Java language specification defines exactly how integer numbers are represented and how integer arithmetic expressions are to be evaluated. This is an important property of Java as this programming language has been designed to be used in distributed applications on the Internet. A Java program is required to produce the same result independently of the target machine executing it.

In contrast, C (and the majority of widely-used imperative and object-oriented programming languages) is more sloppy and leaves many important characteristics open. The intention behind this inaccurate language specification is clear. The same C programs are supposed to run on a 16-bit, 32-bit, or even 64-bit architecture by instantiating the integer arithmetics of the source programs with the arithmetic operations built-in in the target processor. This leads to much more efficient code because it can use the available machine operations directly. As long as the integer computations deal only with numbers being “sufficiently small”, no inconsistencies will arise.

In this sense, the C integer arithmetic is a placeholder which is not defined exactly by the programming language specification but is only completely instantiated by determining the target machine.

Java precisely defines how integers are represented and how integer arithmetic is to be computed.

      Java Integers
--------------------------
Signed         |  Unsigned
--------------------------
long  (64-bit) |
int   (32-bit) |
short (16-bit) |  char (16-bit)
byte  (8-bit)  |

Char is the only unsigned integer type. Its values represent Unicode characters, from \u0000 to \uffff, i.e. from 0 to 2¹⁶−1.

If an integer operator has an operand of type long, then the other operand is also converted to type long. Otherwise the operation is performed on operands of type int, if necessary shorter operands are converted into int. The conversion rules are exactly specified.

[From Electronic Notes in Theoretical Computer Science 82 No. 2 (2003)
Blesner-Blech-COCV 2003: Sabine GLESNER, Jan Olaf BLECH,
Fakultät für Informatik,
Universität Karlsruhe
Karlsruhe, Germany]

Solution 2

EDIT: Okay, now we know it's Java...

Section 4.2.2 of the Java Language Specification states:

The Java programming language provides a number of operators that act on integral values:

[...]

The numerical operators, which result in a value of type int or long:

[...]

The additive operators + and - (§15.18)

In other words, it's like C# - the addition operator (when applied to integral types) only ever results in int or long, which is why you need to cast to assign to a short variable.

Original answer (C#)

In C# (you haven't specified the language, so I'm guessing), the only addition operators on primitive types are:

int operator +(int x, int y);
uint operator +(uint x, uint y);
long operator +(long x, long y);
ulong operator +(ulong x, ulong y);
float operator +(float x, float y);
double operator +(double x, double y);

These are in the C# 3.0 spec, section 7.7.4. In addition, decimal addition is defined:

decimal operator +(decimal x, decimal y);

(Enumeration addition, string concatenation and delegate combination are also defined there.)

As you can see, there's no short operator +(short x, short y) operator - so both operands are implicitly converted to int, and the int form is used. That means the result is an expression of type "int", hence the need to cast.

Solution 3

In C# and Java, the arithmatic expression on the right hand side of the assignment evaluates to int by default. That's why you need to cast back to a short, because there is no implicit conversion form int to short, for obvious reasons.

Solution 4

Given that the "why int by default" question hasn't been answered ...

First, "default" is not really the right term (although close enough). As noted by VonC, an expression composed of ints and longs will have a long result. And an operation consisting of ints/logs and doubles will have a double result. The compiler promotes the terms of an expression to whatever type provides a greater range and/or precision in the result (floating point types are presumed to have greater range and precision than integral, although you do lose precision converting large longs to double).

One caveat is that this promotion happens only for the terms that need it. So in the following example, the subexpression 5/4 uses only integral values and is performed using integer math, even though the overall expression involves a double. The result isn't what you might expect...

(5/4) * 1000.0

OK, so why are byte and short promoted to int? Without any references to back me up, it's due to practicality: there are a limited number of bytecodes.

"Bytecode," as its name implies, uses a single byte to specify an operation. For example iadd, which adds two ints. Currently, 205 opcodes are defined, and integer math takes 18 for each type (ie, 36 total between integer and long), not counting conversion operators.

If short, and byte each got their own set of opcodes, you'd be at 241, limiting the ability of the JVM to expand. As I said, no references to back me up on this, but I suspect that Gosling et al said "how often do people actually use shorts?" On the other hand, promoting byte to int leads to this not-so-wonderful effect (the expected answer is 96, the actual is -16):

byte x = (byte)0xC0;
System.out.println(x >> 2);

Solution 5

What language are you using?

Many C based languages have a rule that any mathematical expression is performed in size int or larger. Because of this, once you add two shorts the result is of type int. This causes the need for a cast.

View more solutions

Comments

[Palo]

What is particularly annoying is when you have a function that takes short as an argument, and you want to pass a constant to it in that argument. You have to typecast that constant to short. For instance, passing a 0 to short argument of a function gives an error. That is a scandal!

[VonC]

You could add msdn.microsoft.com/en-us/library/aa691375(VS.71).aspx for linking to the 7.7.4 section

[Jon Skeet]

Yes, it's a shame that there isn't a simple hyperlinked version of the C# 3.0 spec. The MSDN version is too painful IMO :(

[Saurabh]

We now know it's Java, hence there's no uint or ulong. I can't remember whether Java overloads operator + for BigInteger and/or BigDecimal

[VonC]

Still at 0 ?! C'mon... +1, you did mention the specs right ;) Could you have a look at my follow-up question in my answer and see if you have some insight on that topic ?(i.e. "why int by default ?")

[BaroqueBobcat]

the url has been oracleified. docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.2‌​.2

[Jon Skeet]

@BaroqueBobcat: Thanks, fixed.

[wchargin]

Also T a, b; a += b is equivalent to T a, b; a = (T) (a + b): notice the compiler-added cast.

[mafu]

The expected answer is 48, isn't it?

[Gordon]

Nonsense, because I can add two int MAXVALUE and it won't require that LHS be a long.

[LAFK says Reinstate Monica]

Not exactly. final byte a = (byte) (new Random().nextInt(4)); and Incompatible types rears it's ugly head again. It's not just finality, it's being able to compile it away to a value that fits the type.

[Soner from The Ottoman Empire]

tell your complaint to Herbert Schildt, it's his idea. @LIttleAncientForestKami

[LAFK says Reinstate Monica]

I would if I had one @snr, especially since not even Shildt could help against javac. ;-) Your words imply that final assures compiler, and it may not be enough. If we take your example verbatim, all is fine and dandy. But try replacing b = 3 with b = (byte)(new Random().nextInt(4)). and incompatible types are back and a+b needs casting again. You may want to add that to your answer.

[Heimdall]

@mafu It is. So >> casts to int?? The effect, however, is what's in Z80 called SRA (shift right arithmetical), which shifts bits of a byte to the right 1 place, losing the rightmost one and duplicating the leftmost one (so dividing a signed byte by 2), as opposed to SRL (shift right logical), which leaves a zero bit on the left (same as dividing an unsigned byte by 2), which is what the "expected answer" is based on.

[Palo]

Yes, but that's not full truth, obviously you can store 16-bit or 8-bit values into 16-bit and 8-bit registers and then perform arithmetic there. This would allow to have more register variables, i.e. fewer accesses to memory, i.e. more efficient code. Of course, java byte-code and JIT compiler would have to allow that, but it does not mean that it is not a java design flaw prevnting writing more efficient code.