🧩

Java 17

Java 17 Features

Records, Sealed Classes & Pattern Matching

💡 Java 17 एक नए घर का smart blueprint जैसा है — Records एक ready-made furniture kit है (बिना खुद जोड़-तोड़ किए सीधा use करो), Sealed Classes एक building society का rule है ("सिर्फ ये specific घर type बन सकते हैं, और कोई नहीं"), और Pattern Matching एक smart lock है जो check करने के साथ-साथ खुद ही सही चाबी भी पकड़ा देता है।

Java 17 (September 2021) दूसरी major LTS (Long-Term Support) release है Java 11 के बाद — बहुत companies इसी version पर migrate करती हैं क्योंकि इसमें कई साल के improvements एक साथ आते हैं (Java 12 से 17 तक के सारे features)।

सबसे बड़े highlights: Records (data classes एक line में), Sealed Classes (controlled inheritance), Pattern Matching for instanceof (auto-casting), Text Blocks (multi-line strings आसानी से), और Switch Expressions।

Interview में Java 17 के features बहुत common हैं, especially Records और Sealed Classes — क्योंकि ये modern Java code लिखने का तरीका बदल देते हैं, boilerplate कम करते हैं।

// Record — ek line mein data class
record User(String name, int age) {}
User u = new User("Aarav", 25);
System.out.println(u); // User[name=Aarav, age=25]

// Pattern Matching for instanceof
Object obj = "Hello";
if (obj instanceof String s) {
  System.out.println(s.length()); // seedha use, cast nahi chahiye
}

🧩

Java 17 एक नए घर का smart blueprint जैसा है — Records एक ready-made furniture kit है (बिना खुद जोड़-तोड़ किए सीधा use करो), Sealed Classes एक building society का rule है ("सिर्फ ये specific घर type बन सकते हैं, और कोई नहीं"), और Pattern Matching एक smart lock है जो check करने के साथ-साथ खुद ही सही चाबी भी पकड़ा देता है।

1 / 6

⚡ झट से Recap

Java 17 = LTS release (Sept 2021)
Records = data classes एक line में
Sealed Classes = controlled inheritance
Pattern Matching for instanceof = auto-cast
Text Blocks = multi-line strings आसानी से

इस page में (8 subtopics)

Normal class में एक simple data-holder (जैसे Point जिसमें सिर्फ x और y हों) बनाने के लिए काफी boilerplate लिखना पड़ता है — constructor, getters, equals(), hashCode(), toString() सब manually (या IDE से generate करके)। record keyword यह सब automatically generate कर देता है एक line में।

record Point(int x, int y) {} लिखने से compiler खुद बनाता है: एक constructor (दोनों fields set करने वाला), getter methods (x() और y() — बिना "get" prefix के), और properly implemented equals(), hashCode(), toString()। Records implicitly final हैं (extend नहीं हो सकते) और उनके fields भी implicitly final हैं (immutable)।

Records तब best हैं जब तुम्हें सिर्फ data carry करना हो, कोई complex behavior नहीं — जैसे API responses, DTOs (Data Transfer Objects), या coordinate pairs। अगर class में methods/logic भी चाहिए (सिर्फ data नहीं), normal class ही better रहेगी।

Interview में पूछा जा सकता है records और Lombok के @Data annotation में फ़र्क — Lombok एक third-party library है जो compile-time code generate करती है (annotation processing), जबकि records एक native language feature है, कोई extra dependency नहीं चाहिए।

Constructor — दोनों fields set करने वाला, automatically
Getters — x() और y(), बिना "get" prefix के
equals() / hashCode() — values compare करते हैं, properly implemented
toString() — readable format, जैसे Point[x=3, y=4]

record Point(int x, int y) {}

Point p1 = new Point(3, 4);
System.out.println(p1.x());       // 3 (getter, "get" prefix nahi)
System.out.println(p1);           // Point[x=3, y=4] (auto toString)

Point p2 = new Point(3, 4);
System.out.println(p1.equals(p2)); // true (auto equals, values compare hote hain)

💡Tip: Record में custom validation भी डाल सकते हो "compact constructor" से — record Point(int x, int y) { Point { if (x < 0) throw new IllegalArgumentException("x negative नहीं हो सकता"); } }

Normal class/interface को कोई भी extend/implement कर सकता है — sealed keyword से तुम control करते हो *exactly* कौन-कौन extend/implement कर सकता है। यह especially useful है जब तुम्हें पता हो कि सब possible subtypes क्या हैं (जैसे Shape सिर्फ Circle, Square, Triangle हो सकता है, और कुछ नहीं)।

sealed class Shape permits Circle, Square, Triangle {} लिखने से सिर्फ ये तीन classes ही Shape extend कर सकती हैं — कोई बाहर का code नया subtype नहीं बना सकता। हर permitted subclass को explicitly declare करना पड़ता है: final (आगे extend नहीं हो सकती), sealed (खुद आगे control करती है), या non-sealed (वापस normal, कुछ भी extend कर सकता है)।

फ़ायदा: switch statements में compiler को पता होता है सारे possible types क्या हैं, इसलिए "exhaustiveness checking" possible होता है (अगला subtopic में pattern matching के साथ देखेंगे) — बिना default case के भी compiler confirm कर सकता है सारे cases cover हो गए।

Real-world use-case: API response modeling में sealed classes बहुत useful हैं — जैसे ApiResult सिर्फ Success या Failure हो सकता है, और कुछ नहीं। यह pattern functional languages (जैसे Kotlin के sealed classes) से inspire हुआ है।

final — permitted subclass आगे extend नहीं हो सकती
sealed — permitted subclass खुद आगे control करती है
non-sealed — वापस normal, कुछ भी extend कर सकता है

sealed interface Shape permits Circle, Square, Triangle {}

final class Circle implements Shape { double radius; }
final class Square implements Shape { double side; }
final class Triangle implements Shape { double base, height; }

// Koi doosri class Shape implement NAHI kar sakti — compiler error dega

⚠️Common Mistake: Sealed hierarchy की सारी permitted classes (अगर अलग files में हों) उसी module/package में होनी चाहिए जहाँ sealed type define हुआ है — यह एक compiler-enforced rule है।

पुराने Java में instanceof check करने के बाद manually cast करना पड़ता था — दो steps, थोड़ा repetitive: if (obj instanceof String) { String s = (String) obj; ... }। Java 16+ (17 में stable) में instanceof खुद एक variable "bind" कर देता है अगर check pass हो जाए।

if (obj instanceof String s) लिखने से, अगर obj String है, तो s automatically उस cast-किए-हुए value को point करता है — उस if block के अंदर सीधा s use कर सकते हो, manual cast की ज़रूरत नहीं। यह code को छोटा और safer बनाता है (ClassCastException का risk कम होता है क्योंकि compiler खुद type-check करता है)।

Chained conditions में भी काम आता है — if (obj instanceof String s && s.length() > 5) जैसा लिख सकते हो, जहाँ pattern variable s तुरंत next condition में भी use हो जाता है।

Object obj = "Hello Java 17";

// Purana tareeka:
if (obj instanceof String) {
  String s = (String) obj;
  System.out.println(s.length());
}

// Java 16+ pattern matching:
if (obj instanceof String s) {
  System.out.println(s.length()); // s seedha use ho sakta hai, cast nahi chahiye
}

Multi-line String (जैसे JSON, HTML, SQL query) लिखना पुराने Java में बहुत messy था — हर line के end में \n, quotes escape करना, + से concatenate करना। Text block (""" से शुरू और खत्म होके) इस सब को खत्म कर देता है।

Text block automatically leading whitespace को "smart" तरीके से strip करता है (सारी lines का common indentation हटा देता है), line breaks को \n में convert कर देता है, और quotes को escape करने की ज़रूरत नहीं (सिर्फ edge cases में)।

SQL queries, JSON payloads, या HTML templates लिखते वक्त text blocks code review में भी easier हो जाते हैं — reviewer को पूरा structure एक साथ दिखता है, string concatenation के टूटे-फूटे pieces नहीं।

Common leading whitespace automatically strip होता है
Line breaks खुद \n में convert हो जाते हैं
Quotes escape करने की ज़रूरत नहीं (सिर्फ edge cases में)

// Purana tareeka:
String json1 = "{\n" +
    "  \"name\": \"Aarav\",\n" +
    "  \"age\": 25\n" +
    "}";

// Text block (Java 15+):
String json2 = """
    {
      "name": "Aarav",
      "age": 25
    }
    """;

💡Tip: Text block के closing """ की position matter करती है — यह decide करता है कितना leading whitespace common माना जाएगा और strip होगा। Closing """ को सबसे कम-indented line से भी पीछे रखोगे तो extra indentation preserve हो जाएगा।

Switch Expression (Java 14+, stable) पुराने switch statement से छोटा और safer है — arrow syntax (case X -> result) use करता है, fall-through नहीं होता (हर case के end में break नहीं चाहिए), और एक value "return" भी कर सकता है (assignment में directly use करने लायक)।

Java 17 में Pattern Matching for switch preview feature के रूप में आया (बाद की versions में stable हुआ) — अब switch में type के basis पर भी branch कर सकते हो, instanceof जैसा ही pattern binding के साथ: case Integer i -> ..., case String s -> ...।

Multiple case labels एक साथ भी लिख सकते हो comma से — case 1, 2, 3 -> "Weekday"; — जो पुराने switch statement में भी possible था, लेकिन अब arrow syntax के साथ और भी clean लगता है।

// Purana switch statement:
int day = 3;
String name;
switch (day) {
  case 1: name = "Monday"; break;
  case 2: name = "Tuesday"; break;
  default: name = "Other";
}

// Switch Expression (Java 14+):
String name2 = switch (day) {
  case 1 -> "Monday";
  case 2 -> "Tuesday";
  default -> "Other";
};

// Pattern Matching for switch (preview, Java 17):
Object obj = 42;
String result = switch (obj) {
  case Integer i -> "Integer: " + i;
  case String s -> "String: " + s;
  default -> "Unknown";
};

पुराना java.util.Random एक ही algorithm use करता था, और नए/बेहतर random algorithms add करना मुश्किल था (सब कुछ Random class में ही hardcoded था)। Java 17 ने RandomGenerator interface दिया जो सारे random number generators (नए पुराने) के लिए एक common API देता है।

नए algorithms भी आए — जैसे Xoshiro256PlusPlus, जो पुराने Random से better statistical quality और performance देते हैं, especially parallel/multi-threaded use के लिए (जैसे SplittableRandom जो अलग-अलग threads को independent streams दे सकता है बिना lock overhead के)।

Interview में ज़्यादा deep detail expected नहीं है इस topic पर — बस इतना पता होना चाहिए कि RandomGenerator एक नया common interface है, और SecureRandom (cryptographically strong random numbers के लिए) इस hierarchy से अलग, security-sensitive cases के लिए use होता है।

RandomGenerator rng = RandomGenerator.of("Xoshiro256PlusPlus");
System.out.println(rng.nextInt(100)); // 0-99 ke beech ek random number

// Streams of random numbers bhi easily ban sakte hain:
rng.ints(5, 1, 10).forEach(System.out::println); // 5 numbers, 1-9 ke beech

Java 9 में module system (JPMS) आया था, लेकिन backward compatibility के लिए internal JDK APIs (जैसे sun.misc.Unsafe) तब भी --illegal-access flag से access हो सकते थे। Java 17 से ये internals strongly encapsulate हो गए — by default access नहीं हो सकते, चाहे कुछ भी flag use करो (सिर्फ critical ones के लिए --add-opens explicitly देना पड़ता है)।

यह application code के लिए directly कम relevant है, लेकिन अगर तुम्हारी कोई library/framework internal JDK classes use करती थी (reflection से), Java 17 upgrade करते वक्त यह break हो सकता है — इसीलिए migration guides में यह एक common gotcha है।

यह change specifically उन libraries को affect करता है जो "unsafe" internal APIs use करके performance optimize करती थीं (जैसे कुछ पुराने ORM frameworks) — modern libraries already migrate हो चुकी हैं, लेकिन legacy codebases upgrade करते वक्त इस issue से टकरा सकते हैं।

Security Manager एक पुराना mechanism था जो Java applications को sandbox में चलाने देता था (जैसे browser applets के लिए) — restrict करता था कि code क्या कर सकता है (file access, network, etc.)। Modern applications इसको rarely use करते हैं (containers/OS-level sandboxing ज़्यादा common हो गया है), और maintain करना JDK team के लिए costly था।

Java 17 में इसे "deprecated for removal" mark किया गया (बाद की versions में completely remove हो गया) — अगर कोई legacy application इसको use करती है, upgrade से पहले warning आएगी, और eventually alternative ढूंढना पड़ेगा।

Alternative approach के रूप में अब container-level isolation (Docker), OS-level sandboxing, या cloud-provider IAM policies use होते हैं — application-level security manager की जगह infrastructure-level security ज़्यादा practical माना जाता है modern deployments में।

⚠️Common Mistake: Interview में अक्सर पूछा जाता है "Java 17 में क्या deprecated हुआ" — Security Manager इसका सबसे common answer है। Applets भी already पहले से deprecated थे।

← पिछला🚀 Java 11 Features अगला →🧵 Java 21 Features

Code10x

Java 17 Features

Records — Concise Data Classes (JEP 395)

Sealed Classes & Interfaces (JEP 409)

Pattern Matching for instanceof (JEP 394)

Text Blocks (JEP 378)

Switch Expressions & Pattern Matching for switch (Preview)

Enhanced Pseudo-Random Number Generators (JEP 356)

Strong Encapsulation of JDK Internals (JEP 403)

Deprecated for Removal: Security Manager (JEP 411)