JEP ड्राफ्ट: String Templates (Final)

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

Java की language core के लिए नया String Templates प्रस्ताव अपनी security-focused डिज़ाइन के लिए प्रशंसा और अपनी असामान्य, verbose syntax (`STR."...\{x}..."`) के लिए आलोचना, दोनों आकर्षित कर रहा है। समर्थकों का तर्क है कि template processors और `\{}` syntax, developers को raw string interpolation और injection risks से दूर रखते हुए, SQL, HTML, JSON और अन्य structured outputs को अधिक सुरक्षित तरीके से बनाने में मदद करते हैं। आलोचकों का कहना है कि यह फीचर उस समस्या को अनावश्यक रूप से जटिल बना देता है जिसे अन्य भाषाएँ सरल interpolation से हल कर लेती हैं, और वे सवाल उठाते हैं कि ergonomics से जुड़े trade-offs और backward-compatibility के औचित्य क्या अतिरिक्त जटिलता के लायक हैं।

कुल प्रतिक्रिया

  • बहुत से लोग Java में आखिरकार string templates आने का स्वागत करते हैं और उन्हें शक्तिशाली मानते हैं, खासकर custom processors और type-safe APIs (HTML, SQL, JSON) के साथ।
  • टिप्पणियों का एक बड़ा हिस्सा डिज़ाइन को “ugly”, “over-engineered”, और Kotlin, Python, JS, C# आदि जैसी अन्य भाषाओं की तुलना में बहुत verbose मानता है।
  • कुछ लोगों का तर्क है कि डिज़ाइन के पीछे के कारणों के बावजूद, सामान्य उपयोग का मामला (साधारण interpolation) अब अन्य भाषाओं और मौजूदा Java idioms दोनों की तुलना में खराब हो गया है।

Syntax: STR."..." और \{...}

  • STR. receiver और \{expr} syntax की कड़ी आलोचना की जाती है: यह visually noisy है, भ्रमित करने वाला है क्योंकि \ पारंपरिक रूप से एक escape है, और इसे { को escape करने के बजाय interpolation शुरू करने के रूप में गलत पढ़ा जा सकता है।
  • अन्य लोग इसे Java के अनुरूप मानकर बचाव करते हैं: \ पहले से ही “literal में special interpretation” का अर्थ रखता है; \{ पहले अवैध था, जिससे processor के छूटने पर उपयोगी compile-time errors देना संभव हुआ।
  • कुछ लोग तर्क देते हैं कि चूँकि वैसे भी STR जैसा processor आवश्यक है, इसलिए backward compatibility के लिए \{} का उपयोग redundant है; ${} या {} का उपयोग किया जा सकता था।
  • प्रतिवाद: $ मौजूदा Java templating ecosystems में व्यापक रूप से उपयोग होता है, और इसे special बनाने से escaping और migration की परेशानी बढ़ेगी।

सुरक्षा और डिज़ाइन लक्ष्य

  • समर्थक इस बात पर ज़ोर देते हैं कि यह सुविधा केवल string interpolation के लिए नहीं है; इसे injection vulnerabilities से निपटने के लिए डिज़ाइन किया गया है:
    • Template expressions को typed processors पर method calls बनाकर (जैसे, SQL."...", HTML."...")।
    • Libraries को plain String APIs को अस्वीकार करने और केवल safe, processor-produced types स्वीकार करने की अनुमति देकर।
  • आलोचक जवाब देते हैं कि व्यवहार में अधिकांश developer बस interpolation के लिए STR/FMT का उपयोग करेंगे और unsafe SQL/HTML को strings के रूप में ही लिखते रहेंगे।

Custom template processors / DSLs

  • कुछ लोग user-defined processors को एक बड़ा लाभ मानते हैं, JavaScript tagged templates और Scala interpolators जैसा, जो safe, domain-specific builders (SQL, HTML, JSON, XML) सक्षम करते हैं।
  • अन्य लोग ad-hoc mini-DSLs के प्रसार से डरते हैं, जिससे cognitive load और maintenance risk बढ़ता है।
  • कुछ लोग नोट करते हैं कि Scala और JS में इसी तरह की सुविधाओं ने स्पष्ट रूप से व्यापक दुरुपयोग नहीं किया है।

प्रदर्शन और tooling

  • allocation overhead (values की lists) और MethodHandle specialization पर निर्भरता को लेकर चिंताएँ उठाई गईं; जवाब में कहा गया कि specialization केवल built-in processors तक सीमित नहीं है।
  • कुछ लोगों का तर्क है कि “no extra tooling cost” का दावा बढ़ा-चढ़ाकर कहा गया है, क्योंकि parsers/IDEs को फिर भी नई expression forms संभालनी पड़ेंगी।