Migration Guide 3.25.10 to 3.26.0

3.25.10 to 3.26.0 Migration Guide

JavaParser version 3.26.0 brings in support for java 21 features that required changes to switch entries and pattern expressions.

Switch pattern matching

In JavaParser versions before 3.26.0, pattern matching was limited to instanceof expressions, but from JavaParser 3.26.0 onwards, patterns are also supported as labels in switch expression entries, for example

switch (o) {
  case String s -> ...
}

Since switch entry labels are are already of type Expression, no API changes were made to support this, but it is mentioned here as it is used in some of the examples below.

SwitchEntry isDefault field

In Java 21, it is possible to have a combined null and default case for switch expressions, for example:

switch (o) {
  case String s -> ...
  case null, default -> ...
}

This means that checking for an empty label list in a SwitchEntry of a switch expression is no longer sufficient to determine whether an entry is the default or not. A new isDefault field was therefore added so, from JavaParser 3.26.0 onwards, switchEntry.isDefault() should be used to determine whether an entry is the default case.

PatternExpr changes

In JavaParser versions up to and including 3.25.10, the PatternExpr node was used to represent type pattern expressions of the form

input instanceof String s

but Java 21 added support for record patterns which can be used to pattern match on fields of records, for example

input instanceof Box(String s)

In JavaParser 3.26.0, there are 2 new pattern nodes: TypePatternExpr and RecordPatternExpr. TypePatternExpr is used to represent type pattern expressions and is therefore identical to PatternExpr from JavaParser 3.25.10. RecordPatternExpr is used to represent the new record pattern expression. PatternExpr has been repurposed and is now a common base class for TypePatternExpr and RecordPatternExpr

This means that, when upgrading, everywhere PatternExpr was being handled with JavaParser < 3.26.0, there are now 2 cases which must be handled separately. If the PatternExpr is a TypePatternExpr, then it should be handled the same as the old PatternExpr, except with a new name. Only the RecordPatternExpr case is brand new.