In older Java, List (which has order) and LinkedHashSet/LinkedHashMap (which also have a predictable order) had no common, consistent way to get the "first element" or "last element" — List.get(0) vs List.get(size()-1), or different methods across different collections.

Java 21 introduced three new interfaces: SequencedCollection, SequencedSet, SequencedMap — giving ordered collections like List, LinkedHashSet, and LinkedHashMap common methods: getFirst(), getLast(), addFirst(), addLast(), removeFirst(), removeLast(), and reversed() (which gives a reversed view of the collection, without creating a copy).

A real-world use-case: when you need the "most recent" or "oldest" item in a list (like an activity feed or an undo history), you used to have to do manual index math — now getLast()/getFirst() give you direct, readable code.

• getFirst() / getLast() — grab the first / last element
• addFirst() / addLast() — insert at the start / end
• removeFirst() / removeLast() — remove from the start / end
• reversed() — a reversed view, no copy created

List<String> names = new ArrayList<>(List.of("Aman", "Riya", "Zoya"));
System.out.println(names.getFirst());  // Aman
System.out.println(names.getLast());   // Zoya
names.addFirst("Aarav");
System.out.println(names.reversed());  // [Zoya, Riya, Aman, Aarav]

// LinkedHashMap bhi ab yehi methods deta hai:
LinkedHashMap<String, Integer> scores = new LinkedHashMap<>();
scores.put("A", 90);
scores.putFirst("Z", 100); // naya method — sabse pehle daalta hai

Records arrived in Java 17 for data classes, and instanceof pattern matching arrived in Java 16+. Java 21 combined the two — now you can directly "destructure" the fields inside a record within an instanceof or switch check, without calling record.field().

For example, if you have record Point(int x, int y), writing if (obj instanceof Point(int x, int y)) means that if obj is a Point, x and y are directly available — a record can even contain another record (nested destructuring), which gives very clean code for deeply nested data structures.

An interviewer might combine this with sealed classes — together they give you something like the "algebraic data type" pattern from functional languages, where both the shape of the data and the logic that processes it are explicit and type-safe.

record Point(int x, int y) {}
record Line(Point start, Point end) {}

Object obj = new Point(3, 4);

// Record pattern — seedha destructure
if (obj instanceof Point(int x, int y)) {
  System.out.println("x=" + x + ", y=" + y);
}

// Nested record pattern
Object line = new Line(new Point(0, 0), new Point(3, 4));
if (line instanceof Line(Point(int x1, int y1), Point(int x2, int y2))) {
  System.out.println("Line from (" + x1 + "," + y1 + ") to (" + x2 + "," + y2 + ")");
}

This was a preview feature in Java 17; it finally became stable/final in Java 21. Now a switch expression/statement can combine type-based branching, record destructuring, and guard conditions (a when clause) all together.

null can now be handled directly inside a switch too (case null ->) — previously a switch would throw a NullPointerException on null, forcing a separate null check. A guard condition (when) lets you add an extra condition even inside a type-match, like case Integer i when i > 0 -> ....

The order of guard conditions matters — a switch checks cases top to bottom, so a more specific guarded case (like when i > 0) needs to come before the generic one, otherwise the generic case matches first.

• Type patterns — case Integer i -> ...
• Record patterns — case Point(int x, int y) -> ...
• Guard conditions — case Integer i when i > 0 -> ...
• case null -> — can now be handled directly

Object obj = 42;

String result = switch (obj) {
  case null -> "It's null";
  case Integer i when i > 0 -> "Positive integer: " + i;
  case Integer i -> "Non-positive integer: " + i;
  case String s -> "String: " + s;
  case Point(int x, int y) -> "Point at (" + x + "," + y + ")"; // record pattern bhi
  default -> "Unknown";
};

Both String concatenation (joining with +) and String.format() get a bit clunky for long strings. String Templates bring a new syntax — something like STR."Hello \{name}!" — where you put Java expressions directly inside \{...}, and they get automatically evaluated and embedded into the result.

This is a preview feature in Java 21 (meaning you need the --enable-preview flag to compile/run it, and it might still change in future versions) — but it shows where Java is taking string handling: readable, type-safe, and it opens the door to custom template processors (like a SQL processor) that can easily prevent things like SQL injection too.

An interviewer might ask what STR actually is — it's a built-in "template processor" (implementing the StringTemplate.Processor interface). Developers can build their own processors too, like one that automatically HTML-escapes to prevent XSS.

String name = "Aarav";
int age = 25;

// Purana tareeka:
String s1 = "Hello " + name + ", you are " + age + " years old";
String s2 = String.format("Hello %s, you are %d years old", name, age);

// String Template (preview, Java 21):
String s3 = STR."Hello \{name}, you are \{age} years old";
// Expressions bhi chal sakti hain:
String s4 = STR."Next year you'll be \{age + 1}";

When completing a task requires running multiple sub-tasks in parallel (like fetching a user's profile, price, and inventory from different services), managing them manually — cancel the rest if one fails, wait for all, handle errors — gets error-prone fast.

StructuredTaskScope treats sub-tasks in a "structured" way — the parent task doesn't finish until every child task it started has finished, and if one child fails, the whole group can automatically get cancelled (fail-fast). Combined with virtual threads, this makes concurrent code much safer and more readable.

This is far more readable than traditional manual thread management with try-catch-finally — in the old way, if one task failed you had to manually cancel the others and risk thread leaks; StructuredTaskScope handles all of this automatically.

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
  Future<String> user = scope.fork(() -> fetchUser());
  Future<String> orders = scope.fork(() -> fetchOrders());

  scope.join();           // dono ka wait karo
  scope.throwIfFailed();  // agar koi fail hua, exception throw karo

  System.out.println(user.resultNow() + orders.resultNow());
} // scope band hote hi saare threads cleanup ho jaate hain

In Java 17, ZGC (the Z Garbage Collector) was experimental, designed for low latency (pause times consistently under 10ms) — but it wasn't "generational", meaning it didn't treat young and old objects differently, which reduced efficiency for some workloads.

In Java 21, ZGC became "generational" (like other modern GCs such as G1) — it collects the young generation (where most objects "die" quickly) more often and more efficiently, and collects the old generation less often. This improved both throughput and memory efficiency, without losing the low-latency guarantee.

An interviewer might ask why generational ZGC was even needed if G1 was already generational — the answer: G1 being generational didn't give it ZGC's ultra-low pause times; Generational ZGC delivers both low pause time AND generational efficiency together.

Sometimes you have to declare a variable you don't actually use (like catch (Exception e) where e is never used, or a record pattern where you only need some fields, not all). In the Java 21 preview, you can use an underscore (_) as an "unnamed variable" — signaling this value is being intentionally ignored.

This is useful with record patterns too — say Point(int x, int y) and you only need x, you can write case Point(int x, var _), explicitly saying "I don't care about y", which gives readers of the code more clarity.

This feature especially helps in large codebases where static analysis tools (like SonarQube) flag "unused variable" warnings — using an underscore (_) explicitly signals the value is intentionally ignored, and clears up the warning too.

// catch block mein unused exception:
try {
  riskyOperation();
} catch (IOException _) {
  System.out.println("Kuch to gaya galat, details ki zaroorat nahi");
}

// Record pattern mein sirf zaroori field:
if (obj instanceof Point(int x, var _)) {
  System.out.println("x = " + x + " (y ignore kiya)");
}