क्या जावा श्रेणी की फाइलों का निर्माण नियतात्मक है?

Question

एक ही JDK (यानी एक ही javacनिष्पादन योग्य) का उपयोग करते समय , उत्पन्न वर्ग फाइलें हमेशा समान होती हैं? क्या ऑपरेटिंग सिस्टम या हार्डवेयर के आधार पर अंतर हो सकता है ? जेडीके संस्करण को छोड़कर, मतभेदों के परिणामस्वरूप कोई अन्य कारक हो सकते हैं? मतभेदों से बचने के लिए कोई संकलक विकल्प हैं? क्या केवल सिद्धांत में ही अंतर है या ऑरेकल javacवास्तव में एक ही इनपुट और कंपाइलर विकल्पों के लिए अलग-अलग श्रेणी की फाइलें तैयार करता है?

अपडेट 1 मैं पीढ़ी , यानी कंपाइलर आउटपुट में दिलचस्पी रखता हूं , यह नहीं कि क्या विभिन्न प्लेटफार्मों पर एक क्लास फ़ाइल चलाई जा सकती है।

अपडेट 2 'सेम जेडीके' द्वारा, मैं भी उसी javacनिष्पादन योग्य मतलब है ।

अद्यतन 3 ओरेकल के संकलक में सैद्धांतिक अंतर और व्यावहारिक अंतर के बीच का अंतर।

[संपादित करें, पैराफ़्रास्ड प्रश्न जोड़ते हुए]
"वे परिस्थितियाँ क्या हैं जहाँ एक ही javac निष्पादन योग्य है, जब एक अलग प्लेटफ़ॉर्म पर चलाया जाता है, तो अलग-अलग बायोटेक उत्पन्न करेगा?"

Comments

@ जुआ कॉरा का मतलब यह नहीं है कि बाइट कोड बिल्कुल वैसा ही होगा यदि विभिन्न प्लेटफार्मों पर संकलित किया गया हो; इसका मतलब यह है कि उत्पन्न बाइट कोड बिल्कुल वही काम करेगा।

— dasblinkenlight

तुम क्यो फिकर करते हो? इससे XY प्रॉब्लम जैसी बदबू आती है ।

— जोकिम सॉयर

@JoachimSauer विचार करें कि क्या आप संस्करण अपने बायनेरिज़ को नियंत्रित करते हैं - आप केवल स्रोत कोड में परिवर्तन होने पर परिवर्तन का पता लगाना चाहते हैं, लेकिन आपको पता होगा कि यह एक समझदार विचार नहीं था यदि जेडीके मनमाने ढंग से आउटपुट बायनेरिज़ को बदल सकता है।

— आरबी।

@ आरबी .: संकलक को किसी भी अनुरूप बाइट कोड का उत्पादन करने की अनुमति है जो संकलित कोड का प्रतिनिधित्व करता है। वास्तव में, कुछ संकलक अपडेट बग को ठीक करते हैं जो थोड़ा अलग कोड (आमतौर पर समान रनटाइम व्यवहार के साथ) उत्पन्न करते हैं। दूसरे शब्दों में: यदि आप स्रोत परिवर्तनों का पता लगाना चाहते हैं, तो स्रोत परिवर्तनों की जाँच करें ।

— जोकिम सॉयर

@dasblinkenlight: आप मान रहे हैं कि जिस उत्तर का वे दावा करते हैं, वह वास्तव में सही है और अप-टू-डेट (संदिग्ध, यह देखते हुए कि प्रश्न 2003 से है)।

— जोआचिम सॉयर

Answer 1

इसे इस तरह रख कर देखते हैं:

मैं आसानी से एक पूरी तरह से अनुरूपित जावा कंपाइलर का उत्पादन कर सकता हूं जो कभी भी एक ही .classफ़ाइल को एक ही बार दो बार नहीं बनाता है .java।

मैं सभी प्रकार के बाईटकोड निर्माण को टाल कर या केवल अपनी विधि (जो अनुमति दी गई है) में शानदार गुण जोड़कर कर सकता हूं।

यह देखते हुए कि विनिर्देशन को संकलक को बाइट-फॉर-बाइट समान श्रेणी की फ़ाइलों का उत्पादन करने की आवश्यकता नहीं है , मैं इस तरह के परिणाम से बचना चाहूंगा ।

हालांकि , कई बार है कि मैं देख लिया है, एक ही स्विच (और एक ही पुस्तकालयों!) के साथ एक ही संकलक के साथ एक ही स्रोत फ़ाइल संकलन किया था उसी में परिणाम .classफ़ाइलें।

अद्यतन: मैं हाल ही में खत्म हो गया है ठोकर खाई के कार्यान्वयन के बारे में इस दिलचस्प ब्लॉग पोस्ट switchपर Stringजावा 7 में । इस ब्लॉग पोस्ट में, कुछ प्रासंगिक भाग हैं, जिन्हें मैं यहाँ उद्धृत करूँगा (जोर मेरा):

संकलक के आउटपुट को पूर्वानुमेय और दोहराने योग्य बनाने के लिए, इन डेटा संरचनाओं में उपयोग किए जाने वाले नक्शे और सेट केवल और के बजाय LinkedHashMapएस और LinkedHashSetएस हैं । दिए गए संकलन के दौरान उत्पन्न कोड की कार्यात्मक शुद्धता के संदर्भ में , उपयोग करना और ठीक होगा ; पुनरावृति क्रम कोई फर्क नहीं पड़ता। हालाँकि, हमें यह लाभदायक लगता है कि सिस्टम कक्षाओं के कार्यान्वयन के विवरण के आधार पर आउटपुट अलग-अलग नहीं है ।HashMapsHashSetsHashMapHashSetjavac

यह बहुत स्पष्ट रूप से इस मुद्दे को दिखाता है: कंपाइलर को नियतात्मक तरीके से कार्य करने की आवश्यकता नहीं है, जब तक कि यह कल्पना से मेल नहीं खाता है। कंपाइलर डेवलपर्स, हालांकि, महसूस करते हैं कि यह आम तौर पर प्रयास करने के लिए एक अच्छा विचार है (बशर्ते यह बहुत महंगा नहीं है, शायद)।

Comments

@GaborSch क्या याद आ रही है? "ऐसी कौन सी परिस्थितियाँ हैं जहाँ एक ही जावाक निष्पादन योग्य होता है, जब एक अलग प्लेटफ़ॉर्म पर चलाया जाता है, तो अलग-अलग बायोटेक उत्पन्न करेगा?" मूल रूप से संकलक बनाने वाले समूह की सनक पर निर्भर करता है

— एमोरी

खैर, मेरे लिए यह इस पर निर्भर न करने के लिए पर्याप्त कारण होगा: एक अद्यतन JDK मेरे बिल्ड / अभिलेखीय प्रणाली को तोड़ सकता है अगर मैं इस तथ्य पर निर्भर करता कि कंपाइलर हमेशा एक ही कोड बनाता है।

— जोकिम सॉयर

@GaborSch: आपके पास पहले से ही ऐसी स्थिति का एक अच्छा उदाहरण है, इसलिए समस्या पर कुछ अतिरिक्त दृश्य क्रम में थे। आपके काम की नकल करने में कोई समझदारी नहीं है।

— जोआचिम सॉयर

@GaborSch मूल समस्या यह है कि हम अपने एप्लिकेशन के एक कुशल "ऑनलाइन अपडेट" को लागू करना चाहते हैं जिसके लिए उपयोगकर्ता केवल वेबसाइट से संशोधित JARs प्राप्त करेंगे। मैं समान JAR को इनपुट के रूप में समान श्रेणी की फाइलें बना सकता हूं। लेकिन सवाल यह है कि क्या समान स्रोत फ़ाइलों से संकलित होने पर कक्षा की फाइलें हमेशा समान होती हैं। हमारी पूरी अवधारणा इस तथ्य के साथ खड़ी है और विफल है।

— mstrap

@mstrap: तो यह सब के बाद एक XY समस्या है। ठीक है, आप जार के अंतर अपडेट में देख सकते हैं (इसलिए एक-बाइट-अंतर के कारण पूरे जार को फिर से डाउनलोड नहीं किया जाएगा) और आपको अपनी रिलीज़ के लिए स्पष्ट संस्करण संख्या प्रदान करनी चाहिए, ताकि पूरी बात मेरे विचार में है ।

— जोकिम सॉयर

Answer 2

कंपाइलरों के लिए प्रत्येक प्लेटफ़ॉर्म पर एक ही बायोटेक का उत्पादन करने के लिए कोई दायित्व नहीं है। आपको javacविशिष्ट उत्तर के लिए विभिन्न विक्रेताओं की उपयोगिता से परामर्श करना चाहिए ।

---

मैं फ़ाइल ऑर्डरिंग के साथ इसके लिए एक व्यावहारिक उदाहरण दिखाऊंगा।

मान लीजिए कि हमारे पास 2 जार फाइलें हैं: my1.jarऔर My2.jar। उन्हें libनिर्देशिका में, साथ-साथ रखा गया है। संकलक उन्हें वर्णमाला क्रम में पढ़ता है (क्योंकि यह है lib), लेकिन आदेश है my1.jar, My2.jarजब फ़ाइल सिस्टम असंवेदनशील है, और My2.jar, my1.jarअगर यह संवेदनशील है।

my1.jarएक वर्ग है A.classएक विधि के साथ

public class A {
     public static void a(String s) {}
}

My2.jarएक ही है A.class, लेकिन अलग अलग विधि हस्ताक्षर के साथ (स्वीकार करता है Object):

public class A {
     public static void a(Object o) {}
}

यह स्पष्ट है कि यदि आपके पास कॉल है

String s = "x"; 
A.a(s); 

यह विभिन्न मामलों में अलग हस्ताक्षर के साथ एक विधि कॉल संकलित करेगा। इसलिए, आपके फाइलसिस्टम केस सेंसिटिविटी के आधार पर, आपको परिणामस्वरूप अलग-अलग वर्ग मिलेंगे।

Comments

+1 ग्रहण संकलक और जेवैक के बीच असंख्य अंतर हैं, उदाहरण के लिए कि सिंथेटिक कंस्ट्रक्टर कैसे उत्पन्न होते हैं ।

— पॉल बेलोरा

@GaborSch मुझे दिलचस्पी है कि क्या बाइट कोड समान JDK के लिए समान है, यानी समान javac। मैं वह साफ कर दूंगा।

— mstrap

@ मैंस्ट्रैप मैंने आपके प्रश्न को समझा, लेकिन उत्तर अभी भी वही है: विक्रेता पर निर्भर करता है। यह javacसमान नहीं है, क्योंकि आपके पास प्रत्येक प्लेटफ़ॉर्म पर अलग-अलग बायनेरिज़ हैं (जैसे Win7, Linux, Solaris, Mac)। एक विक्रेता के लिए, अलग-अलग कार्यान्वयन होने का कोई मतलब नहीं है, लेकिन कोई भी प्लेटफ़ॉर्म विशिष्ट मुद्दा परिणाम को प्रभावित कर सकता है (उदाहरण के लिए एक निर्देशिका में फ्लि ऑर्डर करना (आपकी libनिर्देशिका पर विचार करना ), एंडियननेस, आदि)।

— गबोरश

आमतौर पर, अधिकांश को javacजावा में लागू किया जाता है (और javacसिर्फ एक साधारण देशी लांचर है), इसलिए अधिकांश प्लेटफ़ॉर्म अंतर का कोई प्रभाव नहीं होना चाहिए।

— जोआचिम सॉयर

@mstrap - वह जो बिंदु बना रहा है, वह यह है कि किसी भी विक्रेता को अपने कंपाइलर का उत्पादन करने के लिए प्लेटफॉर्म पर बिलकुल एक ही बायटेकोड की आवश्यकता नहीं है, केवल इसके परिणामस्वरूप बायटेकोड वही परिणाम उत्पन्न करता है। यह देखते हुए कि आपके प्रश्न का उत्तर कोई मानक / युक्ति / आवश्यकता नहीं है "यह विशिष्ट विक्रेता, संकलक और प्लेटफॉर्म पर निर्भर करता है"।

— ब्रायन रोच

Answer 3

संक्षिप्त उत्तर - नहीं

---

लंबा जवाब

उन्हें bytecodeअलग-अलग प्लेटफॉर्म के लिए समान नहीं होना चाहिए। यह जेआरई (जावा रनटाइम एनवायरनमेंट) है जो जानता है कि बाईटेकोड को कैसे निष्पादित किया जाता है।

यदि आप जावा वीएम विनिर्देशन के माध्यम से जाते हैं, तो आपको पता चल जाएगा कि यह सही नहीं है कि अलग-अलग प्लेटफार्मों के लिए बायटेकोड समान है।

क्लास फाइल फॉर्मेट से गुजरते हुए , यह क्लास फाइल की संरचना को दिखाता है

ClassFile {
    u4 magic;
    u2 minor_version;
    u2 major_version;
    u2 constant_pool_count;
    cp_info constant_pool[constant_pool_count-1];
    u2 access_flags;
    u2 this_class;
    u2 super_class;
    u2 interfaces_count;
    u2 interfaces[interfaces_count];
    u2 fields_count;
    field_info fields[fields_count];
    u2 methods_count;
    method_info methods[methods_count];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
}

लघु और प्रमुख संस्करण के बारे में जाँच

minor_version, major_version

माइनर_वर्जन और मेजर_वर्जन आइटम्स के मान इस क्लास फाइल के माइनर और मेजर वर्जन नंबर हैं। कुल मिलाकर, एक मेजर और माइनर वर्जन नंबर क्लास फाइल फॉर्मेट के वर्जन को निर्धारित करते हैं। यदि किसी वर्ग फ़ाइल में प्रमुख संस्करण संख्या M और लघु संस्करण संख्या m है, तो हम इसके वर्ग फ़ाइल प्रारूप के संस्करण को Mm के रूप में निरूपित करते हैं, इसलिए, वर्ग फ़ाइल प्रारूप संस्करणों को शाब्दिक रूप से आदेश दिया जा सकता है, उदाहरण के लिए, 1.5 <2.0 <2.1। एक जावा वर्चुअल मशीन कार्यान्वयन संस्करण v के एक वर्ग फ़ाइल प्रारूप का समर्थन कर सकता है अगर और केवल अगर v कुछ सन्निहित रेंज में निहित है Mi.0 vj.m. केवल सन निर्दिष्ट कर सकता है कि जावा प्लेटफ़ॉर्म के किसी निश्चित रिलीज़ स्तर के अनुरूप जावा वर्चुअल मशीन कार्यान्वयन किस संस्करण का समर्थन कर सकता है

फुटनोट के माध्यम से अधिक पढ़ना

1 सूर्य की JDK रिलीज़ 1.0.2 का जावा वर्चुअल मशीन कार्यान्वयन 45.3 समावेशी के माध्यम से 45.0 वर्ग फ़ाइल प्रारूप संस्करणों का समर्थन करता है। सन की JDK रिलीज़ 1.1.X 45.65535 समावेशी के माध्यम से 45.0 रेंज में संस्करणों के वर्ग फ़ाइल स्वरूपों का समर्थन कर सकती है। जावा 2 प्लेटफ़ॉर्म के संस्करण 1.2 का कार्यान्वयन 46.0 समावेशी के माध्यम से 45.0 रेंज में संस्करणों के वर्ग फ़ाइल स्वरूपों का समर्थन कर सकता है।

इसलिए, इस सब की जांच से पता चलता है कि विभिन्न प्लेटफार्मों पर उत्पन्न वर्ग फ़ाइलों को समान होने की आवश्यकता नहीं है।

Comments

क्या आप कृपया अधिक विस्तृत लिंक दे सकते हैं?

— mstrap

मुझे लगता है कि 'प्लेटफ़ॉर्म' से वे जावा प्लेटफ़ॉर्म की बात कर रहे हैं, ऑपरेटिंग सिस्टम की नहीं। बेशक, 1.6-संगत क्लास फ़ाइलों को बनाने के लिए javac 1.7 को निर्देश देते समय, एक अंतर होगा।

— mstrap

संकलन के दौरान एक वर्ग के लिए कितने गुण उत्पन्न होते हैं यह दिखाने के लिए @mtk +1।

— गाबर्सच

Answer 4

सबसे पहले, कल्पना में ऐसी कोई गारंटी नहीं है। एक अनुरूप कंपाइलर अतिरिक्त (कस्टम) विशेषता के रूप में उत्पन्न वर्ग फ़ाइल में संकलन के समय पर मुहर लगा सकता है, और वर्ग फ़ाइल अभी भी सही होगी। हालाँकि यह हर एक बिल्ड पर एक बाइट-स्तरीय अलग फ़ाइल का उत्पादन करेगा, और तुच्छ रूप से।

दूसरी बात, इस तरह के घिनौने काम के बिना भी, एक कंपाइलर से एक पंक्ति में दो बार एक ही काम करने की उम्मीद करने का कोई कारण नहीं है जब तक कि उसके कॉन्फ़िगरेशन और उसके इनपुट दोनों मामलों में समान नहीं हैं। कल्पना करता मानक विशेषताओं में से एक के रूप में स्रोत फ़ाइल नाम का वर्णन है, और स्रोत फ़ाइल के लिए रिक्त लाइनों को जोड़ने अच्छी तरह से लाइन नंबर तालिका बदल सकता है।

तीसरे, मैंने होस्ट प्लेटफ़ॉर्म (इसके अलावा जो क्लासपाथ में अंतर के कारण था) के कारण निर्माण में कोई अंतर नहीं देखा है। कोड जो प्लेटफ़ॉर्म (यानी, देशी कोड लाइब्रेरी) के आधार पर अलग-अलग होगा, वह क्लास फ़ाइल का हिस्सा नहीं है, और बायटेकोड से देशी कोड की वास्तविक पीढ़ी वर्ग लोड होने के बाद होती है।

चौथा (और सबसे महत्वपूर्ण) यह एक खराब प्रक्रिया गंध (जैसे एक कोड गंध, लेकिन आप कोड पर कैसे कार्य करते हैं) के बारे में जानना चाहते हैं। यदि संभव हो तो स्रोत का निर्माण करें, बिल्ड का नहीं, और यदि आपको बिल्ड का संस्करण बनाने की आवश्यकता है, तो पूरे-घटक स्तर पर संस्करण और न कि व्यक्तिगत डेटा फ़ाइलों पर। प्राथमिकता के लिए, स्रोत को चालू करने योग्य कोड में बदलने की प्रक्रिया को प्रबंधित करने के लिए CI सर्वर (जैसे जेनकिन्स) का उपयोग करें।

Answer 5

मेरा मानना ​​है कि, यदि आप एक ही JDK का उपयोग करते हैं, तो उत्पन्न बाइट कोड हमेशा एक ही होगा, बिना उपयोग किए हार्बर और OS के साथ संबंध के बिना। बाइट कोड का उत्पादन जावा कंपाइलर द्वारा किया जाता है, जो स्रोत कोड को बाइट कोड में "रूपांतरित" करने के लिए एक नियतात्मक एल्गोरिथम का उपयोग करता है। इसलिए, आउटपुट हमेशा समान रहेगा। इन स्थितियों में, स्रोत कोड पर केवल एक अपडेट आउटपुट को प्रभावित करेगा।

Comments

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

— आरबी।

यह मेरे सवाल का जवाब है और मैं क्या उम्मीद करूंगा, हालांकि मैं आरबी से सहमत हूं कि इसके लिए एक संदर्भ महत्वपूर्ण होगा।

— mstrap 16

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

— एमोरी

Answer 6

कुल मिलाकर, मेरा कहना है कि इस बात की कोई गारंटी नहीं है कि समान संकलक द्वारा संकलित किए जाने पर एक ही स्रोत बायकोटोड का उत्पादन करेगा लेकिन एक अलग मंच पर।

मैं विभिन्न भाषाओं (कोड-पेज) के परिदृश्यों पर ध्यान देता हूं, उदाहरण के लिए जापानी भाषा समर्थन के साथ विंडोज। मल्टी-बाइट वर्णों के बारे में सोचो; जब तक कंपाइलर हमेशा यह मान लेता है कि उसे 8-बिट ASCII के लिए अनुकूलित हो सकने वाली सभी भाषाओं का समर्थन करना चाहिए।

जावा भाषा विनिर्देश में द्विआधारी संगतता पर एक अनुभाग है ।

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

• प्रदर्शन को बेहतर बनाने के लिए मौजूदा तरीकों, निर्माणकर्ताओं और इनिशियलाइज़र को लागू करना।

• आदानों पर मूल्यों को लौटाने के लिए तरीकों या निर्माणों को बदलना, जिसके लिए वे पहले या तो अपवादों को फेंक देते हैं जो आम तौर पर घटित नहीं होना चाहिए या एक अनंत लूप में जाने या गतिरोध पैदा करने में विफल रहा।

• एक मौजूदा वर्ग या इंटरफ़ेस में नए फ़ील्ड, विधियाँ, या कंस्ट्रक्टर जोड़ना।

• किसी कक्षा के निजी क्षेत्र, विधियाँ, या निर्माणकर्ता को हटाना।

• जब एक पूरा पैकेज अद्यतन किया जाता है, तो डिफ़ॉल्ट (पैकेज-ओनली) एक्सेस फ़ील्ड, विधियों, या पैकेज में वर्गों और इंटरफेस के निर्माण को हटा देता है।

• मौजूदा प्रकार की घोषणा में फ़ील्ड, विधियों, या कंस्ट्रक्टर को फिर से व्यवस्थित करना।

• कक्षा पदानुक्रम में एक विधि को ऊपर की ओर ले जाना।

• एक वर्ग या इंटरफ़ेस के प्रत्यक्ष सुपरन्टेफ़्स की सूची को फिर से व्यवस्थित करना।

• पदानुक्रम में नए वर्ग या इंटरफ़ेस प्रकार सम्मिलित करना।

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

Comments

यह आलेख चर्चा करता है कि हम जावा संस्करण को बदल सकते हैं। ओपी का सवाल था कि अगर हम एक ही जावा संस्करण में प्लेटफॉर्म बदलते हैं तो क्या हो सकता है। अन्यथा यह एक अच्छी पकड़ है।

— gaborsch

यह उतना ही करीब है जितना मुझे मिल सकता है। भाषा और जेवीएम की कल्पना के बीच एक अजीब छेद है। अब तक, मुझे ओपी के साथ जवाब देना होगा कि 'इस बात की कोई गारंटी नहीं है कि एक ही जावा कंपाइलर एक अलग प्लेटफॉर्म पर चलने पर एक ही बायटेकोड का उत्पादन करेगा।'

— केली एस। फ्रेंच

Answer 7

Java allows you write/compile code on one platform and run on different platform. AFAIK ; यह तभी संभव होगा जब विभिन्न प्लेटफ़ॉर्म पर उत्पन्न वर्ग फ़ाइल समान या तकनीकी रूप से समान हो या समान हो।

संपादित करें

तकनीकी रूप से मेरा मतलब वही है टिप्पणी से है। यदि आप बाइट की बाइट की तुलना करते हैं तो उन्हें बिल्कुल वैसा ही होने की आवश्यकता नहीं है।

इसलिए विनिर्देश के अनुसार विभिन्न प्लेटफार्मों पर एक वर्ग की .class फ़ाइल को बाइट-बाय-बाइट से मेल खाने की आवश्यकता नहीं है।

Comments

ओपी का सवाल था कि क्या क्लास की फाइलें समान थीं या "तकनीकी रूप से समान थीं"।

— bdesham

मुझे दिलचस्पी है कि क्या वे समान हैं ।

— mstrap

और उत्तर हाँ है। मेरा मतलब है कि वे समान नहीं हो सकते हैं यदि आप बाइट की बाइट की तुलना करते हैं, तो यही कारण है कि मैंने तकनीकी रूप से उसी शब्द का उपयोग किया है।

— rai.skumar

@bdesham वह जानना चाहता था कि क्या वे समान हैं। सुनिश्चित नहीं है कि आप "तकनीकी रूप से वही" से क्या समझे ... क्या यह पतन का कारण है?

— rai.skumar

@ rai.skumar आपका उत्तर मूल रूप से कहता है, "दो संकलक हमेशा ऐसा उत्पादन करते हैं जो समान व्यवहार करता है।" बेशक यह सच है; यह जावा प्लेटफॉर्म की पूरी प्रेरणा है। ओपी यह जानना चाहता था कि क्या उत्सर्जित कोड बाइट के लिए बाइट के समान था , जिसे आपने अपने उत्तर में संबोधित नहीं किया था।

— बिशेष

Answer 8

प्रश्न के लिए:

"वे परिस्थितियाँ क्या हैं जहाँ एक ही जावाक निष्पादन योग्य होता है, जब एक अलग प्लेटफ़ॉर्म पर चलाया जाता है, तो अलग-अलग बायोटेक उत्पन्न करेगा?"

क्रॉस-संकलन उदाहरण से पता चलता है कि कैसे हम javac विकल्प का उपयोग कर सकते हैं: -target संस्करण

यह ध्वज क्लास फ़ाइलों को उत्पन्न करता है जो इस कमांड को लागू करते समय हमारे द्वारा निर्दिष्ट जावा संस्करण के साथ संगत हैं। इसलिए इस विकल्प के उपयोग के दौरान हमारे द्वारा आपूर्ति की जाने वाली विशेषताओं के आधार पर कक्षा की फाइलें अलग-अलग होंगी।

Answer 9

शायद, उत्तर "हाँ" है, लेकिन सटीक उत्तर देने के लिए, किसी को संकलन के दौरान कुछ कुंजी या गाइड पीढ़ी की खोज करने की आवश्यकता होती है।

मुझे वह स्थिति याद नहीं है जहां यह होता है। उदाहरण के लिए क्रमबद्ध प्रयोजनों के लिए आईडी होना कठिन है, अर्थात प्रोग्रामर या आईडीई द्वारा उत्पन्न।

PS इसके अलावा JNI मायने रख सकता है।

पीपीएस मैंने पाया कि javacयह स्वयं जावा में लिखा गया है। इसका मतलब है कि यह विभिन्न प्लेटफार्मों पर समान है। इसलिए यह बिना किसी कारण के अलग कोड उत्पन्न नहीं करेगा। तो, यह केवल देशी कॉल के साथ कर सकता है।

Comments

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

— जोकिम सॉयर

Answer 10

दो सवाल हैं।

Can there be a difference depending on the operating system or hardware? 

यह एक सैद्धांतिक सवाल है, और जवाब स्पष्ट रूप से है, हाँ, वहाँ हो सकता है सकता है। जैसा कि दूसरों ने कहा है, विनिर्देशन को बाइट के लिए बाइट समान क्लास फ़ाइलों का उत्पादन करने के लिए संकलक की आवश्यकता नहीं है।

भले ही वर्तमान में प्रत्येक कंपाइलर सभी परिस्थितियों (अलग हार्डवेयर, आदि) में एक ही बाइट कोड का उत्पादन करता है, कल उत्तर अलग हो सकता है। यदि आप कभी भी javac या अपने ऑपरेटिंग सिस्टम को अपडेट करने की योजना नहीं बनाते हैं, तो आप अपने विशेष परिस्थितियों में उस संस्करण के व्यवहार का परीक्षण कर सकते हैं, लेकिन यदि आप जाते हैं तो परिणाम भिन्न हो सकते हैं, उदाहरण के लिए, जावा 7 अपडेट 11 से जावा 7 अपडेट 15।

What are the circumstances where the same javac executable, when run on a different platform, will produce different bytecode?

वह अनजाना है।

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

Answer 11

मैं इसे दूसरे तरीके से रखूंगा।

सबसे पहले, मुझे लगता है कि सवाल निर्धारक होने के बारे में नहीं है:

बेशक यह निर्धारक है: यादृच्छिकता कंप्यूटर विज्ञान में प्राप्त करना कठिन है, और कोई कारण नहीं है कि एक कंपाइलर इसे किसी भी कारण से यहां पेश करेगा।

दूसरा, यदि आप इसे "एक ही सोर्सकोड फ़ाइल के लिए बाइटकोड फ़ाइलों के समान कैसे हैं" द्वारा इसे सुधारते हैं, तो नहीं , आप इस तथ्य पर भरोसा नहीं कर सकते हैं कि वे समान होंगे ।

यह सुनिश्चित करने का एक अच्छा तरीका है, अपने गिट चरण में .class (या मेरे मामले में .pyc) को छोड़कर। आपको महसूस होगा कि आपकी टीम के विभिन्न कंप्यूटरों के बीच, .pyc फ़ाइलों के बीच में परिवर्तन होता है, जब .py फ़ाइल में कोई परिवर्तन नहीं लाया जाता था (और .pyc वैसे भी पुन: संकलित होता है)।

कम से कम मैंने यही देखा। तो * .pyc और * .class को अपने .gitignore में डालें!