Java 17 se 21 tak — AI developers ke liye kya naya hai

Java 21 ka har feature yaad karne ki zaroorat nahi hai. Lekin paanch cheezein aisi hain jo AI code likhne ka tareeka hi badal deti hain — aur wahi paanch Spring AI aur LangChain4j ki documentation mein baar-baar dikhti hain. Baaki sab abhi chhod dijiye.

Records — data class ka one-line version#

Purane Java mein ek chhota sa data holder banane ke liye field, constructor, getter, equals, hashCode aur toString — sab haath se likhna padta tha. Record mein ye sab ek line mein aa jaata hai:

public record Recipe(String name, List<String> ingredients, int prepMinutes) {}

Bas. Constructor bhi mil gaya, getters bhi (recipe.name()), equals bhi, aur object immutable bhi hai — banane ke baad koi field badal nahi sakta.

Ab iska AI wala fayda dekhiye. Model se aap chahte hain ki wo JSON de, aur wo JSON aapke object mein seedha ban jaaye:

Recipe recipe = chatClient.prompt()
    .user("Give me a simple paneer recipe")
    .call()
    .entity(Recipe.class);

Spring AI ne is record ko dekha, usse ek JSON schema banaya, wo schema model ko bheja, aur jawab ko wapas Recipe mein deserialise kar diya. Aapne ek bhi line parsing ki nahi likhi. LangChain4j mein bhi bilkul yahi hota hai. Isliye AI projects mein record ek "nice to have" nahi, roz ka tool hai.

Text blocks — prompt likhne ka insaani tareeka#

Prompt lambe hote hain. Purane tareeke mein wo aise dikhte the:

String prompt = "You are a helpful assistant.\n" +
    "Answer only from the context below.\n" +
    "If the answer is not in the context, say you do not know.\n";

Text block ke saath wahi prompt bilkul waisa hi dikhta hai jaisa aap use padhna chahte hain:

String prompt = """
    You are a helpful assistant.
    Answer only from the context below.
    If the answer is not in the context, say you do not know.
    """;

Fayda sirf sundarta ka nahi hai. Prompt ek aisi cheez hai jise aap baar-baar tweak karenge — ek line hataenge, ek jodenge. Jab wo + aur \n mein bandha ho, tab har chhota badlav ek chance hai galti ka. Text block mein aap wahi likhte ho jo model padhega.

Pattern matching — cast ka jhanjhat khatam#

Pehle har instanceof ke baad ek cast likhna padta tha:

if (response instanceof ToolCall) {
    ToolCall call = (ToolCall) response;
    execute(call.name(), call.arguments());
}

Ab check aur variable ek saath aa jaate hain:

if (response instanceof ToolCall call) {
    execute(call.name(), call.arguments());
}

Aur switch ke saath ye aur useful ho jaata hai — agent ke jawab ko handle karna ekdum saaf dikhta hai:

String reply = switch (response) {
    case TextAnswer text  -> text.content();
    case ToolCall call    -> execute(call.name(), call.arguments());
    case Refusal refusal  -> "Model refused: " + refusal.reason();
};

Agent code mein har turn par yahi sawaal hota hai — "model ne text bola, tool maanga, ya mana kar diya?" Ye switch us sawaal ka seedha jawab hai.

Sealed classes — compiler se madad lene ka tareeka#

Upar wale switch mein ek dikkat hai: kal koi banda ImageAnswer naam ka naya response type jod dega aur switch chup-chaap toot jaayega. Sealed class isi ko rokti hai:

public sealed interface AgentResponse
    permits TextAnswer, ToolCall, Refusal {}

Ab compiler ko pata hai ki AgentResponse ke sirf teen roop hain. Aap default case likhna bhool bhi jaayein to koi dikkat nahi — aur agar kal chautha type add hota hai, to har wo switch jo use handle nahi karta, compile hi nahi hoga. Runtime par pata chalne se behtar hai ki build par pata chal jaaye.

Record aur sealed interface saath mein milkar ek aisa domain model dete hain jo bilkul waise hi padha jaata hai jaise aap whiteboard par likhte: "response ya to text hai, ya tool call, ya refusal."

Virtual threads — asli game changer#

Ye samajhna sabse zaroori hai, kyunki AI workload ka shape hi alag hai.

Ek normal REST endpoint 20 millisecond mein DB se data leke jawab de deta hai. Ek LLM call 2 se 20 second leti hai, aur us poore time mein aapka CPU kuch nahi kar raha — sirf network se jawab ka intezaar hai. Purane model mein har request ek OS thread pakde rehti thi, aur OS threads mehenge hain. 200 concurrent AI requests par aapka thread pool khatam, aur service baith gayi.

Virtual thread JVM ka apna thread hai. Jab wo block hota hai, JVM use park kar deta hai aur OS thread kisi aur kaam par lag jaata hai. Spring Boot 3.2+ mein isko on karna ek line ka kaam hai:

spring.threads.virtual.enabled=true

Aur agar aapko khud kaam parallel karna hai, to aise:

try (var scope = Executors.newVirtualThreadPerTaskExecutor()) {
    var summary  = scope.submit(() -> chatClient.prompt().user(summarize).call().content());
    var keywords = scope.submit(() -> chatClient.prompt().user(extract).call().content());
    combine(summary.get(), keywords.get());
}

Dono model calls ek saath ja rahi hain, code bilkul blocking style mein likha hai, aur koi CompletableFuture ki chaining nahi karni padi.

To 17 lein ya 21?#

Seedha jawab: naya project ho to 21.

• Java 17 minimum hai — Spring Boot 3.x isse neeche chalta hi nahi.
• Java 21 bhi LTS hai, matlab lambe time tak support milega.
• Virtual threads 21 mein final hain; 17 mein hain hi nahi.
• switch ka pattern matching 21 mein poora hai, 17 mein preview tha.

Agar aap kisi purane project par kaam kar rahe hain jo 17 par atka hai, tension mat lijiye — records, text blocks aur instanceof pattern matching wahan bhi mil jaate hain. Sirf virtual threads ke liye 21 chahiye.

Aage kya#

Ye paanch features hi wo base hain jinke upar aage ka saara AI code khada hoga. Isse aage ka natural kadam functional Java hai — stream aur CompletableFuture ke saath document pipeline aur concurrent model calls likhna.