Project Valhalla, Explained: JDK 28 में एक दशक के काम का आगमन

मूल लेख ↗ Hacker News चर्चा ↗

Project Valhalla का दायरा और लक्ष्य

  • थ्रेड इस बात से सहमत है कि Valhalla के प्राथमिक उद्देश्य हैं:
    • पहचान (identity) के बिना value classes।
    • अधिक सघन, flattened layouts (खासकर arrays के लिए)।
    • मौजूदा types (जैसे wrappers जैसे Integer) को source changes के बिना value classes के रूप में retrofitting करना।
  • कई लोग इस बात पर ज़ोर देते हैं कि इसे 30-वर्षीय ecosystem में backward-compatible तरीके से करना कितना कठिन है, बनिस्बत एक नए runtime में शुरुआत से structs डिज़ाइन करने के।

.NET, C#, और अन्य भाषाओं से तुलना

  • C# structs और reified generics से बार-बार तुलना की गई:
    • कुछ लोग कहते हैं कि Java सिर्फ़ लंबे समय से मौजूद .NET features की “catch up” कर रहा है, और लेख इसकी नवीनता को ज़्यादा बेचता है।
    • दूसरे तर्क देते हैं कि .NET पर legacy constraints कम थीं; पुराने binaries को चलाए रखते हुए JVM में यह जोड़ना trivial नहीं है।
  • fibers/virtual threads बनाम async/await पर बहस:
    • कुछ लोगों के अनुसार virtual threads, colored async functions से पूरी तरह बेहतर हैं।
    • दूसरे trade-offs की ओर इशारा करते हैं; यह सर्वसम्मति नहीं है कि वे “objectively better” हैं।

Nullability और type system की बहसें

  • Java में built-in null-safety की कमी पर तीखा मतभेद:
    • कुछ लोग मानते हैं कि Valhalla ने type level पर null को ठीक करने का मौका गंवा दिया।
    • दूसरे एक draft JEP की ओर इशारा करते हैं जो null-restricted types (T!) और coarse-grained “यहाँ सब non-null” contexts की योजनाएँ बताता है।
  • इस पर विवाद कि nullability types की property होनी चाहिए या variables की।
  • Kotlin, C#, Hack, Go, और Rust के approaches से तुलना; “सही” model पर कोई सहमति नहीं।

Semantics: identity, equality, और encapsulation

  • Value classes की identity नहीं होती; == bitwise/state comparison बन जाता है:
    • कुछ लोग इसका स्वागत करते हैं; दूसरों को चिंता है कि यह internal representation को उजागर कर देगा (उदाहरण के लिए, fraction के अलग non-normalized रूप unequal दिख सकते हैं)।
  • Integer/Long/Double का value classes बनना:
    • इसे एक दुर्लभ breaking change माना गया: reference identity या peculiar boxing behavior पर निर्भर मौजूदा code बदल सकता है या fail कर सकता है।
  • यह स्पष्ट किया गया कि value classes immutable होने के लिए intended हैं (fields effectively final)।

Performance, flattening की सीमाएँ, और tearing

  • मौजूदा preview केवल उन value arrays को flatten करता है जिनकी element representation (null flag सहित) platform के atomic write size में फिट होती है (अक्सर 64 bits):
    • skeptics कहते हैं कि इससे फायदे मुख्यतः छोटे types और boxed primitives तक सीमित हो जाते हैं।
    • supporters future work (null-restricted types, “tearable” semantics) और locals की scalarization के उपयोगी होने की ओर इशारा करते हैं।
  • चिंता यह है कि scalarization/flattening opaque तरीकों से fail हो सकती है, जिससे performance अप्रत्याशित हो जाती है; कुछ लोग silent heap fallbacks की बजाय compile-time errors पसंद करेंगे।

Java का evolution और stewardship

  • भावना बंटी हुई है:
    • आलोचक Java पर अत्यधिक conservatism, missed opportunities (null-safety, generics design), और complexity का आरोप लगाते हैं।
    • समर्थक तेज़, incremental improvements (GCs, virtual threads, records, sealed types), मज़बूत backward compatibility, और यह तर्क देते हैं कि HN की skepticism के बावजूद Java आज अपने अब तक के सबसे अच्छे रूप में है।

Meta: लेख की गुणवत्ता

  • कई टिप्पणीकार आलोचना करते हैं:
    • apparent AI-generated prose और images।
    • तकनीकी अशुद्धियाँ (hardware history, 64-bit limits को अनदेखा करने वाले examples)।
  • कुछ लोग कहते हैं कि इससे explanation पर भरोसा कम होता है, भले ही underlying JEPs सही हों।