जावा को C ++ जैसी अन्य भाषाओं की तुलना में अधिक पोर्टेबल क्यों माना जाता है?

Question

जावा डेवलपर्स के लिए "प्रत्येक प्लेटफॉर्म के लिए एक विशिष्ट JRE लिखने" और "++ वाले लोगों के लिए प्रत्येक प्लेटफॉर्म के लिए C ++ कंपाइलर" लिखने के बीच क्या अंतर है?

Answer 1

जावा कहीं भी एक बार चलाने के लिए संकलित है। कहीं भी संकलित करने के लिए C ++ लिखा जाता है।

Comments

वैसे आप स्पष्ट रूप से जीयूआई विकास के साथ बहुत अनुभव नहीं है। (Qt का इंतजार ...)

जो कोई भी दावा करता है कि C ++ "कहीं भी एक बार संकलित है" लिखने के लिए कभी भी C ++ प्रोग्राम को पोर्ट नहीं करना

— पड़ता है

मैं ब्लूराज से सहमत हूं। C ++ प्रोग्राम को पोर्ट करना कंपाइलर को पोर्ट करने की तुलना में बहुत अधिक है। C ++ सबसे अधिक व्यापक रूप से महत्वपूर्ण वातावरण में मौजूद है, जहां इंट के आकार या फ़ाइल सिस्टम के कार्यान्वयन जैसी चीजें इतना बड़ा अंतर ला सकती हैं। पोर्टिंग का मतलब केवल पुनर्मिलन नहीं है।

— रहमू

@ Pubby8 नहीं, पोर्टेबिलिटी के मुद्दे भी सुंदर मानक कोड से आते हैं , जो गैर-मान्य धारणाएं बनाते हैं , जैसे कि एंडियननेस के बारे में धारणाएं (जो आपको बुरा लगता है, आप जावा में भी पीड़ित हो सकते हैं), संरेखण और आकार प्रकार मौलिक।

— आर। मार्टिनो फर्नांडीस

एक बार लिखें, हर जगह डिबग करें।

— भजन

Answer 2

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

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

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

जैसा कि टिप्पणियों में उल्लेख किया गया है, पोर्टेबिलिटी के लिए C ++ का दृष्टिकोण अलग है। एक ओर, यह एक संकलित भाषा है, और उन बायनेरिज़ हमेशा लगभग विशिष्ट प्लेटफ़ॉर्म हैं। तो c ++ एक्जीक्यूटिव कभी भी पोर्टेबल नहीं होंगे (जावा के विपरीत)। दूसरी ओर, संकलक को पोर्ट करना कभी-कभी पर्याप्त हो सकता है। समुदाय ने पाया है कि संकलक के साथ-साथ भाषा के कुछ मुख्य पुस्तकालयों को पोर्ट करके, स्रोत कोड (और बायनेरी नहीं) पोर्टेबल हो सकते हैं।

हालांकि, C ++ व्यापक रूप से संकलक, कर्नेल, रीयल-टाइम सिस्टम, एम्बेडेड सिस्टम जैसी महत्वपूर्ण प्रणालियों में उपयोग किया जाता है, ... पोर्ट ++ के बारे में बात करते समय C ++ का "निम्न स्तर" पहलू है जिसे अनदेखा नहीं किया जा सकता है।

Comments

पोर्टेबिलिटी एक मिथक नहीं है। सही पोर्टेबिलिटी है।

— मैलकम

"उसका वह स्थान जहां जावा C ++ से बहुत अलग है, जहां प्रत्येक एप्लिकेशन" मशीन-विशिष्ट "है, और कोड को निर्दिष्ट किए बिना पोर्ट नहीं किया जा सकता है।" यह सच नहीं है, यह निर्भरता पर निर्भर करता है। यदि आप अपने लक्ष्य के लिए पोर्टेबल स्रोतों के साथ केवल मानक पुस्तकालय और पुस्तकालयों का उपयोग करते हैं, तो आप एक बार कोड करते हैं और प्रत्येक लक्ष्य पर संकलन करते हैं। यदि आप किसी ऐसी चीज़ को कोड करते हैं, जिसे C ++ में कोड को संशोधित किए बिना पोर्ट किया जा सकता है, तो केवल एक चीज जिसे आपको संशोधित करने की आवश्यकता हो सकती है वह है बिल्ड स्क्रिप्ट। यह सभी मामलों में सच भी नहीं है।

— स्लेम

आइए यह न भूलें कि C ++ को उच्च-स्तरीय और निम्न स्तर की भाषा दोनों के रूप में उपयोग किया जा सकता है। बहुत सारे C ++ कोड का उपयोग उन कार्यक्रमों में किया जाता है जहां 32 बिट इंट 64-बिट इंट से बहुत अलग होता है। उच्च-स्तर हमेशा पोर्टेबल होगा, ज़ाहिर है। लेकिन यह एक C ++ के सामान्यीकरण से बहुत दूर है

— rahmu

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

— 22

बस यह सुनिश्चित करने के लिए कि मैं स्पष्ट हूं: मैं यह नहीं कहता कि सभी C ++ कोड पोर्टेबल है, मैं कह रहा हूं कि जैसा कि आपका कथन गलत है। आप इसे कुछ इस तरह से ठीक करना चाह सकते हैं: "यह वह जगह है जहाँ जावा सी ++ से बहुत अलग है, जहां प्रत्येक एप्लिकेशन" मशीन-विशिष्ट "है, और कोड को संशोधित किए बिना पोर्ट नहीं किया जा सकता है, या यदि कोड वास्तव में पोर्टेबल है और बिल्ड है स्क्रिप्ट कम से कम एक संकलन के बिना, नए लक्ष्य का प्रबंधन करती है। "

— 22

Answer 3

यह सिर्फ भाषा नहीं है - यह पुस्तकालय है।

जावा और सी ++ दोनों क्रॉस-प्लेटफॉर्म लाइब्रेरी प्रदान करते हैं। जावा एक समृद्ध सेट प्रदान करता है।

Comments

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

— मार्टिन यॉर्क

C ++ के लिए पुस्तकालयों के ब्रह्मांड में जावा के मानक पुस्तकालयों की तुलना करना वास्तव में एक वैध तुलना नहीं है। जावा एक समृद्ध सेट प्रदान करता है, चाहे आप प्रत्येक के मानक पुस्तकालयों की तुलना कर रहे हों, या आप प्रत्येक के पुस्तकालयों के ब्रह्मांड की तुलना कर रहे हों।

— एंडी थॉमस

निश्चित रूप से इससे असहमत हैं। जावा लाइब्रेरी में कुछ भी उपलब्ध है, कुछ लाइब्रेरी में C ++ द्वारा उपयोग के लिए पहले से ही उपलब्ध है। मुझे यह तथ्य पसंद है कि जावा में यह सब एक जगह पर है, लेकिन यह कहना कि यह अधिक समृद्ध है, यह सच नहीं है। हो सकता है कि आप जिस विशेषण की तलाश कर रहे हैं, वह `अधिक एकीकृत 'हो

— मार्टिन

+1 फिर से बढ़ेगा। मुझे लगता है कि पुस्तकालय पोर्टेबिलिटी का सबसे बड़ा कारक हैं। यदि आप C / C ++ में काम कर रहे हैं और शुद्ध संगणना के अलावा कुछ भी कर रहे हैं, तो वहाँ पुस्तकालयों (विशेष रूप से, सिस्टम लाइब्रेरी के कुछ हिस्सों) होंगे जो विंडोज और यूनिक्स के बीच मौलिक रूप से भिन्न होते हैं, और यूनिक्स के विभिन्न स्वादों के बीच सूक्ष्म रूप से भिन्न होते हैं। जिससे पोर्टिंग कठिन हो जाती है। जावा में मूल रूप से वह समस्या नहीं है।

— टॉम एंडरसन

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

— मार्टिन यॉर्क

Answer 4

अंतर यह है कि जावा किसी भी प्लेटफ़ॉर्म पर फिर से स्थापित किए बिना चलेगा । प्रत्येक प्लेटफ़ॉर्म के लिए C ++ कंपाइलर का होना एक समान नहीं है।

Answer 5

"अंतर है ...", या बहुत समान के साथ शुरू होने वाले सभी उत्तर मूल रूप से गलत हैं (क्षमा करें, लेकिन ऐसा ही जीवन है)। दोनों के बीच वास्तव में दो अलग-अलग अंतर हैं।

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

दूसरा यह है कि जावा (कम से कम प्रयास) यह आश्वासन देता है कि सभी सही ढंग से लिखे गए जावा पोर्टेबल होंगे। कम से कम सिद्धांत में, आपको कोई भी कोड लिखने में सक्षम नहीं होना चाहिए जो पोर्टेबल नहीं है।

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

Comments

C ++ पीसीआई बस और न ही हार्डवेयर के बारे में कुछ भी नहीं जानता है।

— निक्को ४

बेशक, यह प्लेटफ़ॉर्म विशिष्ट चीजें नहीं हैं, जिन्हें प्लेटफ़ॉर्म विशिष्ट पुस्तकालयों में शामिल करना होगा। जैसे जावा में जरूरत पड़ने पर प्लेटफॉर्म विशिष्ट पुस्तकालय हो सकते हैं।

— 8 अक्टूबर

@ निक्को: यह इसके बारे में कुछ भी नहीं जानता है, लेकिन यह आपको इसके बारे में जानने के लिए उपयोग करने की अनुमति देता है।

— जेरी कॉफिन

@jwenting: अंतर यह है कि आप प्लेटफ़ॉर्म-विशिष्ट पुस्तकालयों को C ++ में लिख सकते हैं , लेकिन आप आमतौर पर उन्हें जावा में नहीं लिख सकते ।

— जेरी कॉफिन

Answer 6

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

JVM अपने आप में बहुत पोर्टेबल नहीं है। एक उच्च-प्रदर्शन करने वाले JVM को किसी अन्य प्लेटफ़ॉर्म या CPU आर्किटेक्चर में पोर्ट करना एक हेक्युलियन कार्य है।

Comments

उस अंतिम वाक्य के लिए +1!

— रहमू

Answer 7

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

Comments

है ना? C ++ कंपाइलर हैं जो JVM को लक्षित करते हैं और जावा कंपाइलर हैं जो मूल कोड को लक्षित करते हैं। क्या आप C ++ भाषा विनिर्देश के विशिष्ट खंड का हवाला दे सकते हैं जो कहता है कि C ++ प्रोग्राम को स्रोत कोड या प्लेटफ़ॉर्म-विशिष्ट बायनेरिज़ के रूप में वितरित किया जाना चाहिए?

— जोर्ग डब्ल्यू मित्तग

वहाँ, मैंने अपने उत्तर को कम निश्चित भाषा का उपयोग करने के लिए संपादित किया

— कॉलिन

Answer 8

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

उदाहरण के लिए, दिया गया

long thing1(int x) {
  return (x+1)-1L;
}
double thing2(int x, float y) {
  return x/y;
}

के मूल्यों thing1(2147483647)और thing2(1123456700,11234567.0f)-2147483649L और 99.9999923706054688, होना भी आवश्यक है क्रमशः, भले ही हिसाब से सही मान 2147483647L और 100.0, और हो सकता है यहां तक कि कुछ प्लेटफार्मों कोड पर हालांकि उत्पन्न करने के लिए संख्यानुसार-गलत परिणाम धीमी कोड सही उत्पन्न करने के लिए की तुलना में किया जाएगा परिणाम (कुछ 64-बिट प्लेटफ़ॉर्म पर, (x + 1) के बाद रैपिंग व्यवहार के लिए एक अतिरिक्त निर्देश की आवश्यकता होगी, और 8x87 प्लेटफ़ॉर्म पर, 1123456700 के मूल्य को मजबूर करने के लिए गोल करने की floatआवश्यकता होगी, बस लोडिंग के साथ एक अतिरिक्त निर्देश की आवश्यकता होगी) यह सीधे एक विस्तारित-सटीक रजिस्टर के लिए)।

Comments

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

@ स्नोमैन: आपको चुने गए विशेष उदाहरण कैसे पसंद हैं? व्यक्तिगत रूप से अगर मैं एक ऐसी भाषा डिज़ाइन कर रहा था, जिसमें मैंने या तो उदाहरण नहीं दिया, तो जावा के मूल्य को बिना संकुचित कास्ट के उपयोग के (int)पहले उदाहरण के लिए पहले उदाहरण के सब- (x+1)एक्सप्रेशन के लिए, floatदूसरे उदाहरण के xपैरामीटर के लिए, लेकिन स्पष्ट रूप से मैंने भाषा डिज़ाइन नहीं की ।

— सुपरकैट

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

Answer 9

सहायक उपकरणों के लिए काम की मात्रा वास्तव में समान है, अंतर कहीं और निहित है। एक बार एक प्लेटफ़ॉर्म के लिए C ++ प्रोग्राम संकलित कर लेने के बाद, यदि आप इसे किसी अन्य प्लेटफ़ॉर्म पर उपयोग करना चाहते हैं, तो आपको इसे फिर से संकलित करना होगा। हालांकि, जब एक जावा प्रोग्राम संकलित किया गया है, तो आप इसे फिर से चालू किए बिना रनटाइम वातावरण के साथ किसी अन्य प्लेटफ़ॉर्म पर ले जा सकते हैं।

Answer 10

"पोर्टेबिलिटी एक मिथक है?" शीर्षक के जवाब में, "पोर्टेबिलिटी, जावा या सी ++ में बेहतर है" के बजाय, मैं कहूंगा कि आंशिक पोर्टेबिलिटी संभव है, लेकिन पूर्ण पोर्टेबिलिटी यह एक मिथक है।

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

और उन चौखटों में लाइब्रेरी, डेटाबेस, ग्राफिकल इंटरफेस शामिल हैं।

कौन सी प्रोग्रामिंग भाषा, या कौन सी प्रोग्रामिंग रूपरेखा अधिक पोर्टेबल है?

खैर, यह निर्भर करता है, आपके ऐप पर। हासिल करने की कोशिश कर रहा है।

Answer 11

बात यह है कि "आप" उस JRE को न लिखें जिसे आप जावा कोड लिखते हैं जो किसी भी JRE पर चलता है । "आप" लिख सकता हूँ सी ++ कोड जो कर सकते हैं द्वारा परिवर्तन की आवश्यकता आप इससे पहले कि यह एक और मंच पर संकलित कर देगा।

Answer 12

बहुत से लोग भूल जाते हैं या जावा की वास्तविकता को ध्यान में नहीं रखते हैं जब वे कहते हैं कि "यह 100% पोर्टेबल है" या इस तरह के वाक्यांश।

बहुत से सभी प्रमुख निगमों / सॉफ्टवेयर हाउस में हाल ही में एक संबद्ध JRE के साथ जावा के कम से कम 1 घर-निर्मित कार्यान्वयन था और कुछ अभी भी इसे बनाए रखते हैं, उदाहरण के लिए Microsoft, IBM और Apple सभी के अपने स्वयं के संस्करण जावा के अपने को दर्शाते हैं अपने विचारों और विचारों पर जहां उद्योग और ऐसी भाषा को जाना चाहिए।

"पोर्टेबल" के लिए यह कैसा है? एक JRE कहीं भी आप बारी।

और यह सूर्य / ओरेकल क्या कर रहा था पर विचार किए बिना है।

पोर्टेबिलिटी के संदर्भ में जावा कोड वास्तव में C और C ++ से बहुत दूर क्यों नहीं है, GUI और ग्राफिकल सर्वर हैं, Apple ने अपने JRE के लिए GUI फ्रेमवर्क का एक गैर-मानक कार्यान्वयन किया था, जिसके परिणामस्वरूप बहुत सारे थे जो लोग Apple मशीनों के लिए जावा का उपयोग करके GUI बनाना / पोर्ट करना चाहते थे, उनके लिए सिरदर्द और दोहरा काम है और उन्हें मूल रूप से क्वार्ट्ज ("उत्तोलन" और उच्च स्तरीय भाषाओं के संदर्भ में) से निपटने के लिए मजबूर किया गया था?)।

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

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

मुझे अभी भी एक एकल गैर-तुच्छ जावा एप्लिकेशन ढूंढना है जिसमें कोड या कार्यक्षमता की प्रत्येक पंक्ति के लिए केवल 1 संस्करण है (किसी भी प्लेटफ़ॉर्म विशिष्ट सामान के बिना उर्फ) और यह सभी प्रमुख JRE के बीच 100% पोर्टेबल है।