2010-07-11 5 views
12

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

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

मुझे लगता है कि इसका मतलब यह होगा कि अन्य भाषाओं में, कोड को स्वयं किस कंप्यूटर पर चल रहा है, इस पर निर्भर करता है।

क्या कोई इस तरह के नमस्ते विश्व कार्यक्रम की तरह छोटे उदाहरण प्रदान कर सकता है जो इसे प्रदर्शित करता है? इसमें कोई संदेह नहीं है कि यह गैर-जावा में होगा उदा। सी

चूंकि यह ऐसा कुछ नहीं है जो आम तौर पर हैलो वर्ल्ड प्रोग्राम में होता है या मैंने जावा पर उपयोग की जाने वाली किताबों के बाद से देखा है, दुर्भाग्यवश, "प्रोग्राम कैसे करें" शैली की किताबें और सभी चीजें थीं उनमें से यह प्रदर्शित नहीं किया था (शायद 'क्योंकि वे इसे दिखाने के लिए जावा का उपयोग नहीं करना चाहते थे या नहीं!)। हालांकि उन्होंने इसे एक बड़ा फायदा के रूप में तुरही दी। मैं इसके उदाहरण देखना चाहता हूं।

+0

संभावित डुप्लिकेट [प्लेटफॉर्म आजादी कितनी महत्वपूर्ण है?] (Http://stackoverflow.com/questions/540432/how-important-is-platform-independence); "प्लेटफॉर्म आजादी" के लिए भी खोज करें – polygenelubricants

+0

अच्छी तरह से, मेरा प्रश्न कोड-उदाहरणों के लिए पूछ रहा है- दार्शनिक रूप से क्यों मायने रखता है, मैं देख सकता हूं कि यह क्यों मायने रखता है। यह निश्चित रूप से अच्छा है अगर एक ही कोड विभिन्न प्लेटफॉर्म पर काम कर सकता है और उसे पुनः लिखने की आवश्यकता नहीं है। – barlop

+0

यहां पोर्टेबल सी ++ :-) का एक उदाहरण है। पूरे स्थान पर Ifdef मैक्रोज़ के उपयोग पर ध्यान दें। http://mxr.mozilla.org/mozilla/source/xpcom/ds/nsCRT.h – gtrak

उत्तर

0

मैं एक साथ कुछ उत्तर

के रख दिया है ..

जबकि मैं उन्हें परीक्षण नहीं किया .. मुझे लगता है कि जवाब के भीतर मेरे लिए कोई मतलब, से अच्छा उदाहरण देखें, ब्रूनो सी में

#include <win32.h> (एक ओएस विशिष्ट लाइन और कोड एक अलग ओएस के लिए फिर से लिखा करना होगा) एक उदाहरण प्रदान की कुछ भी है कि stdio.h में कॉल और कुछ अन्य लोगों का उपयोग कर के लिए सीमित है (पोर्टेबल हैं)

गैरी, int के साथ एक मामले की बात की। सी में, "32-बिट बॉक्स पर एक int 32-बिट है। 64-बिट बॉक्स पर 64-बिट्स पोर्टेबल तरीका int32_t का उपयोग करना है" और सी और असेंबली भाषा के बारे में एक बिंदु .. मैंने पूछा है चारों ओर और पाया कि यदि आप सीमा से आगे बढ़ते हैं, तो यह चक्र 0 पर वापस आ जाता है। इसलिए, यह एक अलग सिस्टम पर संकलन करने और संकलन करने के लिए कोड का मामला होगा, लेकिन शायद इरादे के रूप में काम नहीं कर रहा है, और यह होना चाहिए फिर से लिखा।

Thorbjørn ने विभिन्न CPUs पर असेंबली भाषा के उदाहरणों के लिए एक लिंक प्रदान किया। 32-बिट CPUs के लिए Win32 ASM और 64-बिट के लिए Win64। इसमें प्रत्येक में एक हैलो वर्ल्ड उदाहरण है, और कहता है कि उन्हें परिवर्तित करना आसान नहीं है, क्योंकि "Win32 में, सभी पैरामीटर स्टैक के माध्यम से पारित होते हैं, हालांकि Win64 में वे रजिस्टरों के माध्यम से पारित होते हैं।" उन्होंने कहा कि यह विभिन्न निर्देशों का उपयोग करता है .. मुझे लगता है कि शायद यह उससे भी अधिक है, इस अर्थ में कि यदि यह एक अलग असेंबली भाषा है .. और असेंबली भाषा गैर पोर्टेबिलिटी का एक स्पष्ट मामला है .. इसलिए मैंने इसका उल्लेख नहीं किया सवाल में, लेकिन उस लिंक पर उदाहरण देखना अच्छा है। और यह अच्छा ज्ञान है। कुछ समकालीन असेंबली भाषाओं को अस्पष्ट मशीनों को देखने के लिए अच्छा नहीं है ..

1

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

आपको बहुत दूर देखने की ज़रूरत नहीं है। विंडोज़ का एक छोटा उद्योग यूनिक्स कोड पोर्टिंग डेवलपर्स [और इसके विपरीत] इस सटीक कारण के लिए मौजूद है। उदाहरण चाहते हैं? उन लोगों की तरह चीजें, सी में दूर पॉइंटर्स के बारे में कैसे? या Windows विशिष्ट डीएल बनाने के लिए __declspec (dllexport) का उपयोग करते हुए, जबकि जीसीसी में इनमें से कोई भी नहीं होगा और आपको शेर विकल्प चाहिए?

क्यूटी अस्तित्व में आने से पहले विशेष रूप से सी ++ आधारित जीयूआई करने के साथ सबसे मुश्किल परिदृश्य में से एक था। जीयूआई के भार अभी भी .NET पर किए गए हैं, विरासत कोड एमएफसी पर है और लिनक्स/यूनिक्स के लिए एक्सविंडोज़ में बहुत सारे विरासत कोड हैं। जावा ऐसे मामलों में एक देवता है - अधिकांश सामान मंचों पर पहिया को पुन: आविष्कार किए बिना काम करेंगे।

+0

मैं तार्किक क्या एक पता पॉइंटर है, और तार्किक रूप से कौन से कंपाइलर्स करते हैं और कंप्यूटर कैसे काम करते हैं, लेकिन चूंकि मुझे सी नहीं पता है, मैं निकट/दूर पॉइंटर्स से परिचित नहीं हूं। वे क्या हैं? क्या वे सीधे प्रोग्रामर को निर्दिष्ट करने वाले प्रोग्रामर को शामिल करते हैं? वे ऐसा क्यों करेंगे? मुझे उदाहरण के लिए पता है कि एक चर घोषित करने के लिए आम तौर पर इसकी आवश्यकता नहीं होती है, संकलक इसके साथ सौदा करेगा। – barlop

+0

@barlop इस लिंक को देखें: http: //wiki.answers।कॉम/क्यू/what_are_near_far_and_huge_pointers_in_C कम से कम, वे दिखाते हैं कि कितनी मुश्किल (मुश्किल का उल्लेख नहीं करना) पोर्टिंग कई बार हो सकता है। – Fanatic23

+0

निकट/दूर पॉइंटर्स का उपयोग अब कम से कम 15 वर्षों से नहीं किया जाता है ... (ध्यान दें कि मैं विशेष उदाहरण की आलोचना कर रहा हूं, अवधारणा नहीं) –

9

... जहां सभी के पास उनके प्लेटफॉर्म के लिए एक कंपाइलर विशिष्ट है। तो लाभ उस द्वारा समझाया नहीं गया है।

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

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

पोर्टेबिलिटी के अलावा, वर्चुअल मशीन पर चलने के अन्य फायदे हैं। Java रनटाइम पर देशी मशीन कोड पर जावा बाइटकोड संकलित करने के लिए जावा JIT compiler का उपयोग करता है। जेआईटी कंपाइलर उस विशिष्ट सीपीयू के लिए परिष्कृत ऑप्टिमाइज़ेशन कर सकता है जो प्रोग्राम चल रहा है और यह प्रोफाइलिंग जानकारी का उपयोग कर सकता है जो आगे के समय के कंपाइलर के लिए उपलब्ध नहीं होगा - सिद्धांत रूप में, एक जेआईटी कंपाइलर इसलिए अधिक इष्टतम कोड उत्पन्न कर सकता है एक "सामान्य" कंपाइलर से।

जावा वी एम अलावा, वहाँ अन्य आभासी मशीनों हैं। उदाहरण के लिए, Microsoft .NET CLR (साझा भाषा क्रम) शामिल हैं और वहाँ भी LLVM, जो सी और सी सहित कई अलग अलग भाषाओं के लिए सामने के छोर है है ++ (और सी और सी के लिए भी JIT संकलन के फायदे में लाने के लिए माना जाता है जो ++) ।

+0

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

+1

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

3

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

+0

में एंडियननेस – gtrak

+0

के बारे में भी पढ़ा गया है, मैंने कई वर्षों पहले अंतहीनता को पढ़ा था। बड़ा एंडियन, थोड़ा एंडियन .. इसमें कोई संदेह नहीं है कि आमतौर पर कंपाइलर्स इसे संभालेगा। कोड उस स्तर पर स्मृति का संदर्भ कब देगा? और यदि यह किसी पते को निर्दिष्ट करने की तरह स्मृति को सीधे संदर्भित कर रहा है, तो क्या यह ओएस के माध्यम से नहीं जायेगा और ओएस उस तरह निर्भर हो जाएगा? मेरे पास अभी भी कोई कोड उदाहरण नहीं है .. यह हैलो वर्ल्ड को देखना दिलचस्प होगा जो ऐसा करता है! (जाहिर है कि इसे नहीं करना होगा, लेकिन एक उदाहरण के रूप में) – barlop

+0

इस बारे में सोचें कि जब आप सी पर कोड लिखते हैं तो क्या होता है एक मंच और यह एक अलग कोड के साथ एक मंच पर एक ही कोड के लिए नेटवर्क आईओ करता है। किसी बिंदु पर कहीं आपको इसके बारे में सचेत होना होगा या आपका डेटा खराब हो जाएगा। प्रोसेसर की तुलना में कंपाइलर्स के साथ इसका कम संबंध नहीं है। – gtrak

3

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

gcc (जीएनयू क्रॉस संकलक), उदाहरण के लिए, आप कम या ज्यादा किसी भी मंच के लिए सी कोड संकलन करने देगा। stdio.h और कुछ अन्य लोगों में कॉल का उपयोग करने के लिए सीमित है जो कुछ भी सिद्धांत में ठीक है। हालांकि, अगर आप मुसीबत में बहुत जल्दी के रूप में जल्द से चलाने के रूप में आप में थोड़ा और अधिक कुछ ओएस विशिष्ट है, जो जाता है प्रकट होता है बहुत जल्दी का उपयोग करने की कोशिश करेंगे: जीयूआई, कुछ मैं/हे, थ्रेडिंग, प्रक्रियाओं, नेटवर्किंग।

जैसे ही आप एक #include <win32.h> या अपने सी कोड में इसी तरह के रूप में, आप एक लिनक्स/OSX मंच के लिए यह बंदरगाह के लिए कोड के कुछ हिस्सों के पुनर्लेखन के लिए होगा, इस काम के कुछ स्पष्ट या सीधे संभव नहीं हो सकता।

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

3
बेशक

, यह वर्तमान स्थिति, जहां हर कोई एक संकलक उनके मंच के लिए विशिष्ट है के समान दिखता है।

बात को समझने की जरूरत है कि भले ही वहाँ है एक मंच के लिए एक संकलक विशिष्ट, भाषाओं थोड़े अलग हैं (जब तक यह ठीक उसी संकलक, जो जीसीसी संकलक से दूसरों के लिए दुर्लभ है) है, और यह कि कार्यक्रम जो कार्यक्रम देखते हैं वे काफी अलग हैं। "ओह, हमारे पास 64-बिट पूर्णांक हैं, और आपको ग्राफिक्स इत्यादि आदि करने के लिए X11 का उपयोग करने की आवश्यकता है"। आप एक बहुत बड़ी GNU परियोजना वहाँ मौजूद है कि बस प्रोग्राम (automake) करने के लिए इन मतभेदों को निर्दिष्ट करने के विन्यास से निपटने के लिए कोड में इन बातों को, और सिर्फ इस तथ्य को संभालने के लिए संकेत देना चाहिए कि यह एक छोटी सी बात नहीं है की जरूरत है।

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

+0

मुझे लगता है कि एएमडी 64- बिट प्रोसेसर बनाम 32-बिट प्रोसेसर एक उदाहरण हो सकता है। मैंने अभी भी कोई कोड उदाहरण नहीं देखा है .. उदाहरण के लिए देखना दिलचस्प होगा, एक प्रोग्राम लिखने का एक उदाहरण हैलो दुनिया को लिखना जो 64-बिट सीपीयू पर काम करता है लेकिन 32- बिट सीपीयू – barlop

+0

कि केवल 32 बिट सीपीयू पर उपलब्ध निर्देशों का उपयोग करने की आवश्यकता नहीं है। यहां एक उदाहरण दिया गया है: http://www.codegurus.be/codegurus/Programming/assembler&win64_en.htm –

+0

धन्यवाद .. लेकिन सी में क्या है? – barlop

1

मेरे लिए मुख्य लाभ लाइब्रेरी पोर्टेबिलिटी है। पुस्तकालयों में स्वयं के बीच संस्करण निर्भरता हो सकती है, लेकिन इसके अलावा, एक जेएआर बस काम करता है।

तथाकथित क्लासलोडर नरक है, लेकिन यह लगभग सामान्य नहीं है।

अन्य भाषाओं में, आपको या तो सही लाइब्रेरी बाइनरी मिलनी है, या आपको इसे स्थापित करने के लिए स्रोत डाउनलोड करना होगा।

0

पोर्टेबिलिटी ज्यादातर। वही जावा बाइनरी लिनक्स/मैक/विंडोज पर चल सकती है। प्लस एसपीएआरसी/पीपीसी/x86/x86-64/एआरएम/एमआईपीएस इत्यादि पढ़ें: एक ही बाइनरी। कोई पुनर्मूल्यांकन की आवश्यकता नहीं है। :)

+0

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

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