Java's Primitive Types, and the Four That Trip Everyone Up

A ruler with no thirds#

Take a ruler marked only in halves, then quarters, then eighths, then sixteenths, and keep going as fine as you like.

You can measure a half exactly. A quarter, exactly. Three eighths, exactly. Now measure one third. You cannot. Not because your ruler is cheap, and not because you are measuring carelessly — one third simply is not one of the marks, and it never will be, however fine you cut them. The best you can ever do is land on the nearest mark and be a hair out.

A computer stores decimals on exactly that ruler. Its marks are halves and quarters and eighths, because it counts in twos. Anything that is not built from those pieces gets the nearest mark instead, and 0.1 is one of the numbers that misses.

Every type on this page has an edge like that: a point where it stops behaving the way the number line in your head behaves. Those edges are what exams ask about, so we will walk all eight and mark where each one breaks.

Does this print true?#

System.out.println(0.1 + 0.2 == 0.3);

True or false? Decide before you scroll.

Almost everybody says true. Nothing here looks difficult — it is the arithmetic we learned at eight years old.

false

Not a bug, and not Java being awkward. double stores numbers in binary, and 0.1 has no exact binary form, exactly as 1/3 has no exact decimal form. So 0.1 + 0.2 lands a hair above 0.3, and == compares them honestly and says no.

Every primitive type has a shape like this: a size, a range, and an edge where it stops behaving the way the number line does. Those edges are what get examined, so we will go through all eight and mark where each one breaks.

The eight primitives#

Java has exactly eight primitive types. They are not objects, they hold a value directly, and they are the only types that work this way — everything else in Java, String included, is a reference type.

Two of those rows deserve a second look. int is the default for whole numbers and double is the default for decimals — which is exactly why the next two errors happen.

Literals have types before they are assigned#

This looks like it should obviously work, and it does not compile:

long big = 10000000000;

Big.java:3: error: integer number too large
        long big = 10000000000;
                   ^
1 error

The variable is a long, so what is too large? The literal is. Java reads 10000000000 as an int before it ever looks at the left-hand side, and ten billion does not fit in an int. The L suffix tells the compiler to read it as a long from the start:

long big = 10000000000L;   // compiles

Say it out loud as “ten billion, long”. The L is not decoration and it is not part of the number; it is an instruction to the compiler about which type to read the digits as, given before it reads them.

The same thing happens with float, in the other direction:

float f = 3.14;

Flt.java:3: error: incompatible types: possible lossy conversion from double to float
        float f = 3.14;
                  ^
1 error

3.14 is a double, and squeezing a 64-bit value into a 32-bit variable could lose precision, so Java refuses. Write 3.14f.

int x = 5;
byte b = x;   // error: incompatible types: possible lossy conversion from int to byte

Trap 1 — integer division throws away the remainder#

If both operands are whole numbers, Java does whole-number division. There is no rounding involved:

System.out.println(7 / 2);
System.out.println(7 % 2);
System.out.println(7.0 / 2);

3
1
3.5

7 / 2 is 3, not 3.5 and not 4. The % operator recovers the remainder that division discarded.

The fix is to make at least one operand floating-point — but where you put the cast decides whether it works:

System.out.println((double) 7 / 2);     // cast first, then divide
System.out.println((double) (7 / 2));   // divide first, then cast

3.5
3.0

In the second line the damage is already done: 7 / 2 evaluated to the int 3, and casting 3 to a double gives 3.0. Casting cannot recover information that was already discarded.

Trap 2 — overflow is silent#

System.out.println(Integer.MAX_VALUE);
System.out.println(Integer.MAX_VALUE + 1);

2147483647
-2147483648

Adding one to the largest possible int produces the smallest possible int. No exception, no warning, no crash — the value wraps around like a car odometer rolling over, and the program keeps going with a wrong number.

This is why counters, running totals, and anything measured in milliseconds usually want long, not int.

Trap 3 — decimals are not exact#

System.out.println(0.1 + 0.2);
System.out.println(0.1 + 0.2 == 0.3);

0.30000000000000004
false

double and float store values in binary. One tenth cannot be written exactly in binary for the same reason one third cannot be written exactly in decimal — the digits never stop. What gets stored is the nearest available value, and the tiny errors accumulate.

Trap 4 — char is a number wearing a costume#

System.out.println('A' + 1);
System.out.println((char) ('A' + 1));

66
B

A char holds a number identifying a character; 'A' is 65. Arithmetic on it therefore produces a number, and Java promotes the result to int — which is why the first line prints 66 and not 'B'. Casting the result back to char gives the letter.

This is genuinely useful once you expect it. ch - 'a' converts a lowercase letter to its position in the alphabet, and (char) ('a' + n) converts a position back to a letter.

Casting truncates, it does not round#

System.out.println((int) 9.99);
System.out.println((int) -9.99);

9
-9

A cast to int deletes the fractional part and moves toward zero. It is not Math.floor either — floor would give −10 for the second one. If you want rounding, say so with Math.round.

Where these go wrong#

• Computing an average with integer division. (a + b) / 2 on two ints silently truncates. This is the single most common version of Trap 1.
• Casting after the fact. (double) (sum / count) is too late. Cast an operand, not the result.
• Using == on doubles. It compiles, it runs, and it returns false for values that look identical when printed.
• Forgetting L and f. Both produce compile errors that name a type you did not write, which makes them confusing until you know that the literal has a type of its own.
• Expecting overflow to announce itself. It does not. A total that suddenly goes negative is the symptom.
• Reading 'A' + 1 as string concatenation. Concatenation means joining text end to end, and it needs a String on one side of the +. Both operands here are numeric, so + is plain addition.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written — several of these exist because somebody asked.