2014-04-05 5 views
5

का कारण मैं प्रोग्रामिंग भाषाओं के सिद्धांत में खुद को शिक्षित कर रहा हूं और मुझे आश्चर्य है, हमें इस मामले के लिए बिल्कुल जावा वर्चुअल मशीन या किसी वर्चुअल मशीन की आवश्यकता क्यों है? मौलिक कारण क्या हैं?जेवीएम अस्तित्व

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

+0

हम पहले से ही है जैसे आप का वर्णन है और वे के रूप में पोर्टेबल के रूप में जावा हो जाता है नहीं कर रहे हैं (सी, सी ++ उन के बीच में कर रहे हैं) भाषाओं की क्या ज़रूरत है। जब आप जावा के लिए केवल एक बार करते हैं तो आपको प्रत्येक प्लेटफ़ॉर्म के लिए परीक्षण, संकलन और रिलीज़ करने की आवश्यकता होती है। जेवीएम मूल तरीकों पर भरोसा करके फ़ाइलों, सॉकेट इत्यादि के लिए निम्न स्तर के एपीआई से भाषा को अलग करता है। अमूर्तता का यह स्तर JVM पर ऐसी अच्छी पोर्टेबिलिटी बनाता है। –

उत्तर

5

उनके 1996 श्वेतपत्र The Java Language Environment में, सन पर जावा टीम में कहा गया जावा भाषा के लिए निम्नलिखित design goals:

जावा टीएम प्रोग्रामिंग भाषा के डिजाइन आवश्यकताओं कंप्यूटिंग वातावरण की प्रकृति से प्रेरित हैं, जिसमें सॉफ्टवेयर तैनात किया जाना चाहिए।

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

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

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

एक और नीचे थोड़ा है, वे अधिक विस्तार में एक दुभाषिया का उपयोग कर के लिए कारणों का पता:

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

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

+0

अब तक का सबसे अच्छा जवाब :) – TheLostMind

+0

आपको मैरिटन धन्यवाद। इस मामले पर कुछ प्रकाश डाला। – lishaak

1

जावा आभासी मशीन (JVM) एक मंच या बाइट कोड को चलाने के लिए एक sandbox है। बाइट कोड में विशेष निर्देश सेट और ऑपरेशन है जिसे केवल JVM द्वारा पहचाना जा सकता है।

यह किसी भी आभासी मशीनों जहां यह आपरेशन के विशिष्ट सेट उम्मीद के साथ एक ही मामला है।

3

कारण है कि हम सिर्फ विभिन्न प्लेटफार्मों के लिए एक मंच स्वतंत्र भाषा और विभिन्न compilers नहीं हो सकता?

ठीक है। यदि मैं एक 16 बिट मशीन पर एक रैखिक खोज प्रोग्राम (किसी भी भाषा में ..) लिखता हूं, तो इसे 16-बिट कंपाइलर का उपयोग करके संकलित करें और फिर इसे 32-बिट मशीन पर चलाने का प्रयास करें। क्या यह वैसे ही व्यवहार करेगा?

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

अब,

वर्चुअल मशीनें: ये मूल रूप से "मशीन समझ/ओएस समझ भाषा" में दिए गए निर्देशों का कन्वर्ट करने के लिए लिखा सॉफ्टवेयर है। वे आपके ओएस के शीर्ष पर बैठते हैं और इसे कॉल करते हैं यानी ओएस को समझते हैं कि आपका एप्लिकेशन क्या चाहता है।

JVM: जिसमें जावा के लिए प्रयोग किया जाता है आभासी मशीन का एक प्रकार है। जब आप एक जावा प्रोग्राम लिखते और संकलित करते हैं, तो यह "लगभग-माचिन स्वतंत्र" राज्य में होगा। इसे बाइट कोड कहा जाता है। आप इसे किसी अन्य मशीन पर ले जा सकते हैं और इसे चला/समझ सकते हैं।

+0

ठीक है, मैं समझता हूं कि जेवीएम क्या है, मुझे जावा प्रोग्रामर का अनुभव है और मैंने कई अन्य भाषाओं का भी उपयोग किया है। तो मुझे पता है कि वर्चुअल मशीन कैसे काम करती है और बाइट कोड क्या है। आप कह रहे हैं कि अब जावा के साथ आप परवाह करने की ज़रूरत के बिना बिल्कुल एक कोड लिख सकते हैं उदा। थोड़ा गहराई ठीक है, अगर यह संभव है तो एक कंपाइलर लिखना क्यों संभव नहीं है, जो सीधे कोड कोड को संकलित करेगा? अंत में, सभी प्रोग्राम सीधे या कोड कोड को व्याख्या करके मशीन कोड के रूप में निष्पादित किए जाते हैं। – lishaak

+0

@meriton ने इसे विस्तार से समझाया है :) – TheLostMind

2

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

यहां मैं वर्चुअल मशीनों के लाभ के मानव पक्ष को जोड़ दूंगा। यह मुख्य रूप से विकास और तक पहुंचने के लिए है।

विशिष्ट ऑपरेटिंग सिस्टम के लिए विशिष्ट कंपेलरों के साथ मंच स्वतंत्र भाषा के उदाहरण के रूप में सी पर विचार करें। लिनक्स के साथ-साथ विंडोज़ पर सी में कोड भी हो सकता है। लेकिन, आपको एक ही सिस्टम को Windows सिस्टम पर चलाने के लिए अतिरिक्त लाइब्रेरी हेडर फ़ाइल conio.h की आवश्यकता होगी।

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

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

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

संक्षेप में; यह प्रत्येक प्रणाली के लिए एक ही स्रोत कोड के मेनियल दोहराव पुनर्मूल्यांकन को कम करना है, ताकि हम प्रोग्रामर हमारे समय के योग्य चीज़ों पर ध्यान केंद्रित कर सकें। [या हम सिर्फ आलसी हैं;)]

परिशिष्ट:

लैरी वॉल, पर्ल प्रोग्रामिंग भाषा के मूल लेखक, वहाँ एक प्रोग्रामर के तीन महान गुण हैं के अनुसार; आलस्य, असंतोष और हबिस। Link

1

आभासी मशीनों एक महत्वपूर्ण भाषा के विकास और कार्यान्वयन को आसान बनाने के लिए इस्तेमाल किया अमूर्त हैं।

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

जैसे कि जावा

अन्य भाषाओं बाईटकोड जो तब या तो व्याख्या की है या सिर्फ-इन-टाइम (JIT) निष्पादन के लिए संकलित करने के लिए समय से आगे संकलित किया जा सकता। इस मॉडल में केवल वर्चुअल मशीन ही है, और संकलक नहीं, वहां कोड चलाने के लिए किसी भी दिए गए वातावरण को पोर्ट किया जाना चाहिए। जावा ने वेब पेजों में अनुप्रयोगों को एम्बेड करने की इजाजत देकर इसका फायदा उठाया।

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

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

संबंधित मुद्दे