एक काल्पनिक परिदृश्य:अलग-अलग जेडीके अपडेट अलग जावा बाइट कोड उत्पन्न करते हैं?
मुझे एक प्रोजेक्ट मिला है जिसका स्रोत अनुपालन स्तर 1.5 को निर्दिष्ट किया गया है। अब मैं इस परियोजना को दो अलग-अलग जेडीके के साथ संकलित करता हूं: पहले जेडीके 6 अपडेट 7 के साथ और फिर जेडीके 6 अपडेट 20 के साथ।
क्या इन दो अलग-अलग जेडीके विभिन्न जावा बाइट कोड उत्पन्न करते हैं, हालांकि वे केवल उनके अपडेट संस्करण में भिन्न हैं?
जेनरेट कोड आमतौर पर केवल कंपाइलर बग फिक्स के मामले में भिन्न होता है।
हालांकि जेएलएस स्रोत कोड से उत्पन्न 1: 1 मैपिंग जेनरेट बाइट कोड में निर्दिष्ट नहीं करता है, इसलिए आपको उत्पन्न होने वाले सटीक बाइट कोड पर भरोसा नहीं करना चाहिए।
पृथ्वी पर क्यों कोई विकास विकास किट का अद्यतन जारी करने की परेशानी पर जायेगा यदि कम से कम कुछ मामलों में बाइट कोड बदल नहीं गया है? मुझे दृढ़ता से संदेह है कि कोई भी दस्तावेज़ीकरण अद्यतनों के लिए ऐसा करेगा।
अपने उदारवादी प्रश्न का उत्तर देने के लिए: क्योंकि बाइट कोड के साथ-साथ पुस्तकालयों की व्याख्या/निष्पादन भी बदल सकता है। * अद्यतनों के बीच जेडीके में अधिकांश * परिवर्तन रनटाइम और लाइब्रेरी और * नहीं * संकलक के लिए होते हैं। –
चलो दूसरी ओर से इसका जवाब दें: इस बात की कोई गारंटी नहीं है कि जेडीके के किसी भी दो संस्करण समान बाइट कोड उत्पन्न करते हैं। तो आप सामान्य रूप से अंतर की उम्मीद कर सकते हैं।
ऐसा कुछ भी नहीं है जो अलग-अलग संस्करणों को विभिन्न बाइटकोड उत्पन्न करने से रोक देगा, जब तक यह व्यवहार जेएलएस में निर्दिष्ट है। जेएलएस एक कार्यान्वयन से दूसरे में भिन्न होने के लिए कई कार्यान्वयन विवरण छोड़ देता है।
बाइटकोड थोड़ा अलग हो सकता है, लेकिन यह चिंता करने के लिए कुछ भी नहीं है क्योंकि यह अभी भी संगत होगा।
वास्तव में निष्पादित किया जाएगा जेआईटी पर निर्भर करता है।
आमतौर पर विभिन्न कंपाइलरों के लिए होता है, यह जावा मामले में भी होता है: परिणाम वही होना चाहिए, जिस तरह से यह पहुंचा जा सकता है (बाइटकोड्स बिंदु दृश्य से) अलग हो सकता है। अनुकूलन या समान रूप से। जेवीएम स्टैक आधारित वी मशीन है; निम्नलिखित एक काल्पनिक उदाहरण (मैं निर्देश opcodes के लिए JVM स्मृति सहायकों पता नहीं है)
push 10 push 20 add
push 19 push 1 add push 10 add
ये वही परिणाम उपज है, लेकिन उत्पन्न bytecodes अलग हैं (पहले थोड़ा अनुकूलित है है, दूसरा है " पूरी तरह से अनुकूलित नहीं किया गया; एक तीसरा विकल्प push 30 हो सकता है क्योंकि हम ज्ञात (संभवतः संकलन समय) स्थिरांक जोड़ रहे हैं)। यह एक साधारण मामला है, लेकिन अधिक जटिल मामला आसानी से बनाया जा सकता है।
उदाहरण के लिए कंपाइलर जेडीके 6 अपडेट 7 जेडीके 6 अपडेट 20 के कंपाइलर की तुलना में थोड़ा अलग बाइटकोड आउटपुट कर सकता है, लेकिन चूंकि यह जावा 6 दोनों है, इसलिए क्लास फाइल पूरी तरह से संगत होगी - आप कोड संकलित करने में सक्षम होंगे किसी भी समस्या के बिना अद्यतन 7 पर अद्यतन 20 के साथ।
प्रमुख जावा संस्करणों (उदाहरण के लिए जावा 5 बनाम जावा 6) के बीच परिवर्तन हो सकते हैं ताकि नए संस्करण पर संकलित कोड पुराने संस्करण पर नहीं चल सके। उदाहरण के लिए, जावा 7 के लिए एक नया निर्देश होने की संभावना है, invokedynamic। क्लास फाइलें जिनमें उस निर्देश को शामिल किया गया है, पुराने जावा संस्करणों पर नहीं चल पाएगा।
ऐसे बड़े बदलाव हालांकि अद्यतन संस्करणों के बीच कभी नहीं किए जाते हैं।
यदि आप विभिन्न जेडीके संस्करणों के साथ संकलित करते हैं तो मैं लक्ष्य विकल्प javac का उपयोग करने की सलाह दूंगा। अन्यथा आप पुराने जेडीके के साथ जार चलाने में सक्षम नहीं हो सकते हैं।
आप यह भी सुनिश्चित करने के लिए स्रोत विकल्प का उपयोग करना चाहते हैं ताकि यह सुनिश्चित किया जा सके कि डेवलपर हाल ही में जेडीके में जोड़े गए वर्ग/विधियों का उपयोग नहीं करता है।
हम पूछ सकते हैं कि यह क्यों मायने रखता है? – polygenelubricants
मैंने इसके बारे में सोचा जब मुझे अपने जेबॉस में गर्म तैनाती में समस्याएं थीं (देखें http://stackoverflow.com/questions/3005919/hot-deploy-not-longer-working-on-jboss-checheme-change-not-implemented)। –
@ पोलिजेनेलब्रिकेंट्स: बाइनरी संगतता स्रोत कोड परिवर्तनों के बारे में है, जिन्हें क्लास फ़ाइलों को अन्य क्लास फ़ाइलों के साथ संगत रखने के दौरान अनुमति दी जाती है, जिन्हें पुनः प्राप्त नहीं किया जाता है। यह एक उपयोगी विषय है लेकिन ऐसा नहीं लगता कि यह इस समस्या पर लागू होता है। –