Java 25 / JDK 25 आधिकारिक रूप से जारी

• Java 25 और इसका रेफ़रेंस इम्प्लीमेंटेशन JDK 25 आधिकारिक रूप से जारी कर दिया गया है
• इस संस्करण में नई 18 JEP (Java Enhancement Proposal) सुविधाएँ शामिल हैं
• x86 32-बिट पोर्ट हटाना, Scoped Values, Structured Concurrency, Primitive Types में सुधार जैसे प्रमुख बदलाव लागू किए गए हैं

---

Java 25 / JDK 25: आधिकारिक रिलीज़

• JDK 25, यानी Java 25 का रेफ़रेंस इम्प्लीमेंटेशन, आधिकारिक रूप से प्रोडक्शन डिस्ट्रीब्यूशन संस्करण के रूप में जारी किया गया है
• 15 अगस्त 2025 को दूसरा रिलीज़ कैंडिडेट build 36 उपलब्ध कराया गया था, और उसके बाद कोई गंभीर (P1) बग रिपोर्ट नहीं हुई
• build 36 अंतिम GA(General Availability) संस्करण है, और इसे ऑपरेटिंग एनवायरनमेंट में भी इस्तेमाल किया जा सकता है

• GPL लाइसेंस आधारित OpenJDK बिल्ड Oracle द्वारा आधिकारिक रूप से उपलब्ध कराया जा रहा है, और अन्य कई वेंडरों के बिल्ड संस्करण भी जल्द वितरित किए जाएंगे

OpenJDK आधिकारिक डाउनलोड लिंक

प्रमुख सुविधाएँ और सुधार

इस रिलीज़ में 18 JEP (Java Enhancement Proposal) शामिल हैं

• 470: PEM-आधारित क्रिप्टोग्राफिक ऑब्जेक्ट एन्कोडिंग (प्रीव्यू)
• 502: Stable Values (प्रीव्यू)
• 503: x86 32-बिट पोर्ट हटाना
• 505: Structured Concurrency (5वाँ प्रीव्यू)
• 506: Scoped Values
• 507: pattern, instanceof, switch में Primitive Types समर्थन (3रा प्रीव्यू)
• 508: Vector API (10वाँ incubator version)
• 509: JFR CPU टाइम प्रोफाइलिंग (प्रयोगात्मक सुविधा)
• 510: Key Derivation Function API
• 511: Module Import declarations
• 512: Compact Source Files और instance main methods
• 513: Flexible Constructor Bodies
• 514: Ahead-of-Time कमांडलाइन ऑप्टिमाइज़ेशन
• 515: Ahead-of-Time मेथड प्रोफाइलिंग
• 518: JFR cooperative sampling
• 519: Compact Object Headers
• 520: JFR method timing और tracing
• 521: Generational Shenandoah

इस रिलीज़ में ऊपर दिए गए JEP के अलावा सैकड़ों छोटे फीचर सुधार और हज़ारों बग फ़िक्स भी शामिल किए गए हैं

रिलीज़ की विस्तृत जानकारी और JEP के विवरण
OpenJDK JDK 25 प्रोजेक्ट पेज पर देखे जा सकते हैं

[ahwjdekf]

पिछले साल वाला यही तमाशबीन मरा भी नहीं और फिर आ गया, अरे वाह अब शुरू होता है... तू बार-बार क्यों निकल आता है?

[click]

यह फ़ीचर JDK24 में आया था, लेकिन क्योंकि Java में केवल LTS का इस्तेमाल करने की प्रवृत्ति काफ़ी मजबूत है, इसलिए JEP 491: Synchronize Virtual Threads without Pinning के ज़रिए synchronized कीवर्ड इस्तेमाल करते समय virtual thread pinning की समस्या खत्म हो गई है—यह भी ध्यान देने लायक है.
अक्सर virtual thread के real-world benchmark धीमे निकलते थे, और ज़्यादातर मामलों में इसकी वजह pinning ही होती थी.

[GN⁺]

Hacker News की राय

• मेरा मानना है कि और नए प्रोग्राम Java या JVM पर लिखे जाने चाहिए, अतीत में Java की लोकप्रियता घटने के जो कारण थे वे अब लगभग खत्म हो चुके हैं, और अब इसका ecosystem बहुत स्थिर और परिपक्व है। 10 साल पहले लिखा गया Clojure प्रोग्राम भी बिना किसी समस्या के बढ़िया चलता है, जबकि TypeScript में लिखा प्रोग्राम 6 महीने में ही maintenance और update मांगने लगता है।
  • Oracle को लेकर चिंता सबसे बड़ी बात है। Java इस्तेमाल करते समय Oracle की EULA का उल्लंघन न हो, इसका ध्यान रखना असुविधाजनक है। OpenJDK इस्तेमाल करें तो शायद ठीक हो, लेकिन बेहतर यही लगता है कि बिना चिंता किसी दूसरी भाषा का उपयोग किया जाए। C# भी Java जैसा ही माहौल देता है और Oracle की चिंता भी नहीं रहती। Java को सुरक्षित ढंग से इस्तेमाल करना सीखने से बेहतर है कि बस कोई दूसरी भाषा चुन ली जाए। वैसे भी Java कोई अनिवार्य विकल्प नहीं है, और विकल्प बहुत हैं।
  • बड़े backend systems में Java अब भी बेहद लोकप्रिय है और व्यापक रूप से इस्तेमाल होता है। मुझे हैरानी है कि यहाँ ऐसे सिस्टम संभालने वाले लोग कम दिखते हैं। मेरे अनुभव में Java से सामना लगभग हर जगह होता है।
  • मैं चुपचाप उम्मीद कर रहा हूँ कि Kotlin और Compose JVM पर desktop apps को फिर से जीवित कर दें।
  • adoption rate के लिहाज़ से Java के लिए लगातार जोखिम वाली चीज़ इसकी जुड़ी हुई culture है। पुराने Java developers और legacy Java programs अक्सर बेवजह बहुत verbose लिखे गए हैं, जबकि भाषा में अब ऐसी क्षमताएँ मौजूद हैं जिनसे इसे दूसरी modern languages की तरह concise लिखा जा सकता है। फिर भी Java इतना बड़ा प्लेटफ़ॉर्म है कि इसमें बदलाव की संभावना बनी रहती है।
  • मैं जानना चाहता हूँ कि 10 साल पहले लिखा Clojure प्रोग्राम आज भी अच्छे से चल रहा है, यह JVM की वजह से है या Clojure की अपनी खासियत की वजह से। मुझे ClojureScript projects में भी ऐसा ही अनुभव हुआ है। पुराने nbb scripts भी लगभग बिना किसी समस्या के सीधे चल गए (कभी-कभी सिर्फ npm dependencies थोड़ी ठीक करनी पड़ीं)। दूसरी ओर, Python में dependency issues और venv management में कभी-कभी आधा दिन निकल जाता है।
• Java लंबे समय से हैरान कर देने वाली मजबूती वाला तकनीकी आधार रहा है। यह सबसे आकर्षक भाषा तो नहीं है, लेकिन हमेशा स्थिरता दिखाती है। Java 1.4 से बना app, Java 21 LTS पर भी ठीक से चल रहा है, और जल्द ही इसे Java 25 पर upgrade करने की योजना है। Java शानदार है।
  • अगर JetBrains के बेहतरीन tools और उसके smart student program न होते, तो सोचता हूँ Java आज कहाँ होता।
  • थोड़ा दूर का संबंध है, लेकिन 2009 में मेरे touch Symbian phone पर चलने वाला Java से बना Gmail app मुझे अब भी याद है। वह सच में प्यारा था और features भी अच्छे से काम करते थे।
  • अपने अनुभव के आधार पर मैं इससे पूरी तरह सहमत नहीं हूँ। कई कंपनियों में JVM version बढ़ाते समय हमेशा बड़ी समस्याएँ आईं, और बहुत सारा rework व retesting करना पड़ा। मैं Java 17~18 के आसपास रुक गया था, लेकिन मेरे साथ काम करने वाले लोग भी नए versions लगभग इस्तेमाल नहीं करते थे। 2022 में एक project में JVM 1.5 को update करना था, लेकिन महत्वपूर्ण third-party libraries सिर्फ Java 1.7 से पहले के versions तक ही supported थीं, इसलिए काफी मुश्किलें आईं। source code लेकर खुद compile करने की कोशिश की, लेकिन दायरा बढ़ता ही गया। managers के साथ सहमति नहीं बन पाई, और अंत में मैंने Fortune 10 के एक top client को छोड़ने का फैसला किया। सुना है वह system आज भी update नहीं हो पाया है।
  • मैं पहले लिखा हुआ एक swing app फिर से चलाना चाहता था, और लगता है कि बड़े बदलावों के बिना उसे revive किया जा सकता है, इसलिए कोशिश करने का सोच रहा हूँ।
  • JVM और उसका ecosystem Scala, Clojure जैसी दूसरी भाषाओं के साथ भी इस्तेमाल किया जा सकता है, इसलिए इसके उपयोग काफी विविध और आकर्षक हैं।
• यह अजीब लगता है कि constructor में super call से पहले parameter validation और transformation की अनुमति मिलने में इतना समय लग गया। मुझे यह बात पहले से ही intuition के खिलाफ लगती थी।
  • मैं JDK 1.0 से पहले से Java इस्तेमाल कर रहा हूँ। यह हिस्सा पहले से खटकता था, लेकिन अब इसकी आदत हो गई है और workaround methods में सहज हो चुका हूँ।
  • अगर आप static function से validate प्रक्रिया को super parameters में इस्तेमाल करते रहे हैं, तो वास्तव में वह super से पहले ही call हो जाती थी, इसलिए compiler को भी कोई समस्या नहीं थी।
• मैं Java developer नहीं हूँ, लेकिन module import system मुझे व्यक्तिगत रूप से खास पसंद नहीं है। import * जैसे syntax कोड लिखते समय आसान लगते हैं, लेकिन पढ़ने में कहीं ज्यादा कठिन होते हैं, खासकर उस developer के लिए जो भाषा या codebase से परिचित न हो। C# और Nim भी ऐसे ही style के हैं, और IDE के बिना उन्हें पढ़ना लगभग मुश्किल लगता है। इसलिए मुझे Python की तरह छोटे aliases वाले उदाहरण (import torch.nn.functional as F) ज्यादा पसंद हैं।
  • बड़े codebase में imports की मुख्य समस्या होती है: "यह आया कहाँ से?"। explicit imports ज़रूरी हैं, खासकर जब build टूट जाए या dependency versions को लेकर भ्रम हो। छोटे codebase में ज़्यादा फर्क नहीं पड़ता। वैसे भी आजकल editors import statements छिपा देते हैं, इसलिए उन्हें सीधे देखने की ज़रूरत बहुत कम पड़ती है। हम कोड पर क्लिक करके या shortcut से तुरंत source तक पहुँच जाते हैं, इसलिए imports पर ज़्यादा ध्यान नहीं जाता।
  • मुझे लगता है कि C# के साथ आपका खराब अनुभव इसलिए रहा होगा क्योंकि आपने सही Visual Studio इस्तेमाल नहीं किया। VSCode अच्छा है, लेकिन मैं csproj या sln files कभी VSCode में नहीं खोलूँगा। जानकारी के लिए, Visual Studio को यहाँ $500 में perpetual license के रूप में खरीदा जा सकता है, और इसके लिए अलग subscription की ज़रूरत नहीं है।
  • मैं यह समझ नहीं पाता कि ऐसे language constructs की शिकायत क्यों की जाए जिन्हें IDE के बिना समझना मुश्किल है। जब कोड IDE में ही देखा जा रहा है तो मुझे इसमें कोई समस्या नहीं लगती। जो लोग IDE का उपयोग नहीं करते, वे खुद अपनी असुविधा बढ़ाते हैं। GitHub पर कोड देखना आमतौर पर references का गहरा विश्लेषण करना नहीं होता, इसलिए इस स्तर की संक्षिप्तता से होने वाली थोड़ी असुविधा स्वीकार्य है।
  • जहाँ तक मुझे पता है, इस style का उद्देश्य single source file programs लिखना आसान बनाना है।
• नए features OpenJDK 25 के आधिकारिक पेज पर अच्छी तरह से व्यवस्थित हैं। Java 25 एक LTS release है।
  • उम्मीद है कि 10 साल बाद 17 से 25 में migration करने का दिन जल्दी आए।
• यह मेरा व्यक्तिगत एहसास है, लेकिन Java एक पुरानी भाषा होने के बावजूद पिछले 10 वर्षों में लगातार बेहतर हुई है, जबकि C++ उल्टा और मुश्किल लगता गया है।
• अफसोस है कि structured concurrency अभी पूरी तरह release नहीं हुआ है। मैं इस feature का सच में इंतज़ार कर रहा हूँ। इसके बदले Scoped Values का जुड़ना खुशी की बात है। सिर्फ इससे भी मुझे लगता है कि Java में "rails-like" style में code structure बनाते समय god-class या god-object का बेवजह इस्तेमाल नहीं करना पड़ेगा।
  • Java की वर्तमान preview-आधारित क्रमिक प्रगति, C++ की उस स्थिति से कहीं बेहतर लगती है जहाँ features standardize तो हो जाते हैं लेकिन implementations मौजूद नहीं होतीं और भ्रम पैदा होता है।
  • उम्मीद है कि structured concurrency, async/await की तरह सिर्फ sugar-coated चीज़ न लगे बल्कि वास्तविक प्रगति महसूस हो। सिर्फ examples देखकर अभी पूरा भरोसा नहीं हुआ है, लेकिन मैं इसे आगे भी देखता रहूँगा।
• मैंने हाल ही में JDK8 से migration करने का फैसला किया और सीधे JDK21 पर चला गया। 25 सामने ही था, इसलिए 17 छोड़कर 21 चुना। मेरी नज़र में 8 से 11 में migration सबसे कठिन था (जब नया module system आया), और उसके बाद चीज़ें आसान रहीं। Proof-of-Concept jdk17 पर किया था, लेकिन वह लगभग उसी रूप में jdk21 पर भी काम कर गया (सिर्फ guice का major version upgrade करना पड़ा)। वैसे Java की जगह दूसरी JVM language इस्तेमाल करने से भी शायद मदद मिली।
  • हमारी team के लिए 8 से 17 पर जाना मुश्किल था। हमने sun packages जैसे कई non-official हिस्सों का भी काफी उपयोग किया था, और javax से jakarta पर जाना भी बोझिल था। लेकिन वह चरण पार करने के बाद 21 या 25 पर जाना आसान लगता है। उम्मीद है कि अब आगे latest versions के साथ लगातार बने रहना पहले से ज्यादा आसान होगा।
  • Java 9 ecosystem के लिए Python 3 moment जैसा था, लेकिन अब लगता है कि चीज़ें बिना समस्या के व्यवस्थित हो चुकी हैं।
  • जानकारी के लिए, मैंने हाल ही में 17 से 21 पर migration किया और कोई समस्या नहीं आई। कुछ minor issues Gradle को साथ में upgrade करते समय आए थे (जो मूलतः अलग समस्या है)।
• Java 25 के नए features को baeldung post में अच्छी तरह संक्षेपित किया गया है।
• मैं जानना चाहता हूँ कि कानूनी दृष्टि से आज Java का उपयोग किस स्थिति में है, open source और commercial use दोनों में। Oracle Truffle जैसी बेहतरीन technology को Java से जोड़े हुए है, इसलिए समझना चाहता हूँ कि नए projects में इसका उपयोग कितना तर्कसंगत है।
  • OpenJDK मूल रूप से Oracle से सीधे आया open license वाला विकल्प है। अगर Oracle पसंद नहीं है तो Eclipse Foundation, Microsoft, Amazon आदि के बनाए versions भी इस्तेमाल किए जा सकते हैं। Java की लंबी उम्र ही वजह है कि लोग अब भी 8/11 जैसे पुराने versions इस्तेमाल करते हैं। एक बार लिख दो तो बहुत लंबे समय तक चलता है। features के मामले में यह competitors की तुलना में धीमा है, लेकिन महत्वपूर्ण development के लिए पर्याप्त है। अगर आप JVM पर निर्भर हैं, तो मैं Kotlin की सिफारिश करूँगा (खासकर क्योंकि Java में अब भी nullable type नहीं है, इसलिए NullPointerException आम है)। Kotlin पसंद न हो तो C# भी अच्छा है। फिर भी Java पूरी तरह उपयोग करने लायक है।
  • मौजूदा स्थिति में Oracle distribution के मामले में broadly यही मानिए कि सिर्फ latest LTS को खुलकर इस्तेमाल किया जा सकता है। उससे नीचे के versions OTN license के अंतर्गत आते हैं, इसलिए वे सिर्फ personal/development use के लिए हैं, production के लिए नहीं। अगर Oracle branding ज़रूरी नहीं है, तो OpenJDK या किसी और vendor के JDK के साथ license की चिंता नहीं रहती।
  • OpenJDK पूरी तरह open source है, इसलिए चिंता की कोई बात नहीं है।
  • OpenJDK जैसा कुछ इस्तेमाल करें तो Oracle वाले मुद्दों से पूरी तरह मुक्त रहते हैं।
  • जब तक आप खुद Java implementation बनाकर distribute नहीं करने वाले, कानूनी मुद्दे लगभग विचार का विषय ही नहीं हैं।