Java कोडिंग इंटरव्यू: प्रिमिटिव टाइप पैटर्न्स instanceof और switch को कैसे बदलते हैं?

प्रॉम्प्ट और दायरा

आपकी टीम instanceof, switch, और रिकॉर्ड पैटर्न्स में प्रिमिटिव टाइप पैटर्न्स के लिए Java 25 के प्रीव्यू फीचर का मूल्यांकन कर रही है। कोड एक पार्सर से Number मान प्राप्त करता है और उसे बिना किसी अनपेक्षित नैरोइंग या null विफलताओं के इंटीग्रल और फ्लोटिंग-पॉइंट मामलों को वर्गीकृत करना होगा। भाषा के नियमों को समझाएं, एक छोटा उदाहरण लिखें, और कम्पैटिबिलिटी तथा रोलआउट का निर्णय दें।

JEP 507 Java 25 में एक प्रीव्यू फीचर है। एक अच्छे उत्तर में यह बताना आवश्यक है कि प्रीव्यू सिंटैक्स के लिए स्पष्ट कंपाइलर और रनटाइम फ़्लैग की आवश्यकता होती है और यह स्वचालित रूप से एक स्थिर प्रोडक्शन अनुबंध (production contract) नहीं है।

इंटरव्यूअर क्या जांच रहा है

• क्या आप संदर्भ पैटर्न्स (reference patterns), प्रिमिटिव पैटर्न्स और बॉक्सिंग रूपांतरणों के बीच अंतर करते हैं।
• क्या आप सुरक्षित वाइडनिंग (widening), असुरक्षित नैरोइंग (narrowing), और सूचना के नुकसान (loss of information) को समझा सकते हैं।
• क्या आप null, NaN, अनंतता (infinity), और चयनकर्ता प्रकारों (selector types) को स्पष्ट रूप से संभालते हैं।
• क्या आप संपूर्ण (exhaustive) switch व्यवहार और प्रीव्यू कम्पैटिबिलिटी सीमा को समझते हैं।
• क्या आप केवल सिंटैक्स छोटा दिखने के कारण उसे अपनाने के बजाय परीक्षण और फ़ॉलबैक डिज़ाइन कर सकते हैं।

इंटरव्यूअर JEP नंबरों की सूची नहीं, बल्कि नियम और विरोधी उदाहरण (counterexamples) की तलाश कर रहा है।

पहले पूछे जाने वाले स्पष्टीकरण

1. क्या बिल्ड को CI और प्रोडक्शन में प्रीव्यू फीचर्स का उपयोग करने की अनुमति है? यदि नहीं, तो समाधान में Java 21-युग के पैटर्न्स या स्पष्ट रूपांतरणों का उपयोग किया जाना चाहिए।
2. क्या "संख्या को वर्गीकृत करना" मूल मान को सुरक्षित रखता है, या एक सीमित पूर्णांक (bounded integer) परिणाम स्वीकार्य है? यह तय करता है कि नैरोइंग वैध है या नहीं।
3. क्या null को अस्वीकार किया जाना चाहिए, UNKNOWN पर मैप किया जाना चाहिए, या एक समर्पित switch आर्म द्वारा संभाला जाना चाहिए?
4. क्या NaN और अनंत मान मान्य इनपुट हैं? संख्यात्मक प्रकार मिलान उन्हें सामान्य परिमित (finite) मानों में नहीं बदलता है।
5. क्या वही स्रोत कोड बिना प्रीव्यू वाले JDK पर कंपाइल होना चाहिए? यदि हाँ, तो प्रीव्यू कोड को एक मॉड्यूल के पीछे अलग करें या एक स्थिर कार्यान्वयन बनाए रखें।

30-सेकंड उत्तर ढांचा

"Java 25 का JEP 507 प्रीव्यू पैटर्न्स को उन संदर्भों में प्रिमिटिव प्रकारों का उल्लेख करने की अनुमति देता है जहाँ पहले बॉक्सिंग या जटिल गार्ड्स की आवश्यकता होती थी। कंपाइलर उन रूपांतरणों की अनुमति देता है जो पैटर्न नियमों के तहत सुरक्षित हैं और उस नैरोइंग को अस्वीकार करता है जिससे जानकारी का नुकसान हो सकता है। मैं प्रिमिटिव मिलान से पहले null को संभालूँगा, सीमा मानों जैसे Integer.MAX_VALUE, NaN, और अनंतता का परीक्षण करूँगा, और टूलचेन में प्रीव्यू फ़्लैग बनाए रखूँगा। यदि परिनियोजन (deployment) प्रीव्यू सक्षम के साथ Java 25 को पिन नहीं कर सकता है, तो मैं इसके बजाय एक स्थिर switch या स्पष्ट मान्य रूपांतरण का उपयोग करूँगा।"

चरण-दर-चरण समाधान

1. मान के स्थिर प्रकार (static type) से शुरुआत करें

पैटर्न कम्पैटिबिलिटी प्रत्येक संख्या को प्रत्येक प्रिमिटिव में बदलने का लाइसेंस नहीं है। एक Number संदर्भ में Integer, Long, Double, या कोई अन्य कार्यान्वयन हो सकता है। एक पैटर्न जो पहले एक संदर्भ रैपर को पहचानता है और फिर अनबॉक्स करता है, वह प्रिमिटिव चयनकर्ता पर प्रिमिटिव टाइप पैटर्न से भिन्न अनुबंध बनाए रखता है। संपूर्णता पर चर्चा करने से पहले चयनकर्ता प्रकार और रूपांतरण दिशा बताएं।

static String classify(Number value) {
    if (value == null) {
        return "missing";
    }
    return switch (value) {
        case Integer i -> "int:" + i;
        case Long l -> "long:" + l;
        case Double d when Double.isNaN(d) -> "nan";
        case Double d -> "double:" + d;
        default -> "other";
    };
}

यह स्थिर उदाहरण रैपर प्रकारों से मेल खाता है। यह दावा नहीं करता है कि प्रत्येक Number सुरक्षित रूप से int में सीमित (narrow) हो सकता है।

2. वाइडनिंग बनाम नैरोइंग को समझाएं

JEP 507 प्रिमिटिव पैटर्न्स को नियमित करता है ताकि पैटर्न वेरिएबल के लिए रूपांतरण सुरक्षित होने पर पैटर्न प्रिमिटिव मान से मेल खा सके। एक int को long में विस्तृत (widening) करने से प्रत्येक मान सुरक्षित रहता है। एक long को int में संकीर्ण (narrowing) करने से उच्च बिट्स छूट सकते हैं, इसलिए ऐसा पैटर्न जो चुपचाप ऐसे रूपांतरण को स्वीकार करता है वह असुरक्षित है। उत्तर में अस्वीकृत रूपांतरण का नाम होना चाहिए और यदि नैरोइंग एक व्यावसायिक आवश्यकता है तो एक स्पष्ट सीमा जांच (range check) का प्रस्ताव होना चाहिए।

static String bucket(long value) {
    if (value >= Integer.MIN_VALUE && value <= Integer.MAX_VALUE) {
        int narrowed = (int) value;
        return "small:" + narrowed;
    }
    return "wide:" + value;
}

कास्ट अब एक दृश्यमान अपरिवर्तनीय (invariant) द्वारा संरक्षित है। एक पैटर्न उस प्रमाण का विकल्प नहीं है।

3. null को प्रिमिटिव मिलान से अलग करें

प्रिमिटिव मान null नहीं हो सकते, लेकिन एक बॉक्स्ड चयनकर्ता हो सकता है। संदर्भ चयनकर्ता पर एक switch चुपचाप null को संख्यात्मक केस नहीं बनाता है। जब डोमेन को संपूर्ण परिणाम की आवश्यकता हो तो case null जोड़ें, या इसे switch से पहले अस्वीकार करें। अप्रत्याशित null या अज्ञात रैपर को छिपाने के लिए default आर्म का उपयोग न करें; उन मामलों की परिचालन प्रतिक्रियाएँ भिन्न होती हैं।

फ्लोटिंग-पॉइंट मानों के लिए, double प्रकार से मेल खाने का मतलब यह नहीं है कि मान परिमित (finite) है। जब डाउनस्ट्रीम कोड क्रम या अंकगणित मानकर चलता है, तो NaN, धनात्मक अनंतता, और ऋणात्मक अनंतता के लिए स्पष्ट जांच बनाए रखें।

4. जानबूझकर एक संपूर्ण (total) switch बनाएं

प्रिमिटिव पैटर्न्स और स्थिरांक switch को संक्षिप्त बना सकते हैं, लेकिन कवरेज अभी भी चयनकर्ता डोमेन और गार्ड्स पर निर्भर करता है। एक गार्डेड केस अपने प्रकार के प्रत्येक मान को कवर नहीं करता है। शेष के लिए एक अनगार्डेड केस या default का उपयोग करें, और नलेबल चयनकर्ताओं के लिए case null शामिल करें। यदि switch बिलिंग, पार्सिंग, या सुरक्षा नीति के लिए उपयोग किया जाने वाला मान लौटाता है, तो चुपचाप स्वीकार करने के बजाय फ़ॉलबैक को अवलोकनीय (observable) बनाएं।

5. प्रीव्यू सीमाओं की जाँच करें

JEP 507 Java 25 में प्रीव्यू है। संकलन और निष्पादन के लिए संबंधित --enable-preview विकल्प की आवश्यकता होती है, और source/target रिलीज़ चयनित JDK से मेल खाना चाहिए। प्रीव्यू सिंटैक्स बाद के रिलीज़ में बदल सकता है या हटाया जा सकता है। CI को एक स्थिर फ़ॉलबैक भी संकलित करना चाहिए, और एक आर्टिफ़ैक्ट को JDK, प्रीव्यू फ़्लैग और भाषा स्तर रिकॉर्ड करना चाहिए। एक लाइब्रेरी को केवल एक सार्वजनिक API को कॉल करने के लिए उपभोक्ताओं को प्रीव्यू सक्षम करने के लिए बाध्य करने से बचना चाहिए।

6. विकल्पों की तुलना करें

जब इनपुट एक विषम Number हो और कम्पैटिबिलिटी मायने रखती हो, तो स्पष्ट रैपर पैटर्न्स का उपयोग करें। जब चयनकर्ता पहले से ही एक प्रिमिटिव हो और परिनियोजन प्रीव्यू टूलचेन को पिन कर सके, तो प्रिमिटिव switch का उपयोग करें। जब व्यावसायिक नियम "32 बिट्स में फिट होना" हो, तो एक मान्य रूपांतरण का उपयोग करें, क्योंकि रेंज चेक इरादे को स्पष्ट करता है और सिंटैक्स परिवर्तन के बाद भी बना रहता है। छोटा स्रोत कोड अधिक सुरक्षित संख्यात्मक अनुबंध का प्रमाण नहीं है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं पहले चयनकर्ता और null नीति बताऊंगा। Java 25 JEP 507 एक प्रीव्यू फीचर है, इसलिए मैं इसे स्थिर सिंटैक्स के रूप में प्रस्तुत नहीं करूँगा। प्रिमिटिव पैटर्न्स instanceof, switch, और रिकॉर्ड पैटर्न्स में अधिक सुरक्षित, अधिक समान मिलान की अनुमति देते हैं, लेकिन वे नैरोइंग को दोषरहित (lossless) नहीं बनाते हैं। int को long में विस्तृत करना मानों को सुरक्षित रखता है; long को int में बदलने के लिए एक स्पष्ट रेंज प्रमाण की आवश्यकता होती है। बॉक्स्ड इनपुट के लिए मैं null को संभालता हूँ, रैपर प्रकारों में अंतर करता हूँ, और NaN और अनंतता को अलग से वर्गीकृत करता हूँ। प्रत्येक switch में एक जानबूझकर छोड़ा गया शेष होता है, और गार्डेड केस कुल कवरेज प्रदान नहीं करते हैं। यदि प्रोडक्शन प्रीव्यू सक्षम के साथ Java 25 को पिन नहीं कर सकता है, तो मैं रैपर पैटर्न्स या स्पष्ट जांच रखता हूँ और CI में दोनों रास्तों को संकलित करता हूँ। परीक्षणों में null, प्रत्येक संख्यात्मक सीमा, डुप्लिकेट प्रतिनिधित्व, NaN, अनंतता, और एक गैर-प्रीव्यू बिल्ड शामिल हैं।"

सामान्य गलतियाँ

• प्रीव्यू सिंटैक्स को स्थिर कहना → बाद का JDK इसे बदल या हटा सकता है → JDK को पिन करें और एक फ़ॉलबैक रखें।
• यह मान लेना कि प्रत्येक संख्यात्मक रूपांतरण सुरक्षित है → नैरोइंग बिट्स खो सकती है या मानों को अस्वीकार कर सकती है → रूपांतरण बताएं और इसकी सीमा साबित करें।
• default को null अवशोषित करने देना → null और अज्ञात प्रकारों को अलग-अलग हैंडलिंग की आवश्यकता होती है → case null जोड़ें या मिलान से पहले अस्वीकार करें।
• double मिलान को परिमित (finite) मानना → NaN और अनंतता अभी भी प्रिमिटिव प्रकार को संतुष्ट करते हैं → उन्हें स्पष्ट रूप से परीक्षण और वर्गीकृत करें।
• गार्डेड केस को संपूर्ण (exhaustive) के रूप में उपयोग करना → गार्ड में विफल होने वाले मान बिना मिलान के रह जाते हैं → एक अनगार्डेड शेष जोड़ें और कवरेज का परीक्षण करें।

फॉलो-अप और उत्तर

क्या एक long पैटर्न सुरक्षित रूप से एक int चयनकर्ता को बाँध (bind) सकता है?

हाँ, वाइडनिंग int मान को सुरक्षित रखता है। विपरीत दिशा आमतौर पर सुरक्षित नहीं होती है क्योंकि एक long मान int सीमा से अधिक हो सकता है। यदि डोमेन एक सीमा की गारंटी देता है, तो जांच को स्पष्ट रूप से कोड करें और दोनों सिरों का परीक्षण करें।

प्रत्येक मान को केवल बॉक्स ही क्यों न करें?

बॉक्सिंग विषम इनपुट का निरीक्षण करना आसान बना सकती है, लेकिन यह आवंटन और रैपर सिमेंटिक्स जोड़ती है और यह साबित नहीं करती है कि रूपांतरण मान को सुरक्षित रखता है। इसे API कम्पैटिबिलिटी के लिए चुनें, संख्यात्मक तर्कों से बचने के तरीके के रूप में नहीं।

आप प्रीव्यू कार्यान्वयन का परीक्षण कैसे करेंगे?

प्रीव्यू कार्यान्वयन और स्थिर फ़ॉलबैक दोनों के विरुद्ध समान केस चलाएं: null, शून्य, न्यूनतम और अधिकतम मान, एक-सीमा-बाहर मान, NaN, दोनों अनंतताएँ, अज्ञात रैपर्स, गार्डेड-केस मिस, और विकृत इनपुट। CI में सटीक रिलीज़ और प्रीव्यू फ़्लैग के साथ संकलित करें, फिर एक गैर-प्रीव्यू कम्पैटिबिलिटी जॉब चलाएं।

क्या होगा यदि Java 26 प्रीव्यू नियमों को बदल देता है?

भाषा स्तर को आर्टिफ़ैक्ट अनुबंध के भाग के रूप में मानें। नए रिलीज़ नोट्स पढ़ें, उम्मीदवार शाखा को संकलित करें, फ़ॉलबैक परीक्षणों के साथ सिमेंटिक्स की तुलना करें, और स्रोत और रनटाइम मैट्रिक्स पास होने के बाद ही प्रमोट करें। प्रोडक्शन में चुपचाप एक नया प्रीव्यू फ़्लैग सक्षम न करें।