The Java switch nuance that gave me an "oh wow" moment

While preparing for the OCA 808 exam (the Java SE 8 certification exam), I have been revisiting Java fundamentals. Not just the syntax I use daily, but the rules that define how the language actually behaves. Along the way, a switch workshop on pattern matching by Venkat Subramaniam made the topic even more engaging.

One detail that stood out early on is that Java’s switch statement only supports a limited set of data types.

• Integer primitives: byte, short, char, int
• enum
• String

That limitation alone hints that switch behaves very differently from something like if-else.

As I looked more closely at the language rules, I ran into a subtle nuance that rarely shows up in everyday code.

In most real-world examples, default appears at the end of a switch and is paired with a break. Because we see it written this way so consistently, it is easy to internalize default as a simple fallback, almost like an else. Over time, it can even start to feel like something that always runs, similar to finally.

That assumption turns out to be wrong.

A closer look at default in Java switch

In Java, default is a reserved keyword, but that does not give it special control-flow behavior inside a switch. What causes confusion is not how the language works, but how we usually write our code.

Inside a switch, default is just a label. It marks a possible entry point. If no other case matches, execution may begin there. Once execution starts, the rules are exactly the same as for any other case.

Here is a simple example.

int x = 10;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
}

When this code runs, the output is:

Default
One

Because there is no break, execution begins at default and then falls through into case 1.

The important detail here is that default does not control execution.
It only controls where execution starts.

• It does not stop execution.
• It does not have to appear last.
• It does not guarantee that it will run.

Why this feels counterintuitive

The confusion comes from mixing mental models.

• With if-else, conditions are evaluated top to bottom.
• With finally, execution is guaranteed.
• A switch works differently.

A switch does not execute cases in order. It decides where to start, then executes code forward from that point.

Once I stopped thinking of switch as a sequence and started thinking of it as a jump, things clicked.

A note about common explanations

Many explanations describe switch as working sequentially by evaluating cases from top to bottom until a match is found. This model is very common, especially in beginner-friendly resources and search results.

That explanation is useful for predicting behavior, but it is not describing how Java implements switch at runtime.

At the source-code level, switch reads as if cases are checked in order. At the JVM level, however, selection is implemented as a direct jump. The JVM does not compare the switch value against each case one by one.

Both descriptions explain the same observable behavior, but they operate at different levels of abstraction.

If switch were implemented by evaluating cases sequentially, placing default at the top would cause a serious problem. Since default is the widest match, execution would always begin there, and more specific cases would never be reached. In that model, default would almost certainly need to appear last.

Thankfully, that is not how Java works.

During the selection phase, Java does not evaluate default as a condition at all. Instead, the JVM first determines whether any specific case matches the switch value. If a match is found, execution jumps directly to that case, even if default appears earlier in the source code. Only when no case matches does the JVM select default as the entry point, regardless of its position.

Once execution begins at the selected label, normal fall-through rules apply. If there is no break or return, execution continues into subsequent cases. To prevent fall-through, break is commonly used, but return is also a valid alternative when exiting the method is the desired behavior.

This behavior only makes sense when switch selection is treated as a jump decision rather than a sequential check.

Selection and execution

A switch has two distinct phases.

Selection phase

• The switch expression is evaluated once.
• Java decides which label to jump to.
• This will be either a matching case or default.
• No code runs during this phase.
• Source order does not matter.

Execution phase

• Java jumps to the selected label.
• Statements execute top to bottom.
• Output is produced.
• Fall-through can happen.
• Execution continues until a break, return, or the end of the switch.

Selection decides where execution starts.

Execution decides what actually runs.

Here is an example that makes this distinction clear.

int x = 1;

switch (x) {
    case 1:
        System.out.println("One");
    case 2:
        System.out.println("Two");
        break;
    default:
        System.out.println("Default");
}

The output is:

One
Two

Only one entry point was selected, but multiple lines were executed.

Placing default at the top

To make this even clearer, consider default placed at the top.

int x = 1;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
        break;
    case 2:
        System.out.println("Two");
        break;
}

The output is:

One

Even though default appears first, execution does not start there. Selection chooses case 1, and execution begins at that label.

Now remove the break.

int x = 3;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
    case 2:
        System.out.println("Two");
}

The output is:

Default
One
Two

This shows that default behaves exactly like any other case once execution begins.

How Java selects a case internally

Under the hood, Java does not check cases one by one at runtime. The compiler transforms a switch into a structure that allows the JVM to jump directly to the correct label.

When case values are close together, the compiler uses a jump table.

• Example values: 1, 2, 3, 4
• The switch value is converted into an index.
• The JVM jumps directly to the corresponding label.
• This runs in constant time.

When case values are sparse, the compiler uses a lookup table.

• Example values: 1, 100, 10000
• Values are mapped to jump targets.
• This avoids wasting space.
• Lookup is optimized and effectively constant time for typical switches.

In both cases:

• Selection happens before execution.
• default is just a fallback jump target.
• Source order does not affect selection.

Observing selection using the command line

You cannot step through switch selection logic in a normal debugger, because that decision happens before any Java statements execute. To see it clearly, you need to inspect the compiled bytecode.

I compiled the code from the command line and inspected it using javap.

javac -d . SwitchStatement.java
javap -c -classpath . org.example.test.oca.SwitchStatement

A simplified snippet from the output looks like this:

lookupswitch {
  1: 36
  2: 44
  default: 28
}

The numbers 36, 44, and 28 are bytecode instruction offsets. They mark the exact instruction where execution begins for each case.

• If the value is 1, execution jumps to offset 36
• If the value is 2, execution jumps to offset 44
• If no case matches, execution jumps to 28, the start of default

Reading the bytecode like an insider

While reading the javap output, I kept seeing instructions like getstatic, ldc, and invokevirtual. At first glance, these look cryptic, but they map very directly to familiar Java statements.

For example:

28: getstatic
31: ldc "Default"
33: invokevirtual println

This corresponds to:

System.out.println("Default");

Under the hood:

• getstatic retrieves the System.out reference
• ldc loads a constant value from the constant pool
• invokevirtual calls the println method

The instruction that caught my attention was ldc. It is easy to misread it as “idc” (I don’t care), but it actually means load constant. String literals and other constants live in the class’s constant pool, and ldc pushes the correct value onto the operand stack so the next instruction can use it.

Once you understand this, the bytecode stops feeling mysterious. It becomes a very explicit, step-by-step description of how the JVM executes the code you wrote.

A brief note on modern switch features

Switch expressions first appeared as a preview in Java 12, were refined in Java 13, and became official in Java 14. Later, switch was extended with pattern matching, allowing switches to match on object types rather than only constant values.

Classic value-based switch:

String input = "hello";

switch (input) {
    case "hello":
        System.out.println("Greeting");
        break;
    default:
        System.out.println("Unknown");
}

Output:

Greeting

Pattern matching switch:

Object obj = 42;

switch (obj) {
    case Integer i -> System.out.println("Integer: " + i);
    case String s  -> System.out.println("String: " + s);
    default        -> System.out.println("Something else");
}

Output:

Integer: 42

Best practices around switch, such as placing default at the end and using break, are still the right approach in production code. What helped me was understanding what the language is doing underneath those conventions. Seeing the clear separation between selection and execution made those best practices feel intentional rather than arbitrary.

If you have had a similar moment where understanding a small internal detail reshaped how you think about a familiar construct, I would love to hear it.