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

From Vigyanwiki
Revision as of 10:40, 27 July 2023 by Manidh (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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

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

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

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

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

जावा की आलोचना की गई है क्योंकि यह 231 या उससे अधिक तत्वों की सरणियों का समर्थन नहीं करता है। यह भाषा की एक सीमा है; जावा भाषा विनिर्देशिका, अनुभाग 10.4, में कहा गया है कि:

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


समर्थित बड़ी सरणियों के लिए JVM में भी परिवर्तन की आवश्यकता होती है।[15] इस सीमा का प्रमाणित होना संग्रहण विभाग में होता है, जहां संख्या केवल 2 अरब तत्वों तक ही सीमित होती है,[16] और 2 GB से बड़े संचित फ़ाइल सेगमेंट को मेमोरी मैप नहीं करने की असमर्थता होती है।[[17]जावा को भी बहुआयामी सरणियों एकल संदर्भ द्वारा पहुंचे जाने वाले एकल प्रत्यय द्वारा निर्धारित एकल ब्लॉक मेमोरी से एकांतरित का समर्थन नहीं होता है, जिससे वैज्ञानिक और तकनीकी गणना के लिए प्रदर्शन सीमित होता है।[11]

जावा में सरणियों को प्रारंभिकरण करने के लिए कोई प्रभावी तरीका वास्तव में नहीं है। सरणी की घोषणा करते समय, जीवीएम इसे रनटाइम पर एक-एक करके उसके तत्वों को सेट करने के निर्देशों के साथ बाइटकोड में बदलता है। यह प्रारंभिकरण समय में अधिक समय बड़ी सरणियों के लिए कारण बन सकता है। [18]

प्राथमिक डेटा और सरणियों का एकीकरण

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

समानांतरता

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

क्रमांकन

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


स्थानांतरित बिंदु गणना

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


टुपल्स की कमी

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


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

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

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

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


प्रदर्शन

Further information: जावा प्रदर्शन

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

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

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


सुरक्षा

Further information: जावा सुरक्षा

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

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

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

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

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

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

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

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


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

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

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

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

Further information: उचित समय पर संकलन § सुरक्षा

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

यह भी देखें

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

टिप्पणियाँ

  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. ↑ Java Grande Forum Panel (November 1998). "Java Grande Forum Report: Making Java Work for High-End Computing" (PDF). SC98.
  11. ↑ 11.0 11.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. वास्तविक आयताकार बहुआयामी सरणियाँ वैज्ञानिक और इंजीनियरिंग कंप्यूटिंग के लिए सबसे महत्वपूर्ण डेटा संरचनाएं हैं।
  12. ↑ "java.util.HashMap स्रोत कोड". JDK 8. zGrepCode. Retrieved 6 August 2018.
  13. ↑ Hutchinson, Ben (2008-06-14). "JVM को वैल्यू प्रकार की आवश्यकता है". Retrieved 3 February 2012.
  14. ↑ James Gosling; Bill Joy; Guy Steele; Gilad Bracha. "जावा भाषा विशिष्टता" (Third ed.). Addison Wesley. Retrieved 6 February 2012.
  15. ↑ Lowden, James (24 March 2009). "Proposal: Large arrays (take two)". Java.net coin-dev mailing list. Retrieved 10 February 2012.
  16. ↑ "java.util.संग्रह". Java™ Platform, Standard Edition 7 API Specification. Retrieved 10 February 2012.
  17. ↑ "java.nio.ByteBuffer". Java™ Platform, Standard Edition 7 API Specification. Retrieved 6 February 2012.
  18. ↑ David Flanagan. संक्षेप में जावा. p. 77.
  19. ↑ Sherman R. Alpert (IBM) (1998). "आदिम प्रकार को हानिकारक माना जाता है". Java Report, November, 1998 (Volume 3, Number 11). Retrieved 2015-11-18.
  20. ↑ Brinch Hansen (April 1999). "जावा की असुरक्षित समानता" (PDF). SIGPLAN. Retrieved 2012-10-13.; alternate url
  21. ↑ Serialization and Deserialization in Java with Example by geeksforgeeks website
  22. ↑ Serialization Must Die Security issues and problems with serialization of random objects. by dzone.com
  23. ↑ Bloch, Joshua (2018). प्रभावी जावा. Addison-Wesley. pp. 339–345. ISBN 978-0-13-468599-1.
  24. ↑ Kahan, W.; Joseph D. Darcy (1998-03-01). "कैसे जावा का फ़्लोटिंग-प्वाइंट हर जगह हर किसी को नुकसान पहुँचाता है" (PDF). Retrieved 2006-12-09.
  25. ↑ "प्रकार, मान और चर". Sun Microsystems. Retrieved 2006-12-09.
  26. ↑ "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.
  27. ↑ "What's Wrong in Java 8, Part V: Tuples - DZone". dzone.com (in English). Retrieved 18 March 2023.
  28. ↑ 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.
  29. ↑ 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
  30. ↑ 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.
  31. ↑ "Computer Language Benchmarks Game: Java vs Gnu C++". benchmarksgame.alioth.debian.org. Archived from the original on 13 January 2015. Retrieved 2011-11-19.
  32. ↑ 32.0 32.1 J.P.Lewis & Ulrich Neumann. "जावा बनाम सी++ का प्रदर्शन". Graphics and Immersive Technology Lab, University of Southern California.
  33. ↑ "जावा C++ बेंचमार्क से भी तेज़ है". Retrieved 15 May 2016.
  34. ↑ FreeTTS - A Performance Case Study Archived 25 March 2009 at the Wayback Machine, Willie Walker, Paul Lamere, Philip Kwok
  35. ↑ John D. Carmack (27 March 2005). "सेल फ़ोन रोमांच". John Carmack's Blog. armadilloaerospace.com. Archived from the original on 24 November 2015. Retrieved 10 November 2015.
  36. ↑ Java SE Platform Security Architecture. Oracle. Retrieved 2013-04-23.
  37. ↑ 37.0 37.1 "Researchers Highlight Recent Uptick in Java Security Exploits".
  38. ↑ "Have you checked the Java?". Archived from the original on 21 September 2012. Retrieved 25 November 2010.
  39. ↑ "Oracle knew about critical Java flaws since April". The Register. 30 August 2012. Retrieved 30 August 2012.
  40. ↑ "'मूक लेकिन घातक' जावा सुरक्षा अद्यतन पुराने ऐप्स को तोड़ता है - देव". The Register. Retrieved 15 May 2016.
  41. ↑ 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.
  42. ↑ "अनुलग्नक ए". www.java.com (in English). Retrieved 2018-03-03.


बाहरी संबंध

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