Every value has a size, and sizes run out

Think about the little counter on a bike, the one that counts how far you've ridden. It has six windows with digits in them. Ride far enough and it shows 999999. Ride one metre more and it doesn't show 1000000 — it can't. There's no seventh window. It flips back to 000000 and starts again. Your computer is made of counters exactly like that one. Bigger, but still with a fixed number of windows. In about twenty minutes we're going to ride one off the end.

What you'll be able to do

• Make a variable — a named place to keep a value — and change what's in it.
• Pick the right kind of variable: a score, a view count, a height, a yes/no, or a letter.
• Explain, out loud, why 0.1 + 0.2 doesn't give 0.3.
• Predict what 7 / 2 gives in Java — and be right, which most beginners are not.
• Spot the two moments where a computer's counters run out, and know how to avoid them.

Section 1A variable is a labelled box

Memory is the computer's scratch space — where it keeps things it's using right now. It is a very long row of those lockers. Making a variable does three things. Java picks an unused locker, writes your chosen name on the tape, then puts a value inside. From here on this course calls one of them a box.

The name matters. Memory's boxes are told apart by number, and box 140732920755612 isn't something you want to type. So you give it a name instead, and Java remembers which number that name means.

Here's the whole thing in one line of Java. The lines you write are called code.

int score = 7;

Read it left to right. int says what kind of thing this box will hold — a whole number, no fractions. score is the name going on the tape. The = means "put the thing on the right into the box on the left". 7 is the thing being put in. The ; at the end is a full stop. Java wants one after every instruction.

That's it. That's a variable. It's called a variable because the value inside can vary — you can swap it for a different one later. The name on the tape stays the same.

Section 2Declaring, assigning, and doing both at once

Those three jobs from Section 1 have names, and it's worth pulling them apart. Declaring is making the box and writing the name. Assigning is putting a value in. You can do them on separate lines.

int score;              // declare: make the box, label it "score"
score = 7;              // assign: put 7 in the box
System.out.println(score);

score = 12;             // re-assign: throw away 7, put 12 in
System.out.println(score);

score = score + 1;      // read the box, add 1, put the answer back
System.out.println(score);

Line by line. Line 1 makes an empty box named score. The word int is still needed, because Java has to know how big to make it. Line 2 puts 7 inside. Line 3 prints what's inside. System.out.println is Java's "write this on the screen" instruction, which you met in 0.1.

Next comes score = 12;, which is a re-assignment. It does not make a second box. It opens the existing one, tips 7 out, and puts 12 in. The 7 is gone for good. Then it prints again. The last pair of lines is the odd bit, and we'll take it apart in a second.

Section 3= does not mean equals

This is the single biggest trip-up in your first week, so we're going to sit with it.

In maths class, = is a claim about the world. "x = 5" says x and 5 are the same thing. It's a fact, and you can read it in either direction.

In Java, = is an order. Work out whatever is on the right, then put the result in the box named on the left. It only goes one way. It claims nothing. Some people read it aloud as "gets" — score gets 7 — and honestly that's a better name for it.

Java does have a "really equals" for asking questions. It's two equals signs, ==, and it arrives next chapter. One = puts things in boxes. Two == asks a question.

7
12
13

Section 4Why Java makes you say the kind first

Java boxes have shaped holes. When you write int, you cut a whole-number-shaped hole in that box, and nothing else fits. This is called static typing.

Both halves of that phrase need unpacking, so here they are. "Typing" means kind of thing — what sort of value is allowed in here. And static means decided beforehand. It's settled before the program runs, and it can't change while it's running. So static typing means Java knows the kind of every box in advance, and checks it in advance.

Remember from 0.1 that Java has two stages. First javac compiles your code — checks it, then turns it into a form the computer can run. Then java runs the result. The type checking happens in stage one. So Java refuses to build a program it can already see is wrong.

A file in your src/ folder proves it. It's meant to fail.

int age = 15.5;      // a whole-number box, given a fraction

One line. A box shaped for whole numbers, handed something with a half in it. One word in the coming error is worth meeting before you read it. Java calls the change lossy, which means it would lose part of the value — here, the .5. Here's exactly what javac says, run on this machine:

WrongKind.java:5: error: incompatible types: possible lossy conversion from double to int
        int age = 15.5;      // a whole-number box, given a fraction
                  ^
1 error

Unpack that message, because you'll see its relatives for years. WrongKind.java:5 is the file and the line number. "incompatible types" means the shapes don't match. "lossy conversion" is the word we just met — changing 15.5 into a whole number would throw the .5 away. The ^ points at the exact spot.

Java is also strict about empty boxes. Try this one:

Empty.java:6: error: variable score might not have been initialized
        System.out.println(score);       // Java refuses to read it
                           ^
1 error

"Initialized" is a long word for "given its first value". The box was made but never filled. Java won't hand you whatever old rubbish is sitting in that patch of memory. Some languages would. Java won't.

Section 5The five kinds you'll actually use

Java has eight basic kinds, called primitive types. "Primitive" here means raw material — not built out of anything smaller. You'll use five constantly, and three almost never.

int score = 7;
long viewCount = 9000000000L;      // the L says "this is a long"
double height = 1.62;
boolean gameOver = false;
char grade = 'B';                  // single quotes, exactly one letter

Line 1: int is your default for counting things — whole numbers, positive or negative. Line 2: long is an int with a much bigger box. The L on the end isn't optional. Without it Java reads 9000000000 as an int and complains, because it doesn't fit. Line 3: double holds numbers with a fractional part. Line 4: boolean holds one of exactly two values, true or false. Line 5: char holds a single character in single quotes. Double quotes mean something else, and that's a later chapter.

Running it prints each one back:

score     7
viewCount 9000000000
height    1.62
gameOver  false
grade     B

Now the sizes. A bit is one on/off switch — the smallest thing a computer can store. Eight bits make one byte. These numbers came from running src/Sizes.java, which asks Java itself rather than trusting anyone's memory:

The bottom three exist, and you can forget them for now. byte and short save memory you don't need to save. float is a smaller, sloppier double. Stick to int, long, double, boolean, char.

That E308 means "and then 308 more digits' worth of zeroes". Enormous. But hold on to this: a big range is not the same as being exact. Section 8 is going to be rude about that.

Section 6Everything is on/off switches

Count on your fingers. One hand gives you five numbers, because you're using each finger as a tally mark.

Now cheat. Don't tally — make each finger worth a different amount. Thumb is 1, index is 2, middle is 4, ring is 8, little finger is 16. Every finger is either up or down. How high can you count now?

Thumb alone is 1. Index alone is 2. Both is 3. Middle alone is 4. Middle and thumb is 5. Keep going, and every number from 0 to 31 has exactly one finger pattern. That's binary: each position is worth double the one before, and each is only ever on or off.

Computers work this way because a switch is easy to build and a "seven" is not. Electricity flows, or it doesn't. Written down, an up finger is 1 and a down finger is 0. src/Bits.java shows the switches behind some numbers:

number -> switches
     0 -> 0
     1 -> 1
     2 -> 10
     3 -> 11
     5 -> 101
     7 -> 111
    13 -> 1101
   255 -> 11111111

MAX_VALUE -> 1111111111111111111111111111111
MAX + 1   -> 10000000000000000000000000000000
which is    -2147483648

Check 13 by hand. Read 1101 right to left: 1 + 0 + 4 + 8, which is 13. And 255 is eight switches all on — the biggest eight switches can make. Which is exactly why a byte stops where it does.

Here's the sentence the whole chapter hangs on. A fixed number of switches can only make a fixed number of patterns. An int gets 32 switches, which is 4,294,967,296 patterns. Not one more, ever. Java spends half of them on negative numbers, so the top lands at 2,147,483,647.

Section 7The surprise: riding off the end

Back to the bike counter. Six windows, so 999999 is the top, and one more metre rolls it to 000000. An int has 32 windows instead of six, and they're binary, but the principle is identical. So what happens when you add 1 to the biggest int there is?

Before you answer: this catches people who've been paid to write code for years. In 1996 it destroyed a rocket. The Ariane 5's guidance computer moved a number into a box too small to hold it. Make this a bet with yourself.

big      = 2147483647
big + 1  = -2147483648
small    = -2147483648
small - 1= 2147483647
as long  = 2147483648
byte 127+1 = -128

This is called overflow, and the mechanism is the bike counter exactly. The biggest int in binary is 31 ones in a row. Add one and every switch flips, the way 999999 + 1 flips every digit. There's no 33rd switch to carry into, so the carry falls off the end. And Java reads the leftmost switch as the minus sign. So the pattern for "one past the top" is also the pattern for "the very bottom".

MAX_VALUE -> 1111111111111111111111111111111
MAX + 1   -> 10000000000000000000000000000000

All ones, then a one followed by nothing but zeroes. The switches did the sensible thing. It's our reading of the leftmost one as "negative" that makes it a surprise.

Now look back at the other output lines. small - 1 wraps the other way, from the bottom straight to the top. byte 127+1 gives -128, because a byte has only 8 switches and runs out much sooner. And as long prints 2147483648 correctly — same sum, bigger box, no wrap.

Do it with your own hands

Reading about the switches is one thing. Flipping them is another. Below are the 32 switches of a real int, and the number they add up to. Click any switch to turn it on or off.

Three things to try, in this order. Each one has an exact answer, so check the number on screen against the one written here.

1. It starts at MAX_VALUE, reading 2,147,483,647 — every switch on except the leftmost. Press add 1. Every single switch flips, and the number becomes -2,147,483,648. That's the smallest int there is.
2. Press MAX_VALUE again, then click the leftmost switch on its own. All 32 switches are now on, and the number reads -1. One switch took you from two billion to minus one.
3. Press -1 and count the switches it lights up. All 32 of them, every time. If the leftmost switch were just a minus sign, that pattern would be the biggest negative number instead.

That last one is worth sitting with. If the leftmost switch were simply a minus sign, then all switches on would be the biggest negative number there is. It isn't — it's -1. That's two's complement doing its thing: flip every switch, then add one. The rule's in the box above if you skipped it. And the circuitry it saves gets taken apart in Phase 3, in C.

Section 8Second surprise: doubles lie

So whole numbers can run out. Fractions have a different problem, and it's worse, because it shows up with tiny everyday numbers.

Try writing one third as a decimal. 0.3? Not quite. 0.333? Closer. You can add threes forever and never land on it. One third is a perfectly good number — base ten has no exact way to write it down.

Binary has the same problem with a different set of numbers. Base ten writes halves, quarters, fifths and tenths exactly. Base two writes halves, quarters and eighths exactly — but not fifths, and not tenths. So 0.1 is base two's version of one third. Java stores the closest pattern it can and moves on.

0.1 + 0.2 = 0.30000000000000004
is it 0.3? false

ten 10p coins = 0.9999999999999999
0.1 is really 0.1000000000000000055511151231257827021181583404541015625

ten 10p coins, in pennies = 100

Walk down that output. Line 1: the sum is off by 0.00000000000000004 — small, but not zero. Line 2: asking "is it 0.3" gives false. That's why you must never test doubles for exact equality. Line 3: ten 10p coins come to 0.9999999999999999. A till built this way is short of a pound. Line 4 is the confession. Line 5 shows the fix.

double is still right for heights, speeds, temperatures and averages. Anywhere an error in the sixteenth decimal place truly doesn't matter. It's wrong anywhere someone counts the pennies.

Section 97 / 2 is 3, and % is the bit left over

One more place where Java's answer isn't the one you learned in school. When both sides of a / are whole numbers, Java does whole-number division. The answer must fit a whole-number box, so anything after the decimal point is thrown away. Not rounded — thrown away.

7 / 2   = 3
7 % 2   = 1
7.0 / 2 = 3.5
10 / 3  = 3
10 % 3  = 1
9 % 3   = 0
each gets  3
left over  1
fair share 3.5

The % is the remainder operator. Share 7 things between 2 people: / says each gets 3, and % says 1 is left over. Despite the symbol, it has nothing to do with percentages. You'll also hear it called modulo. That's just the maths name for the same job: the amount left over after a division. Same thing, older word.

Two things % is brilliant at. "Is this even?" — n % 2 == 0. And "wrap around a fixed number of slots". day % 7 keeps you inside a week, however big day gets. You'll meet % again in Phase 2. There a hash table has to squeeze any number at all into a fixed number of slots. It's the same trick as the days of the week, doing a much bigger job.

Section 10A letter is a number in a costume

Your computer stores no letters. It has switches, so it has numbers, so somebody had to agree which number means which letter. That agreement is a big lookup table. It puts capital A at 65, B at 66, and so on in order.

A char is that number. Java prints it as a letter to be helpful. Which leads somewhere strange.

The predict below uses one new piece of writing, so meet it first. A type name in round brackets, like (char), is a cast. It means "take this value and treat it as that kind instead". Written in front of a number, (char) says "read this one as a letter, please". You're the one asking, so you're the one taking responsibility.

letter        = A
as a number   = 65
'A' + 1       = 66
(char)('A'+1) = B
'a' as number = 97
'0' as number = 48
int -> double = 7.0
(int) 3.99    = 3
(int) -3.99   = -3
Math.round    = 4

So the cast is what did the work. (char) took the plain 66 and said "print this one as a letter", and out came B. Leave the cast off and you get the number, because maths on a char hands back an int.

Casting goes two ways, and Java treats the two very differently. Moving a value into a roomier box is called widening — the box gets wider, so nothing can be lost. Java therefore does it silently. Every int fits inside a double with room to spare.

Going the other way, into a smaller box, is called narrowing. Now something might not fit, and whatever doesn't fit gets thrown away. So Java refuses to do it behind your back. You have to write the cast and sign for the loss.

int whole = 7;
double asDouble = whole;          // widening: automatic

double messy = 3.99;
int chopped = (int) messy;        // narrowing: you must ask

The first line makes an int holding 7. The second copies it into a double. Nothing is asked of you, and it prints as 7.0. The third makes a double holding 3.99. The last one casts it to int, and the result is 3 — the .99 is deleted, not rounded. That (int) is you signing for the loss. From the output, (int) -3.99 gives -3, so a cast always chops toward zero. When you want real rounding, ask for it: Math.round(3.99) gives 4.

One more from that output: '0' is 48, not 0. The character zero and the number zero are different things.

Section 11final glues the box shut

Sometimes a value must never change. The number of lives in your game. The number of letters in a Wordle answer. If a later line changes it by accident, you'll hunt that bug for an hour. Put final in front of the declaration, and Java refuses to let anything re-assign it.

final int MAX_LIVES = 3;
System.out.println("lives allowed: " + MAX_LIVES);

MAX_LIVES = 4;   // <-- DELETE THIS LINE to fix the file

Line 1 declares a box, fills it with 3, and glues the lid. Line 2 prints it, which is fine — reading is always allowed. Line 4 tries to re-assign it, and javac stops dead:

Finals.java:9: error: cannot assign a value to final variable MAX_LIVES
        MAX_LIVES = 4;   // <-- DELETE THIS LINE to fix the file
        ^
1 error

The bug never runs, because the program never gets built. That's the whole point of catching things early. By habit, final values get SHOUTY_NAMES with underscores. You can see at a glance that they don't move.

Section 12Names: the rules and the manners

The rules are Java's, and breaking them is an error. A name can use letters, digits, _ and $. It can't start with a digit, so 2fast is out. No spaces, no dashes. It can't be a word Java reserves, like int or class. And it's case-sensitive: score and Score are two different boxes.

The manners are everyone else's. Java people write variable names in camelCase: first word lowercase, later words starting with a capital, no spaces. So viewCount, isGameOver, maxLives. The humps are the camel.

One piece of advice that outlasts this chapter: name the thing, not the type. secondsLeft tells the next reader something. x and myInt don't tell them anything. That reader is usually you, in three weeks.

Section 13Check yourself

Three questions, and everything you need is on this page. The first two ask for a judgment rather than a fact, so say your reason out loud before you click. Every option tells you why it's right or wrong, including the ones you didn't pick.

Section 14What broke, and what surprised you

You've met three error messages in this chapter and two silent wrong answers. The silent ones are the dangerous kind, so it's worth writing down which one got you.

Somewhere you can find again, jot down which predictions you got wrong and what you expected instead. Add any error message you hit that isn't on this page, copied exactly. Did your machine print something different from the outputs here? That mismatch is worth keeping. Every output above came from running the files in src/ on JDK 17.

The idea to carry forward is small. A value in Java always sits in a box of a fixed size. The box shapes what you get back. Next we stop storing values and start making decisions with them. And ==, the double equals we skipped, finally earns its keep.