जावा की आलोचना

From Vigyanwiki

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


भाषा वाक्यविन्यास और शब्दार्थ

चेक्ड एक्सेप्शन्स

Further information: चेक्ड एक्सेप्शन्स

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

जेनेरिक्स

जब सामान्य प्रोग्रामिंग को जावा 5.0 में जोड़ा गया था, तो पहले से ही कक्षाओं का एक बड़ा ढांचा उपस्थित था, जिनमें से कई पहले से ही प्रतिवाद थे, इसलिए माइग्रेशन अनुकूलता और इनके पुन: उपयोग की अनुमति देने के लिए जेनेरिक को जावा प्रकार के क्षरण के साथ समस्याओं में जेनेरिक का उपयोग करके लागू किया गया था। उपलब्ध कक्षाएं इसने अन्य भाषाओं की तुलना में प्रदान की जा सकने वाली सुविधाओं को सीमित कर दिया।[2][3]चूँकि जेनेरिक को प्रकार मिटाना का उपयोग करके कार्यान्वित किया जाता है, इसलिए टेम्पलेट पैरामीटर E का वास्तविक प्रकार रन टाइम पर अनुपलब्ध होता है। इस प्रकार, जावा में निम्नलिखित संचालन संभव नहीं हैं:[4] 

public class MyClass<E> {
    public static void myMethod(Object item) {
        if (item instanceof E) {  //Compiler error
            ...
        }
        E item2 = new E();   //Compiler error
        E[] iArray = new E[10]; //Compiler error
    }
}

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

class Nullless<T, U> {
  class Constrain<B extends U> {}
  final Constrain<? super T> constrain;
  final U u;

  Nullless(T t) {
    u = coerce(t);
    constrain = getConstrain();
  }

  <B extends U>
  U upcast(Constrain<B> constrain, B b) {
    return b;
  }
  U coerce(T t) {
    return upcast(constrain, t);
  }
  Constrain<? super T> getConstrain() {
    return constrain;
  }

  public static void main(String[] args) {
    String zero = new Nullless<Integer,String>(0).u;
  }
}


संज्ञा-उन्मुखता

See also: ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग § आलोचना

प्रारूप द्वारा, जावा प्रोग्रामर्स को उस समस्या को विचार करने के लिए प्रेरित करता है जहाँ नाम (क्लास) एक दूसरे के साथ अंतर्क्रिया करते हैं, और क्रियाएं उस नाम पर कार्यान्वित की जा सकती हैं या उसके द्वारा की जा सकती हैं। [5]स्टीव येग्गे का विचार है कि इसके कारण भाषा की व्यक्तिगता पर अनावश्यक प्रतिबंध होता है क्योंकि एक क्लास में कई फ़ंक्शन हो सकते हैं जो उस पर कार्यान्वित हो सकते हैं, लेकिन एक फ़ंक्शन एक क्लास से बंधा होता है और कभी भी एकाधिक प्रकारों पर कार्यान्वित नहीं हो सकता है।[6]

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

अहस्ताक्षरित पूर्णांक प्रकार

जावा में मूल अहस्ताक्षरित पूर्णांक प्रकारों का अभाव है। अहस्ताक्षरित डेटा अक्सर C (प्रोग्रामिंग भाषा) में लिखे गए प्रोग्रामों से उत्पन्न होता है, और इन प्रकारों की कमी C और Java के बीच सीधे डेटा इंटरचेंज को रोकती है। क्रिप्टोग्राफी सहित कई संख्यात्मक प्रसंस्करण क्षेत्रों में अहस्ताक्षरित बड़ी संख्याओं का भी उपयोग किया जाता है, जो इन कार्यों के लिए जावा का उपयोग करने को और अधिक असुविधाजनक बना सकता है।[7] हालाँकि रूपांतरण कोड और बड़े डेटा प्रकारों का उपयोग करके इस समस्या से निपटना संभव है, लेकिन यह अहस्ताक्षरित डेटा को संभालने के लिए जावा का उपयोग करना बोझिल बना देता है। जबकि 32-बिट हस्ताक्षरित पूर्णांक का उपयोग 16-बिट अहस्ताक्षरित पूर्णांक को दोषरहित रूप से रखने के लिए किया जा सकता है, और 64-बिट हस्ताक्षरित पूर्णांक का उपयोग 32-बिट अहस्ताक्षरित पूर्णांक को रखने के लिए किया जा सकता है, 64-बिट अहस्ताक्षरित पूर्णांक को रखने के लिए कोई बड़ा प्रकार नहीं है। सभी मामलों में, खपत की गई मेमोरी दोगुनी हो सकती है, और आम तौर पर दो के पूरक अतिप्रवाह पर निर्भर किसी भी तर्क को फिर से लिखा जाना चाहिए। यदि सार निकाला जाए, तो फ़ंक्शन कॉल कई परिचालनों के लिए आवश्यक हो जाते हैं जो कुछ अन्य भाषाओं के मूल हैं। वैकल्पिक रूप से, समान आकार के अहस्ताक्षरित पूर्णांकों का अनुकरण करने के लिए जावा के हस्ताक्षरित पूर्णांकों का उपयोग करना संभव है, लेकिन इसके लिए बिटवाइज़ संचालन के विस्तृत ज्ञान की आवश्यकता होती है।[8] JDK 8 में अहस्ताक्षरित पूर्णांक प्रकारों के लिए कुछ समर्थन प्रदान किया गया था, लेकिन अहस्ताक्षरित बाइट्स के लिए नहीं और जावा भाषा में कोई समर्थन नहीं था।[9]


ऑपरेटर ओवरलोडिंग

उपयोगकर्ता-परिभाषित ऑपरेटरों का समर्थन नहीं करने के लिए जावा की आलोचना की गई है।[citation needed] ऑपरेटर ओवरलोडिंग कर रहा है से पठनीयता में सुधार होता है,[10] इसलिए इसकी अनुपस्थिति जावा कोड को कम पठनीय बना सकती है, विशेष रूप से गणितीय वस्तुओं, जैसे जटिल संख्याओं और मैट्रिक्स का प्रतिनिधित्व करने वाली कक्षाओं के लिए। जावा में ऑपरेटर का केवल एक गैर-संख्यात्मक उपयोग होता है: + और += स्ट्रिंग संयोजन के लिए. हालाँकि, इसे कंपाइलर द्वारा कार्यान्वित किया जाता है, जो स्ट्रिंगबिल्डर इंस्टेंस बनाने के लिए कोड उत्पन्न करता है। उपयोगकर्ता-परिभाषित ऑपरेटर ओवरलोड बनाना असंभव है।

मिश्रित मान प्रकार

जावा में मिश्रित मूल्य प्रकारों का अभाव है, जैसे सी में स्ट्रक्चर (सी प्रोग्रामिंग भाषा), डेटा के बंडल जिन्हें संदर्भों के माध्यम से अप्रत्यक्ष रूप से बजाय सीधे हेरफेर किया जाता है। मूल्य प्रकार कभी-कभी संदर्भ वाले वर्गों की तुलना में तेज़ और छोटे हो सकते हैं।[11][12][13] उदाहरण के लिए, जावा HashMap संदर्भों की एक श्रृंखला के रूप में कार्यान्वित किया गया है HashMap.Entry वस्तुएं,[14] जिसमें बदले में कुंजी और मूल्य वस्तुओं के संदर्भ शामिल होते हैं। किसी चीज़ को खोजने के लिए अकुशल डबल डीरेफ़रेंसिंग की आवश्यकता होती है। अगर Entry एक मान प्रकार थे, सरणी सीधे कुंजी-मान जोड़े को संग्रहीत कर सकती थी, पहले संकेत को समाप्त कर सकती थी, संदर्भ की स्थानीयता को बढ़ा सकती थी और मेमोरी उपयोग और विखंडन (कंप्यूटर) #मेमोरी विखंडन को कम कर सकती थी। इसके अलावा, यदि जावा सामान्य आदिम प्रकारों का समर्थन करता है, तो अप्रत्यक्षता के दोनों स्तरों को हटाते हुए, कुंजियाँ और मान सीधे सरणी में संग्रहीत किए जा सकते हैं।

बड़ी सारणियाँ

2 की सरणियों का समर्थन न करने के लिए जावा की आलोचना की गई है31(लगभग 2.1 अरब) या अधिक तत्व।[15][16] यह भाषा की एक सीमा है; जावा भाषा विशिष्टता, धारा 10.4, बताती है कि:

सरणी को पूर्णांक मानों द्वारा अनुक्रमित किया जाना चाहिए... एक लंबे सूचकांक मान के साथ एक सरणी घटक तक पहुंचने का प्रयास एक संकलन-समय त्रुटि में परिणामित होता है।[17] </ब्लॉककोट>

बड़े सरणियों का समर्थन करने के लिए JVM में बदलाव की भी आवश्यकता होगी।[18] यह सीमा 2 बिलियन तत्वों तक सीमित होने वाले संग्रह जैसे क्षेत्रों में स्वयं प्रकट होती है[19] और 2 जीबी से बड़े निरंतर फ़ाइल खंडों को मेमोरी मैप करने में असमर्थता।[20] जावा में (इसके 2डी सरणियों के अलावा) बहुआयामी सरणियों (एकल अप्रत्यक्ष द्वारा एक्सेस की गई मेमोरी के लगातार आवंटित एकल ब्लॉक) का भी अभाव है, जो वैज्ञानिक और तकनीकी कंप्यूटिंग के लिए प्रदर्शन को सीमित करता है।[12] जावा में सरणियों को आरंभ करने का कोई प्रभावी तरीका नहीं है। किसी सरणी की घोषणा करते समय, JVM इसे निर्देशों के साथ बाइटकोड में संकलित करता है जो रन टाइम पर इसके तत्वों को एक-एक करके सेट करता है। चूँकि जावा विधियाँ 64KB से बड़ी नहीं हो सकतीं, कोड में सीधे निर्दिष्ट मानों के साथ मामूली आकार की सारणियाँ भी त्रुटि संदेश फेंकेंगी: संकलन पर कोड बहुत बड़ा है।[21][better source needed]

आदिम और सरणियों का एकीकरण

ऐरे और प्रिमिटिव कुछ हद तक विशेष हैं और इन्हें कक्षाओं से अलग तरीके से व्यवहार करने की आवश्यकता है। इसकी आलोचना की गई है[22] क्योंकि सामान्य प्रयोजन पुस्तकालय बनाते समय इसके लिए कई प्रकार के कार्यों की आवश्यकता होती है।

समानांतरता

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

क्रमांकन

जावा ऑब्जेक्ट क्रमांकन के लिए एक तंत्र प्रदान करता है, जहां किसी ऑब्जेक्ट को बाइट्स के अनुक्रम के रूप में दर्शाया जा सकता है जिसमें उसके डेटा फ़ील्ड के साथ-साथ उसके और उसके फ़ील्ड के बारे में प्रकार की जानकारी शामिल होती है। किसी ऑब्जेक्ट को क्रमबद्ध करने के बाद, इसे बाद में डीसेरिएलाइज़ किया जा सकता है; अर्थात्, उस प्रकार की जानकारी और बाइट्स जो उसके डेटा का प्रतिनिधित्व करते हैं, का उपयोग ऑब्जेक्ट को मेमोरी में फिर से बनाने के लिए किया जा सकता है।[24] इससे बहुत गंभीर सैद्धांतिक और वास्तविक सुरक्षा जोखिम पैदा होते हैं।[25][26]


तैरनेवाला स्थल अंकगणित

हालाँकि जावा का फ़्लोटिंग पॉइंट अंकगणित काफी हद तक IEEE 754 (बाइनरी अस्थिर बिन्दु अंकगणित के लिए मानक) पर आधारित है, कुछ अनिवार्य मानक सुविधाएँ इसका उपयोग करते समय भी समर्थित नहीं हैं strictfp संशोधक, जैसे अपवाद फ़्लैग और निर्देशित राउंडिंग। IEEE 754 द्वारा परिभाषित विस्तारित परिशुद्धता प्रकार (और कई प्रोसेसर द्वारा समर्थित) जावा द्वारा समर्थित नहीं हैं।[27][28][29]


टुपल्स की कमी

जावा मूल रूप से टुपल्स का समर्थन नहीं करता है, जिसके परिणामस्वरूप तीसरे पक्ष के कार्यान्वयन का प्रसार होता है जिसे प्रोग्रामर द्वारा आयात और नियंत्रित किया जाना चाहिए।[30]


लैम्ब्डा अभिव्यक्ति

जब तक जावा 8 ने अनाम फ़ंक्शन पेश नहीं किया, तब तक एक विधि को किसी अन्य विधि के पैरामीटर के रूप में पास करना मुश्किल था।

कोड और हार्डवेयर के बीच सार संबंध

2008 में संयुक्त राज्य अमेरिका के रक्षा विभाग के सेंटर सॉफ्टवेयर टेक्नोलॉजी सपोर्ट ने जर्नल ऑफ डिफेंस सॉफ्टवेयर इंजीनियरिंग में एक लेख प्रकाशित किया जिसमें पहली भाषा के रूप में सिखाई जाने वाली जावा की अनुपयुक्तता पर चर्चा की गई। नुकसान यह था कि छात्रों को स्रोत प्रोग्राम और हार्डवेयर वास्तव में क्या करेगा, के बीच संबंध के बारे में कोई एहसास नहीं था और जो लिखा गया है उसकी रन-टाइम लागत की भावना विकसित करने में असमर्थता थी क्योंकि यह जानना बेहद कठिन है कि कोई भी विधि कॉल क्या करेगी अंततः निष्पादित करें।[31] 2005 में जोएल स्पोल्स्की ने अपने निबंध द पेरिल्स ऑफ जावास्कूल्स में जावा को विश्वविद्यालयों के पाठ्यक्रम के अत्यधिक केंद्रित हिस्से के रूप में आलोचना की।[32] नेड बैचेल्डर जैसे अन्य लोग, भाषा के उन हिस्सों की आलोचना करने के लिए स्पॉल्स्की से असहमत हैं, जिन्हें समझना उनके लिए मुश्किल था, उनका दावा है कि स्पॉल्स्की की टिप्पणी एक 'व्यक्तिपरक शेख़ी' से अधिक थी।[33]


प्रदर्शन

Further information: Java performance

2000 से पहले, जब हॉटस्पॉट (वर्चुअल मशीन) को जावा 1.3 में लागू किया गया था, तो इसके प्रदर्शन की कई आलोचनाएँ हुई थीं। जावा को अनुकूलित मूल कोड के साथ तुलनीय गति से चलने के लिए प्रदर्शित किया गया है, और आधुनिक जेवीएम कार्यान्वयन कंप्यूटर भाषा बेंचमार्क गेम उपलब्ध सबसे तेज़ भाषा प्लेटफार्मों में से एक है - आमतौर पर सी और सी ++ की तुलना में तीन गुना से अधिक धीमा नहीं है।[34] शुरुआती संस्करणों से प्रदर्शन में काफी सुधार हुआ है।[35] कुछ अनुकूलित परीक्षणों में देशी कंपाइलरों के सापेक्ष जेआईटी कंपाइलरों का प्रदर्शन काफी समान दिखाया गया है।[35][36][37] जावा बाइटकोड को या तो वर्चुअल मशीन द्वारा रन टाइम पर व्याख्या किया जा सकता है, या लोड समय पर संकलित किया जा सकता है या मूल कोड में रन टाइम किया जा सकता है जो सीधे कंप्यूटर के हार्डवेयर पर चलता है। मूल निष्पादन की तुलना में व्याख्या धीमी है, लेकिन लोड समय या रन टाइम पर संकलन में प्रारंभिक प्रदर्शन जुर्माना होता है। आधुनिक जेवीएम कार्यान्वयन सभी संकलन दृष्टिकोण का उपयोग करते हैं, इसलिए प्रारंभिक स्टार्टअप समय के बाद प्रदर्शन मूल कोड के समान होता है।

गेम डिजाइनर और प्रोग्रामर जॉन डी. कार्मैक ने 2005 में सेलफोन पर जावा के बारे में निष्कर्ष निकाला: सबसे बड़ी समस्या यह है कि जावा वास्तव में धीमा है। शुद्ध सीपीयू/मेमोरी/डिस्प्ले/संचार स्तर पर, अधिकांश आधुनिक सेल फोन गेम ब्वॉय एडवांस की तुलना में काफी बेहतर गेमिंग प्लेटफॉर्म होने चाहिए। जावा के साथ, अधिकांश फोन पर आपके पास मूल 4.77 मेगाहर्ट्ज (एसआईसी) आईबीएम पीसी की सीपीयू शक्ति और हर चीज पर खराब नियंत्रण रह जाता है।[38]


सुरक्षा

Further information: Java security

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

2010 में, ओरेकल सहित जावा कार्यान्वयन द्वारा उपयोग किए जाने वाले सैंडबॉक्सिंग तंत्र में सुरक्षा खामियों को लक्षित करने वाले दुर्भावनापूर्ण सॉफ़्टवेयर में उल्लेखनीय वृद्धि हुई थी। ये खामियाँ अविश्वसनीय कोड को सैंडबॉक्स प्रतिबंधों को बायपास करने की अनुमति देती हैं, जिससे उपयोगकर्ता पर हमला होता है। सुरक्षा अद्यतनों द्वारा खामियाँ ठीक कर दी गईं, लेकिन अद्यतनों के बिना भी मशीनों पर उनका शोषण किया गया।[40] आलोचकों ने सुझाव दिया है कि उपयोगकर्ता अपने जावा इंस्टॉलेशन को अपडेट न करें क्योंकि वे नहीं जानते कि यह उनके पास है, या उन्हें कैसे अपडेट किया जाए। कई संगठन उपयोगकर्ताओं द्वारा सॉफ़्टवेयर इंस्टॉलेशन को प्रतिबंधित करते हैं, लेकिन अपडेट को तैनात करने में धीमे होते हैं।[40][41] ज्ञात सुरक्षा बगों के लिए तुरंत अपडेट उपलब्ध नहीं कराने के लिए Oracle Corporation की आलोचना की गई है।[42] जब ओरेकल ने अंततः जावा 7 में व्यापक रूप से उपयोग की गई खामियों के लिए एक पैच जारी किया, तो उसने उपयोगकर्ताओं की मशीनों से जावा 6 को हटा दिया, बावजूद इसके कि एंटरप्राइज़ अनुप्रयोगों द्वारा इसका व्यापक रूप से उपयोग किया जा रहा था, जिसके बारे में ओरेकल ने कहा था कि वे खामियों से प्रभावित नहीं थे।[43] 2007 में, मार्क पिस्तोइया के नेतृत्व में एक शोध दल ने जावा सुरक्षा मॉडल की एक और महत्वपूर्ण खामी को उजागर किया,[44] स्टैक निरीक्षण के आधार पर। जब एक सुरक्षा-संवेदनशील संसाधन तक पहुंच प्राप्त की जाती है, तो सुरक्षा प्रबंधक कोड को ट्रिगर करता है जो कॉल स्टैक पर चलता है, यह सत्यापित करने के लिए कि उस पर प्रत्येक विधि के कोडबेस के पास संसाधन तक पहुंचने का अधिकार है। ऐसा कन्फ्यूज्ड डिप्टी समस्या को रोकने के लिए किया जाता है, जो हर बार तब होती है जब एक वैध, अधिक विशेषाधिकार प्राप्त कार्यक्रम को दूसरे द्वारा अपने अधिकार का दुरुपयोग करने के लिए धोखा दिया जाता है। भ्रमित-डिप्टी समस्या एक विशिष्ट प्रकार की विशेषाधिकार वृद्धि है। पिस्तोइया ने देखा कि जब सुरक्षा-संवेदनशील संसाधन तक पहुंच बनाई जाती है, तो संसाधन प्राप्त करने के लिए जिम्मेदार कोड अब स्टैक पर नहीं हो सकता है। उदाहरण के लिए, अतीत में निष्पादित एक विधि ने किसी ऑब्जेक्ट फ़ील्ड के मान को संशोधित किया हो सकता है जो यह निर्धारित करता है कि किस संसाधन का उपयोग करना है। निरीक्षण के समय वह विधि कॉल स्टैक पर नहीं रह सकती है।

कुछ अनुमतियाँ परोक्ष रूप से जावा के समतुल्य हैं AllPermission. इनमें वर्तमान सुरक्षा प्रबंधक को बदलने की अनुमति (और इसे ऐसे प्रबंधक से बदलना जो संभावित रूप से स्टैक निरीक्षण को बायपास कर सकता है), कस्टम क्लास लोडर को इंस्टेंट करने और उपयोग करने की अनुमति (जो संबद्ध करना चुन सकता है) शामिल है AllPermission इसे लोड करने पर एक दुर्भावनापूर्ण वर्ग के लिए), और एक कस्टम अनुमति बनाने की अनुमति (जो खुद को उतना शक्तिशाली घोषित कर सकती है)। AllPermission इसके माध्यम से implies तरीका)। ये मुद्दे जावा सुरक्षा पर पिस्तोइया की दो पुस्तकों में प्रलेखित हैं: -4 जावा 2 नेटवर्क सुरक्षा (द्वितीय संस्करण) और एंटरप्राइज जावा सुरक्षा।

समानांतर संस्थापन

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

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

जावा 7 ने अपने पुराने संस्करणों को अपडेट किया, लेकिन जावा 6 या उससे पहले के संस्करणों को अपडेट नहीं किया।[45]


स्वचालित अपडेट

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

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

जेआईटी संबंधित सुरक्षा चुनौतियाँ और संभावित कारनामे

Further information: Just-in-time compilation § Security

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

यह भी देखें

  • जावा और सी++ की तुलना
  • जावा और सी शार्प की तुलना|जावा और सी# की तुलना
  • जावा और .NET प्लेटफॉर्म की तुलना
  • जावा प्रदर्शन
  • एक बार लिखो, कहीं भी दौड़ो
  • स्काला (प्रोग्रामिंग भाषा), जावा की आलोचनाओं को संबोधित करने के लिए प्रारूपित की गई एक प्रोग्रामिंग भाषा

टिप्पणियाँ

  1. ↑ Wong, William (2002-05-27). "Write Once, Debug Everywhere". electronicdesign.com. Archived from the original on 2009-03-21. Retrieved 2008-08-03. So far, the "write-once, run-everywhere" promise of Java hasn't come true. The bulk of a Java application will migrate between most Java implementations, but taking advantage of a VM-specific feature causes porting problems.
  2. ↑ "जावा में जेनेरिक". Object Computing, Inc. Archived from the original on 2 January 2007. Retrieved 9 December 2006.
  3. ↑ "What's Wrong With Java: Type Erasure". 2006-12-06. Archived from the original on 22 July 2012. Retrieved 2006-12-09.
  4. ↑ "Type Erasure".
  5. ↑ "जावा एसई विशिष्टताएँ".
  6. ↑ Yegge, Steve. "संज्ञा के साम्राज्य में निष्पादन".
  7. ↑ "Java libraries should provide support for unsigned integer arithmetic". Bug Database, Sun Developer Network. Oracle. Retrieved 2011-01-18.
  8. ↑ Owen, Sean R. (2009-11-05). "जावा और अहस्ताक्षरित int, अहस्ताक्षरित लघु, अहस्ताक्षरित बाइट, अहस्ताक्षरित लंबा, आदि (या बल्कि, इसकी कमी)". Retrieved 2010-10-09.
  9. ↑ "Unsigned Integer Arithmetic API now in JDK 8 (Joseph D. Darcy's Oracle Weblog)". Retrieved 15 May 2016.
  10. ↑ "C++ ऑपरेटर ओवरलोडिंग". 7 April 2016. Archived from the original on 5 February 2020. Retrieved 5 February 2020.
  11. ↑ Java Grande Forum Panel (November 1998). "Java Grande Forum Report: Making Java Work for High-End Computing" (PDF). SC98.
  12. ↑ 12.0 12.1 Moreira, J.E.; S. P. Midkiff; M. Gupta; P. V. Artigas; M. Snir; R. D. Lawrence (2000). "उच्च-प्रदर्शन संख्यात्मक कंप्यूटिंग के लिए जावा प्रोग्रामिंग". IBM Systems Journal. 39 (1): 21–56. CiteSeerX 10.1.1.13.1554. doi:10.1147/sj.391.0021. वास्तविक आयताकार बहुआयामी सरणियाँ वैज्ञानिक और इंजीनियरिंग कंप्यूटिंग के लिए सबसे महत्वपूर्ण डेटा संरचनाएं हैं।
  13. ↑ Hutchinson, Ben (2008-06-14). "JVM को वैल्यू प्रकार की आवश्यकता है". Retrieved 3 February 2012.
  14. ↑ "java.util.HashMap स्रोत कोड". JDK 8. zGrepCode. Retrieved 6 August 2018.
  15. ↑ Arndt, Holger; Bundschus, Markus; Naegele, Andreas (2009). "Towards a Next-Generation Matrix Library for Java" (PDF). 2009 33rd Annual IEEE International Computer Software and Applications Conference. pp. 460–467. CiteSeerX 10.1.1.471.7567. doi:10.1109/compsac.2009.67. ISBN 978-0-7695-3726-9. S2CID 14672978. ...it is not possible in Java to have arrays with more than 231 entries...
  16. ↑ "Why does Java's Collection.size() return an int?". Stack Overflow. Archived from the original on 26 March 2013. Retrieved 10 February 2012.
  17. ↑ James Gosling; Bill Joy; Guy Steele; Gilad Bracha. "जावा भाषा विशिष्टता" (Third ed.). Addison Wesley. Retrieved 6 February 2012.
  18. ↑ Lowden, James (24 March 2009). "Proposal: Large arrays (take two)". Java.net coin-dev mailing list. Retrieved 10 February 2012.
  19. ↑ "java.util.संग्रह". Java™ Platform, Standard Edition 7 API Specification. Retrieved 10 February 2012.
  20. ↑ "java.nio.ByteBuffer". Java™ Platform, Standard Edition 7 API Specification. Retrieved 6 February 2012.
  21. ↑ David Flanagan. संक्षेप में जावा. p. 77.
  22. ↑ Sherman R. Alpert (IBM) (1998). "आदिम प्रकार को हानिकारक माना जाता है". Java Report, November, 1998 (Volume 3, Number 11). Retrieved 2015-11-18.
  23. ↑ Brinch Hansen (April 1999). "जावा की असुरक्षित समानता" (PDF). SIGPLAN. Retrieved 2012-10-13.; alternate url
  24. ↑ Serialization and Deserialization in Java with Example by geeksforgeeks website
  25. ↑ Serialization Must Die Security issues and problems with serialization of random objects. by dzone.com
  26. ↑ Bloch, Joshua (2018). प्रभावी जावा. Addison-Wesley. pp. 339–345. ISBN 978-0-13-468599-1.
  27. ↑ Kahan, W.; Joseph D. Darcy (1998-03-01). "कैसे जावा का फ़्लोटिंग-प्वाइंट हर जगह हर किसी को नुकसान पहुँचाता है" (PDF). Retrieved 2006-12-09.
  28. ↑ "प्रकार, मान और चर". Sun Microsystems. Retrieved 2006-12-09.
  29. ↑ "Java theory and practice: Where's your point? Tricks and traps with floating point and decimal numbers". IBM. 2003-01-01. Retrieved 2011-11-19.
  30. ↑ "What's Wrong in Java 8, Part V: Tuples - DZone". dzone.com (in English). Retrieved 18 March 2023.
  31. ↑ Robert B.K. Dewar; Edmond Schonberg (2008-01-01). "Computer Science Education: Where Are the Software Engineers of Tomorrow?". CrossTalk Jan 2008. U.S. DOD Software Technology Support Center. Archived from the original on 2009-04-12. Retrieved 2015-03-15. The Pitfalls of Java as a First Programming Language [...] Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.
  32. ↑ Joel Spolsky (December 29, 2005). "सॉफ्टवेयर पर जोएल - जावास्कूल के खतरे". joelonsoftware. Retrieved 2015-11-18. It's bad enough that JavaSchools fail to weed out the kids who are never going to be great programmers, which the schools could justifiably say is not their problem. Industry, or, at least, the recruiters-who-use-grep, are surely clamoring for Java to be taught. But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design
  33. ↑ Ned Batchelder (January 1, 2006). "जोएल स्पोल्स्की एक टेढ़े-मेढ़े बूढ़े आदमी हैं". nedbatchelder.com. Retrieved 2016-02-02. Why does Joel pick out pointers and recursion as the two gatekeeper concepts? Because he found them difficult? As Tim Bray points out, Java is perfectly adept at recursion, and concurrency may be a more important and difficult concept to master in any case. The emphasis on recursion in Lisp languages is a bit over the top, and doesn't carry into other programming cultures. Why do people think it's so important for software engineering? Don't get me wrong: I love recursion when it's the right tool for the job, but that is just not that often to warrant Joel's focus on it as a fundamental concept.
    While we're hunting around for tough concepts that separate the men from the boys, what about the one that got Joel and I into a tussle two years ago: Exceptions. He doesn't like them, basically, because they confuse him. Is this any different than a Java guy not liking pointers? Yes, you can avoid exceptions and use status returns, but you can also try really hard to avoid pointers. Does that mean you should? So Joel's got the concepts he likes (pointers and recursion), and laments their decline, but doesn't seem to notice that there are newer concepts that he's never caught on to, which the Java kiddies feel at home with.
  34. ↑ "Computer Language Benchmarks Game: Java vs Gnu C++". benchmarksgame.alioth.debian.org. Archived from the original on 13 January 2015. Retrieved 2011-11-19.
  35. ↑ 35.0 35.1 J.P.Lewis & Ulrich Neumann. "जावा बनाम सी++ का प्रदर्शन". Graphics and Immersive Technology Lab, University of Southern California.
  36. ↑ "जावा C++ बेंचमार्क से भी तेज़ है". Retrieved 15 May 2016.
  37. ↑ FreeTTS - A Performance Case Study Archived 25 March 2009 at the Wayback Machine, Willie Walker, Paul Lamere, Philip Kwok
  38. ↑ John D. Carmack (27 March 2005). "सेल फ़ोन रोमांच". John Carmack's Blog. armadilloaerospace.com. Archived from the original on 24 November 2015. Retrieved 10 November 2015.
  39. ↑ Java SE Platform Security Architecture. Oracle. Retrieved 2013-04-23.
  40. ↑ 40.0 40.1 "Researchers Highlight Recent Uptick in Java Security Exploits".
  41. ↑ "Have you checked the Java?". Archived from the original on 21 September 2012. Retrieved 25 November 2010.
  42. ↑ "Oracle knew about critical Java flaws since April". The Register. 30 August 2012. Retrieved 30 August 2012.
  43. ↑ "'मूक लेकिन घातक' जावा सुरक्षा अद्यतन पुराने ऐप्स को तोड़ता है - देव". The Register. Retrieved 15 May 2016.
  44. ↑ Pistoia, Marco; Banerjee, Anindya; Naumann, David A. (May 2007). "Beyond Stack Inspection: A Unified Access-Control and Information-Flow Security Model". 2007 IEEE Symposium on Security and Privacy (SP '07). IEEE: 149–163. doi:10.1109/sp.2007.10. ISBN 978-0-7695-2848-9. S2CID 4112294.
  45. ↑ "अनुलग्नक ए". www.java.com (in English). Retrieved 2018-03-03.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=जावा_की_आलोचना&oldid=226592’