Pattern Puzzlers 2025 Edition

https://horstmann.com/presentations/2025/jcrete

Slide navigation: Forward with space bar, →, or swipe left. Backwards with ← or swipe right. Switch slides with PgDn and PgUp.

Why Switch?

• Classic switch statement invented in C

  switch (c) {
     case '0': case '1': case '2': case '3': case '4':
     case '5': case '6': case '7': case '8': case '9':
        ndigit[c-'0']++;
        break;
     case ' ':
     case '\n':
     case '\t':
        nwhite++;
        break;
     default:
        nother++;
        break;
  }
  

• Efficient implementation as jump table (“computed GOTO”)
• If constant range is sparse, array of jump addresses
• Otherwise binary search
• A win over if/else if/else if with ≥ 10 cases
• Can’t be efficiently done with any other C construct

Why Pattern Matching?

• Alternative to polymorphism

  public int length(LispyList lst) {
     return switch (lst) {
        case EmptyList _ -> 0;
        case NonEmptyList(_, tail) -> 1 + length(tail);
     }
  }
  

• Keeps logic in one place
• Useful with sealed hierarchies
• Unrelated to jump tables (duh)

The Evolution of switch and instanceof

• Java 1: C style switch on int, short, byte, char
• Java 5: String, enum, Integer, Short, Byte, Character
• Java 14: switch expressions
• Java 16: instanceof patterns
• Java 21: Type and record patterns
• Java 22: _ patterns
• Java 25, in preview: Selector types float, double, long, boolean and their wrappers
• To come: Deconstruction patterns

Features

• Four kinds of switch: Statement/expression, fallthrough/no fallthrough
• Multiple cases: case YELLOW, GREEN
• Type pattern: case Manager m, e instanceof Manager m
• Record pattern: case Point(double x, double y), p instanceof Point(double x, double y)
• Null pattern: case null
• Guards: case Point(double x, double y) when y > 0
• Wildcards: case Point(double x, _)
• No dominance, e.g. case Employee e can’t be above case Manager m
• All switch expressions and “enhanced” switch statements must be exhaustive

Puzzler: Go or No?

• Does this compile?

  enum Color { RED, YELLOW, GREEN };
  boolean go(Color c) {
      switch (c) {
          case RED: return false;
          case YELLOW, GREEN: return true;
      }
  }
  

• “Missing return statement”
• Nothing to do with modern switch—has been so since Java 5
• Someone might have added another enum constant—§ 14.22
• Does this compile?

  Boolean go(Color c) {
      switch (c) {
          case RED: return false;
          case YELLOW, GREEN: return true;
          case Color _: return null;
      }
  }
  

• This switch is exhaustive.
• Does this compile?

  boolean go(Color c) {
      return switch (c) {
          case RED -> false;
          case YELLOW, GREEN -> true;
      };
  }
  

• Yes. The “completion” rule only applies to switch statements.
• Does this compile?

  Boolean go(Color c) {
      switch (c) {
          case RED: return false;
          case YELLOW, GREEN: return true;
          case null: return null;
      }
  }
  

• Yup. case null makes it “enhanced”
• Key notions: expression vs. statement, enhanced

Puzzler: Boxed and Double Boxed

• Which of these switch expressions throw a NullPointerException?

  record Box<T>(T contents) { }
  
  Box<String> boxed = null;
  String unboxed = switch (boxed) { // ❶
     case Box(String s) -> s;
  };
  
  boxed = new Box<>(null);
  String unboxed = switch (boxed) { // ❷
     case Box(String s) -> s;
  };
  
  Box<Box<String>> doubleBoxed = new Box<>(null);
  String unboxed = switch (doubleBoxed) { // ❸
     case Box(Box(String s)) -> s;
  };
  

• ❶ throws NPE
• ❷ returns null
• ❸ throws a MatchError!

Puzzler: Dare To Be Square

• Consider this code:

  sealed interface Shape {}
  record Rect(double x, double y) implements Shape {}
  record Square(double x) implements Shape {}
  
  public List<Shape> dareToBeSquare(List<Shape> shapes) {
      return shapes.stream()
          .map(s -> switch(s) {
              case Rect(int x, _) -> new Square(x);
              default -> s;
          })
          .toList();
  }
  

• Will it
  • Compile?
  • Run without exceptions?
  • Turn all rectangles into squares?
• What about

  public List<Shape> dareToBeSquare(List<Shape> shapes) {
      return shapes.stream()
          .map(s -> switch(s) {
              case Rect(int x, _) -> new Square(x);
              case Square _ -> s;
          })
          .toList();
  }
  

Puzzler: Something Else

• Which of the following are legal switch expressions?

  Object x = ...;
  String result = switch (x) { // ❶
     case "" -> "empty";
     case 0 -> "zero";
     default -> "something else";
  };
  
  enum Size { SMALL, MEDIUM, LARGE, EXTRA_LARGE };
  Object y = ...;
  result = switch (y) { // ❷
     case Size.EXTRA_LARGE -> "extra large";
     default -> "something else";
  };
  

• In ❶, the selector type is Object
• Constant cases (case "", case 0) can’t be used with Object
• ❷ is fine
• Even though Size.EXTRA_LARGE is a constant case
• Special rule for enum to deal with

  sealed interface JSONValue {}
  record JSONNumber(double x) implements JSONValue {}
  enum JSONBoolean { FALSE, TRUE } implements JSONValue {}
  

• Did you note Size.EXTRA_LARGE?

Puzzler: Whatever Floats Your Boat

• What does the program print?

  void main() {
     int count = 0;
     float sum = 0;
     for (int i = 1; i <= 100; i++) {
        if (1.0 / i instanceof float f) {
           count++;
           sum += f;
        }
     }
     IO.println(count + " " + sum);
  }
  

• Fun fact: 1/1 + 1/2 + 1/3 + ... + 1/100 is about 5.187378
• So the output should surely be 100 5.187378
• But not every 1.0 / i is an “instance” of float
• In fact, only seven are: 1, 1/2, 1/4, 1/8, 1/16, 1/32, 1/64
• And their sum is 1.984375

Puzzler: A Bright Future

• Upcoming feature: Deconstruction

  public class Point { // Not a record
       private double x, y;
  
       public Point(double x, double y) {
           this.x = x;
           this.y = y;
       }
  
       public inverse Point(double x, double y) {
           x = this.x;
           y = this.y;
       }
  }

  Suppose the j.u.r.Pattern class is enhanced with this deconstructor:

  public inverse String match(String... groups) {
      Matcher m = matcher(that);    // *that* is the match candidate
      if (m.matches())              // receiver for matcher() is the Pattern
          __yield IntStream.range(1, m.groupCount())
                              .map(m::group)
                              .toArray(String[]::new);
  }
  

  What is the result of

  switch("0:59") {
     case Pattern.of("([0-2][0-9]):([0-9]+)").match(h, m) ->
        60 * Integer.parseInt(h) + Integer.parseInt(m);
     default -> -1;
  }
  

  1. 59
  2. -1
  3. a MatchError is thrown
  4. A compiler error that groups is not used

Enough Already—What's the TL;DR?

• Retrofitting switch and instanceof for pattern matching leverages existing knowledge
• JEP 361: By teasing the desired benefits (expression-ness, better control flow, saner scoping) into orthogonal features, switch expressions and switch statements could have more in common. The greater the divergence between switch expressions and switch statements, the more complex the language is to learn, and the more sharp edges there are for developers to cut themselves on.
• Sharp edges:
  • Fall-through
  • Constant cases vs patterns
  • Primitives and wrappers
  • null
  • default
  • Enhancedness
  • Completion
• Who could have predicted that this gets so complicated?
• In 2018: "This is a self-inflicted injury, solely based on calling both of them switch."