जावा एप्लेट: Difference between revisions
(→नुकसान) |
(→नुकसान) |
||
| Line 73: | Line 73: | ||
=== 1997, सन बनाम माइक्रोसॉफ्ट === | === 1997, सन बनाम माइक्रोसॉफ्ट === | ||
1997 का मुकदमा,<ref name="s1997">{{cite web |last1=Zukowski |first1=John |date=1997-10-01 |url=https://www.infoworld.com/article/2077055/what-does-sun-s-lawsuit-against-microsoft-mean-for-java-developers-.html |title=What does Sun's lawsuit against Microsoft mean for Java developers? |df=dmy |work=[[JavaWorld]] |access-date=2020-07-13}}</ref> माइक्रोसॉफ्ट द्वारा संशोधित [[माइक्रोसॉफ्ट जावा वर्चुअल मशीन]] बनाने के बाद दायर किया गया था, जिसे इंटरनेट खोजकर्ता के साथ भेज दिया गया था। माइक्रोसॉफ्ट ने जावा.awt, जावा.lang, और जावा.io संकुल के भीतर कक्षाओं में लगभग 50 विधियाँ और 50 क्षेत्रों को जोड़ा।<ref name="s1997"/> अन्य संशोधनों में [[जावा दूरस्थ विधि मंगलाचरण]] क्षमता को हटाना और [[जावा मूल इंटरफ़ेस]] को जेएनआई से | 1997 का मुकदमा,<ref name="s1997">{{cite web |last1=Zukowski |first1=John |date=1997-10-01 |url=https://www.infoworld.com/article/2077055/what-does-sun-s-lawsuit-against-microsoft-mean-for-java-developers-.html |title=What does Sun's lawsuit against Microsoft mean for Java developers? |df=dmy |work=[[JavaWorld]] |access-date=2020-07-13}}</ref> माइक्रोसॉफ्ट द्वारा संशोधित [[माइक्रोसॉफ्ट जावा वर्चुअल मशीन]] बनाने के बाद दायर किया गया था, जिसे इंटरनेट खोजकर्ता के साथ भेज दिया गया था। माइक्रोसॉफ्ट ने जावा.awt, जावा.lang, और जावा.io संकुल के भीतर कक्षाओं में लगभग 50 विधियाँ और 50 क्षेत्रों को जोड़ा।<ref name="s1997"/> अन्य संशोधनों में [[जावा दूरस्थ विधि मंगलाचरण]] क्षमता को हटाना और [[जावा मूल इंटरफ़ेस|जावा नेटिव इंटरफ़ेस]] को जेएनआई से आरएनआई नेटिव , एक अलग मानक में बदलना सम्मिलित है। RMI को हटा दिया गया था क्योंकि यह केवल जावा से जावा संचार का आसानी से समर्थन करता है और Microsoft वितरित घटक ऑब्जेक्ट मॉडल तकनीक के साथ प्रतिस्पर्धा करता है। एप्लेट्स जो इन परिवर्तनों पर भरोसा करते थे या अनजाने में उनका उपयोग करते थे, केवल माइक्रोसॉफ्ट के जावा प्रणाली के भीतर ही काम करते थे। सन ने [[ट्रेडमार्क]] के उल्लंघन के लिए मुकदमा दायर किया, क्योंकि जावा का बिंदु यह था कि कोई मालिकाना विस्तार नहीं होना चाहिए और वह कोड हर जगह काम करना चाहिए। Microsoft Sun को $20 मिलियन का भुगतान करने के लिए सहमत हो गया, और Sun केवल संशोधनों के बिना और सीमित समय के लिए Java का उपयोग करने के लिए Microsoft को सीमित लाइसेंस देने पर सहमत हो गया।<ref name="sun_suits">{{cite web|url=http://www.sun.com/lawsuit/summary.html|title=सन का पेज, माइक्रोसॉफ्ट के खिलाफ मुकदमों के लिए समर्पित|archive-url=https://web.archive.org/web/20090819120756/http://www.sun.com/lawsuit/summary.html|archive-date=19 August 2009|url-status=dead}}</रेफरी> | ||
=== 2002: सन बनाम माइक्रोसॉफ्ट === | === 2002: सन बनाम माइक्रोसॉफ्ट === | ||
Revision as of 12:32, 5 April 2023
जावा एप्लेट्स जावा प्रोग्रामिंग भाषा, या अन्य प्रोग्रामिंग भाषा में लिखे गए छोटे अनुप्रयोग थे, जो जावा बाईटकोड को संकलित करते हैं, और जावा बाइटकोड के रूप में उपयोगकर्ताओं को वितरित किए जाते हैं। उपयोगकर्ता ने जावा एप्लेट को एक वेब पेज से लॉन्च किया, और तब एप्लेट को जावा वर्चुअल मशीन (जेवीएम) के भीतर वेब ब्राउज़र से अलग एक प्रक्रिया में निष्पादित किया गया। एक जावा एप्लेट वेब पेज के एक फ्रेम, एक नई अनुप्रयोग विंडो, सन के एप्लेट व्यूअर, या एप्लेट्स के परीक्षण के लिए एक एकल उपकरण में दिखाई दे सकता है।
जावा एप्लेट्स को जावा भाषा के पहले संस्करण में पेश किया गया था, जो 1995 में जारी किया गया था। 2013 की शुरुआत में, प्रमुख वेब ब्राउज़रों ने एप्लेट्स को चलाने के लिए उपयोग की जाने वाली अंतर्निहित प्रौद्योगिकी के लिए समर्थन को समाप्त करना शुरू कर दिया, साथ ही एप्लेट्स 2015-2017 तक चलने में पूरी तरह से असमर्थ हो गए। जावा एप्लेट्स को 2017 में जावा 9 द्वारा बहिष्कृत कर दिया गया था।[6][7][8][9][10]
जावा एप्लेट आमतौर पर जावा में लिखे जाते थे, लेकिन अन्य भाषाएँ जैसे ज्योथन, जेरुबी, पास्कल (प्रोग्रामिंग भाषा),[11] Scala (प्रोग्रामिंग भाषा), NetRexx, या Eiffel (प्रोग्रामिंग भाषा) (SmartEiffel के माध्यम से) का भी उपयोग किया जा सकता है।
जावा एप्लेट बहुत तेज गति से चलते हैं और 2011 तक वे जावास्क्रिप्ट से कई गुना तेज थे।[citation needed] जावास्क्रिप्ट के विपरीत, जावा एप्लेट्स के पास 3डी हार्डवेयर त्वरण तक पहुंच थी, जो उन्हें गैर-तुच्छ, संगणना-गहन विज़ुअलाइज़ेशन के लिए अच्छी तरह से अनुकूल बनाता है। जैसा कि ब्राउज़र ने हार्डवेयर-त्वरित ग्राफिक्स के लिए कैनवास तत्व प्रौद्योगिकी (या विशेष रूप से 3D ग्राफिक्स के मामले में WebGL) के लिए समर्थन प्राप्त किया है,[12][13] साथ ही समय-समय पर संकलन|बस-समय-समय पर संकलित जावास्क्रिप्ट,[14] गति अंतर कम ध्यान देने योग्य हो गया है।[citation needed] चूंकि जावा बाइटकोड क्रॉस-प्लेटफॉर्म (या प्लेटफ़ॉर्म स्वतंत्र) है, जावा एप्लेट्स को Microsoft Windows, FreeBSD, Unix, macOS और Linux सहित कई प्लेटफ़ॉर्म के लिए क्लाइंट (कंप्यूटिंग) द्वारा निष्पादित किया जा सकता है। वे मोबाइल उपकरणों पर नहीं चलाए जा सकते थे, जो मानक Oracle JVM बायटेकोड चलाने का समर्थन नहीं करते हैं। एंड्रॉइड (ऑपरेटिंग प्रणाली) डिवाइस एंड्रॉइड रनटाइम के लिए संकलित जावा में लिखे कोड चला सकते हैं।
सिंहावलोकन
एप्लेट्स का उपयोग वेब अनुप्रयोगों के लिए इंटरएक्टिव फीचर प्रदान करने के लिए किया जाता है जो केवल HTML द्वारा प्रदान नहीं किया जा सकता है। वे माउस (कंप्यूटिंग) पर कब्जा कर सकते हैं और बटन (कंप्यूटिंग) या चेक बॉक्स जैसे नियंत्रण भी रख सकते हैं। उपयोगकर्ता की कार्रवाइयों के जवाब में, एक एप्लेट प्रदान की गई ग्राफिक सामग्री को बदल सकता है। यह एप्लेट्स को प्रदर्शन, विज़ुअलाइज़ेशन और शिक्षण के लिए उपयुक्त बनाता है। भौतिक विज्ञान से लेकर हृदय शरीर क्रिया विज्ञान तक, विभिन्न विषयों का अध्ययन करने के लिए ऑनलाइन एप्लेट संग्रह हैं।
एक एप्लेट केवल पाठ क्षेत्र भी हो सकता है; उदाहरण के लिए, कुछ रिमोट प्रणाली के लिए एक क्रॉस-प्लेटफ़ॉर्म कमांड लाइन इंटरफेस प्रदान करना। यदि आवश्यक हो, एक एप्लेट समर्पित क्षेत्र को छोड़ सकता है और एक अलग विंडो के रूप में चल सकता है। हालांकि, एप्लेट्स का एप्लेट्स के समर्पित क्षेत्र के बाहर वेब पेज की सामग्री पर बहुत कम नियंत्रण होता है, इसलिए वे अन्य प्रकार के ब्राउज़र एक्सटेंशन के विपरीत सामान्य रूप से साइट की उपस्थिति में सुधार के लिए कम उपयोगी होते हैं (जबकि एप्लेट्स जैसे समाचार टिकर या WYSIWYG संपादक भी जाने जाते हैं)। एप्लेट मीडिया को उन प्रारूपों में भी चला सकते हैं जो मूल रूप से ब्राउज़र द्वारा समर्थित नहीं हैं।
HTML में कोडित पृष्ठ एप्लेट को पास किए गए पैरामीटर को अपने भीतर एम्बेड कर सकते हैं। इस वजह से, पास किए गए पैरामीटर के आधार पर एक ही एप्लेट में एक अलग उपस्थिति हो सकती है।
चूंकि HTML5 से पहले एप्लेट्स उपलब्ध थे, आधुनिक व्यापक शैली पत्रक और जावास्क्रिप्ट इंटरफ़ेस दस्तावेज़ ऑब्जेक्ट मॉडल मानक थे, वे माउस के ऊपर और नेविगेशन बटन जैसे तुच्छ प्रभावों के लिए भी व्यापक रूप से उपयोग किए जाते थे। यह दृष्टिकोण, जिसने अभिगम्यता और प्रणाली संसाधनों के दुरूपयोग के लिए प्रमुख समस्याएं उत्पन्न कीं, अब उपयोग में नहीं है और उस समय भी दृढ़ता से हतोत्साहित किया गया था।
तकनीकी जानकारी
अधिकांश ब्राउज़रों ने जावा एप्लेट्स को सैंडबॉक्स (सुरक्षा) में निष्पादित किया तथा एप्लेट्स को फाइल प्रणाली जैसे स्थानीय डेटा तक पहुंचने से रोका।[15] एप्लेट का कोड एक वेब सर्वर से डाउनलोड किया गया था, जिसके बाद ब्राउज़र या तो एप्लेट को एक वेब पेज में कंपाउंड करता है या एप्लेट के प्रयोक्ता इंटरफ़ेस को दिखाते हुए एक नई विंडो खोलता है।
पहले कार्यान्वयन में कक्षा दर एप्लेट वर्ग को डाउनलोड करना सम्मिलित था। जबकि कक्षाएं छोटी फाइलें होती हैं, अक्सर उनमें से कई होती हैं, इसलिए एप्लेट्स को धीमी गति से लोड होने वाले घटकों के रूप में प्रतिष्ठा मिली। हालाँकि, तब से .jars पेश किए गए थे, एक एप्लेट आमतौर पर एक एकल फ़ाइल के रूप में वितरित किया जाता है जिसका आकार एक छवि फ़ाइल के समान होता है (सैकड़ों किलोबाइट से लेकर कई मेगाबाइट तक)।
जावा स्टेटिक लाइब्रेरी और क्रम पुस्तकालय पिछड़े-संगत हैं, जो किसी को कोड लिखने की इजाजत देता है जो जावा वर्चुअल मशीन के वर्तमान और भविष्य के दोनों संस्करणों पर चलता है।
समान प्रौद्योगिकियां
कई जावा विकासक्स, ब्लॉग और पत्रिकाओं ने अनुशंसा की कि एप्लेट्स के स्थान पर जावा वेब स्टार्ट तकनीक का उपयोग किया जाए।[16] जावा वेब स्टार्ट ने असंशोधित एप्लेट कोड को लॉन्च करने की अनुमति दी, जो तब एक अलग विंडो में चलता था (आह्वान करने वाले ब्राउज़र के अंदर नहीं)।
एक जावा सर्वलेट की कभी-कभी अनौपचारिक रूप से सर्वर-साइड एप्लेट की तरह तुलना की जाती है, लेकिन यह अपनी भाषा, कार्यों और एप्लेट्स के बारे में यहां वर्णित प्रत्येक विशेषताओं में भिन्न है।
एक वेब पेज में एम्बेड करना
पदावनत का उपयोग करके एप्लेट को वेब पेज पर प्रदर्शित किया जाएगा applet एचटीएमएल तत्व,[17] या अनुशंसित object तत्व।[18] embed ई> तत्व का उपयोग किया जा सकता है[19] Mozilla पारिवारिक ब्राउज़रों के साथ (embed HTML 4 में पदावनत किया गया था लेकिन HTML 5 में सम्मिलित किया गया है)। यह एप्लेट के स्रोत और स्थान को निर्दिष्ट करता है। दोनों object और embed टैग जावा वर्चुअल मशीन (यदि आवश्यक हो) को डाउनलोड और इंस्टॉल कर सकते हैं या कम से कम प्लगइन पेज पर ले जा सकते हैं। applet और object टैग क्रमबद्ध एप्लेट्स को लोड करने का भी समर्थन करते हैं जो कुछ विशेष (प्रारंभिक के बजाय) स्थिति में शुरू होते हैं। टैग उस संदेश को भी निर्दिष्ट करते हैं जो एप्लेट के स्थान पर दिखाई देता है यदि ब्राउज़र इसे किसी भी कारण से नहीं चला सकता है।
हालाँकि, बावजूद object आधिकारिक तौर पर 2010 में एक अनुशंसित टैग होने के नाते, object टैग अभी तक ब्राउज़रों के बीच सुसंगत नहीं था और सन पुराने की सिफारिश करता रहा applet मल्टीब्राउज़र वातावरण में तैनाती के लिए टैग,[20] क्योंकि यह सबसे लोकप्रिय ब्राउज़रों द्वारा लगातार समर्थित एकमात्र टैग बना रहा। एकाधिक ब्राउज़रों का समर्थन करने के लिए, object एप्लेट को एम्बेड करने के लिए टैग को जावास्क्रिप्ट (जो ब्राउज़र को पहचानता है और टैग को समायोजित करता है), अतिरिक्त ब्राउज़र-विशिष्ट टैग का उपयोग या सर्वर साइड से अनुकूलित आउटपुट देने की आवश्यकता होगी।
जावा ब्राउज़र प्लग-इन NPAPI पर निर्भर था, जिसकी आयु और सुरक्षा समस्याओं के कारण लगभग सभी वेब ब्राउज़र विक्रेताओं ने इसके लिए समर्थन हटा दिया है या लागू नहीं करते हैं। जनवरी 2016 में, Oracle ने घोषणा की कि JDK 9 पर आधारित जावा रनटाइम वातावरण ब्राउज़र प्लग-इन को बंद कर देगा।[21]
लाभ
जावा एप्लेट में निम्नलिखित में से कोई एक या सभी लाभ हो सकते हैं:[22]
- इसे FreeBSD, Linux, Microsoft Windows और macOS पर काम करना आसान था – यानी इसे क्रॉस-प्लेटफॉर्म बनाना है। 21वीं सदी के पहले दशक में एप्लेट्स को अधिकांश वेब ब्राउज़रों द्वारा समर्थित किया गया था; तब से, अधिकांश ब्राउज़रों ने सुरक्षा कारणों से एप्लेट समर्थन छोड़ दिया है।
- केवल नवीनतम प्लग-इन (कंप्यूटिंग) | प्लग-इन संस्करण के बजाय एक ही एप्लेट एक ही समय में जावा के सभी स्थापित संस्करणों पर काम करेगा। हालाँकि, यदि किसी एप्लेट को जावा वर्चुअल मशीन (JRE) के बाद के संस्करण की आवश्यकता होती है, तो क्लाइंट को बड़े डाउनलोड के दौरान प्रतीक्षा करने के लिए मजबूर किया जाएगा।
- अधिकांश वेब ब्राउज़र एप्लेट्स को वेब कैश करते हैं ताकि वे वेब पेज पर लौटते समय जल्दी से लोड हो सकें। उपयोग के साथ एप्लेट्स में भी सुधार हुआ: पहले एप्लेट के चलने के बाद, जेवीएम पहले से ही चल रहा था और बाद के एप्लेट्स जल्दी से शुरू हो गए (ब्राउज़र के नए सिरे से शुरू होने पर हर बार जेवीएम को फिर से शुरू करने की आवश्यकता होगी)। JRE संस्करण 1.5 और उच्चतर ने JVM को फिर से शुरू किया जब ब्राउज़र पृष्ठों के बीच नेविगेट करता है, एक सुरक्षा उपाय के रूप में जिसने उस प्रदर्शन लाभ को हटा दिया।
- यह काम को सर्वर (कंप्यूटिंग) से क्लाइंट (कंप्यूटिंग) तक ले गया, जिससे वेब समाधान उपयोगकर्ताओं/क्लाइंटों की संख्या के साथ अधिक स्केलेबल हो गया।
- यदि एक स्टैंडअलोन प्रोग्राम (जैसे Google धरती) एक वेब सर्वर से बात करता है, तो उस सर्वर को सामान्य रूप से उन उपयोगकर्ताओं के लिए सभी पूर्व संस्करणों का समर्थन करने की आवश्यकता होती है जिन्होंने अपने क्लाइंट सॉफ़्टवेयर को अद्यतन नहीं रखा है। इसके विपरीत, एक ब्राउज़र नवीनतम एप्लेट संस्करण को लोड (और कैश्ड) करता है, इसलिए लीगेसी संस्करणों का समर्थन करने की कोई आवश्यकता नहीं है।
- एप्लेट स्वाभाविक रूप से बदलती उपयोगकर्ता स्थिति का समर्थन करता है, जैसे शतरंज की बिसात पर आकृति की स्थिति।
- विकासकर्ता केवल एक मुख्य दिनचर्या (या तो एप्लेट की कक्षा में या एक अलग वर्ग में) बनाकर और एप्लेट पर init() और start() को कॉल करके एक एप्लेट को सीधे विकसित और डिबग कर सकते हैं, इस प्रकार अपने पसंदीदा जावा प्लेटफॉर्म में विकास की अनुमति देते हैं, मानक संस्करण विकास पर्यावरण। यह सुनिश्चित करने के लिए कि यह सुरक्षा प्रतिबंधों के अनुरूप है, AppletViewer प्रोग्राम या वेब ब्राउज़र में एप्लेट को फिर से परीक्षण करना था।
- एक ब्राउज़र सुरक्षा एप्लेट की स्थानीय मशीन तक पहुंच नहीं थी और वह केवल उस सर्वर तक पहुंच सकता है जिससे वह आया था। यह एप्लेट्स को उनके द्वारा बदले जाने वाले देशी निष्पादन योग्यों की तुलना में चलाने के लिए अधिक सुरक्षित बनाता है। हालाँकि, एक हस्ताक्षरित एप्लेट को उस मशीन तक पूरी पहुँच प्राप्त हो सकती है जिस पर वह चल रहा है, यदि उपयोगकर्ता सहमत हो।
- जावा एप्लेट तेज थे, मूल रूप से इंस्टॉल किए गए सॉफ्टवेयर के जावा प्रदर्शन के साथ।
नुकसान
This section needs additional citations for verification. (August 2015) (Learn how and when to remove this template message) |
अन्य क्लाइंट-साइड वेब तकनीकों की तुलना में जावा एप्लेट्स में निम्नलिखित नुकसान थे:
- जावा एप्लेट जावा रनटाइम एनवायरनमेंट (जेआरई) पर निर्भर करेगा, जो एक जटिल और भारी सॉफ्टवेयर पैकेज है। उन्हें सामान्य रूप से वेब ब्राउज़र के लिए प्लग-इन (कंप्यूटिंग)|प्लग-इन की भी आवश्यकता होती है। कुछ संगठन केवल व्यवस्थापक द्वारा इंस्टॉल किए गए सॉफ़्टवेयर की अनुमति देते हैं। परिणामस्वरूप, उपयोगकर्ता एप्लेट्स को तब तक देखने में असमर्थ थे जब तक कि एक जेआरई और प्लग-इन की स्थापना का अनुरोध करने के लिए व्यवस्थापक से संपर्क करने का औचित्य साबित करने के लिए पर्याप्त महत्वपूर्ण न हो।
- यदि किसी एप्लेट को प्रणाली पर उपलब्ध नए जेआरई की आवश्यकता है, तो इसे पहली बार चलाने वाले उपयोगकर्ता को बड़े जेआरई डाउनलोड को पूरा करने के लिए इंतजार करना होगा।
- आईओएस या एंड्रॉइड (ऑपरेटिंग प्रणाली) पर मोबाइल ब्राउज़र, कभी भी जावा एप्लेट्स नहीं चलाते हैं।[23] सभी प्लेटफार्मों पर एप्लेट्स के बहिष्करण से पहले ही, मोबाइल ऑपरेटिंग प्रणाली के उदय के साथ-साथ डेस्कटॉप ब्राउज़रों ने जावा एप्लेट समर्थन को समाप्त कर दिया।
- एप्लेट्स की सामग्री को स्क्रीन रीडर्स के लिए उपलब्ध कराने के लिए कोई मानक नहीं था। इसलिए, एप्लेट्स ने विशेष जरूरतों वाले उपयोगकर्ताओं के लिए एक वेब साइट की पहुंच को नुकसान पहुंचाया।
- जैसा कि किसी क्लाइंट-साइड स्क्रिप्टिंग के साथ होता है, सुरक्षा प्रतिबंधों ने कुछ अविश्वसनीय एप्लेट्स के लिए अपने वांछित लक्ष्यों को प्राप्त करना कठिन या असंभव बना दिया। केवल JAVA JRE स्थापना में java.policy फ़ाइल को संपादित करके कोई स्थानीय फाइल प्रणाली या प्रणाली क्लिपबोर्ड तक पहुंच प्रदान कर सकता है, या ब्राउज़र को एप्लेट प्रदान करने वाले नेटवर्क के अलावा अन्य नेटवर्क स्रोतों तक पहुंच प्रदान कर सकता है।
- अधिकांश उपयोगकर्ता अविश्वसनीय और विश्वसनीय एप्लेट्स के बीच के अंतर के बारे में परवाह नहीं करते थे, इसलिए इस अंतर से सुरक्षा में ज्यादा मदद नहीं मिली। सभी एप्लेट्स को हटाने से पहले अविश्वसनीय एप्लेट्स को चलाने की क्षमता को अंततः इसे ठीक करने के लिए पूरी तरह से हटा दिया गया था।
संगतता-संबंधी मुकदमे
जावा संस्करणों के बीच संगतता सुनिश्चित करने के लिए सन माइक्रोप्रणाली्स काफी हद तक जाता है, क्योंकि वे कानून द्वारा आवश्यक होने पर जावा सुवाह्यता को लागू करते हैं। लगता है कि ओरेकल उसी रणनीति को जारी रखे हुए है।
1997, सन बनाम माइक्रोसॉफ्ट
1997 का मुकदमा,[24] माइक्रोसॉफ्ट द्वारा संशोधित माइक्रोसॉफ्ट जावा वर्चुअल मशीन बनाने के बाद दायर किया गया था, जिसे इंटरनेट खोजकर्ता के साथ भेज दिया गया था। माइक्रोसॉफ्ट ने जावा.awt, जावा.lang, और जावा.io संकुल के भीतर कक्षाओं में लगभग 50 विधियाँ और 50 क्षेत्रों को जोड़ा।[24] अन्य संशोधनों में जावा दूरस्थ विधि मंगलाचरण क्षमता को हटाना और जावा नेटिव इंटरफ़ेस को जेएनआई से आरएनआई नेटिव , एक अलग मानक में बदलना सम्मिलित है। RMI को हटा दिया गया था क्योंकि यह केवल जावा से जावा संचार का आसानी से समर्थन करता है और Microsoft वितरित घटक ऑब्जेक्ट मॉडल तकनीक के साथ प्रतिस्पर्धा करता है। एप्लेट्स जो इन परिवर्तनों पर भरोसा करते थे या अनजाने में उनका उपयोग करते थे, केवल माइक्रोसॉफ्ट के जावा प्रणाली के भीतर ही काम करते थे। सन ने ट्रेडमार्क के उल्लंघन के लिए मुकदमा दायर किया, क्योंकि जावा का बिंदु यह था कि कोई मालिकाना विस्तार नहीं होना चाहिए और वह कोड हर जगह काम करना चाहिए। Microsoft Sun को $20 मिलियन का भुगतान करने के लिए सहमत हो गया, और Sun केवल संशोधनों के बिना और सीमित समय के लिए Java का उपयोग करने के लिए Microsoft को सीमित लाइसेंस देने पर सहमत हो गया।Cite error: Closing </ref> missing for <ref> tag 2002 में, सन ने एक अविश्वास मुकदमा दायर किया, जिसमें दावा किया गया कि माइक्रोसॉफ्ट के अवैध विमुद्रीकरण के प्रयासों ने जावा प्लेटफॉर्म को नुकसान पहुंचाया है। सन ने माइक्रोसॉफ्ट से विंडोज के हिस्से के रूप में जावा तकनीक के सन के वर्तमान, बाइनरी कार्यान्वयन को वितरित करने, पुराने माइक्रोसॉफ्ट डेस्कटॉप ऑपरेटिंग प्रणाली के लिए अनुशंसित अद्यतन के रूप में वितरित करने और माइक्रोसॉफ्ट की वर्चुअल मशीन के वितरण को रोकने की मांग की (जैसा कि इसके लाइसेंसिंग समय, पूर्व मुकदमे में सहमत था, था) खत्म हो चुका)।[25]माइक्रोसॉफ्ट ने लंबित एंटीट्रस्ट मुद्दों के लिए $700 मिलियन, पेटेंट मुद्दों के लिए $900 मिलियन और भविष्य में सन के सॉफ्टवेयर का उपयोग करने के लिए $350 मिलियन रॉयल्टी शुल्क का भुगतान किया।[26][non-primary source needed]
सुरक्षा
The neutrality of this section is disputed. (नवंबर 2021) (Learn how and when to remove this template message) |
हस्ताक्षरित एप्लेट और अहस्ताक्षरित एप्लेट, बहुत भिन्न सुरक्षा प्रारूप वाले दो एप्लेट प्रकार थे।[27] जावा एसई 7 अपडेट 21 (अप्रैल 2013) से शुरू होकर एप्लेट्स और वेब-स्टार्ट ऐप्स को एक विश्वसनीय प्रमाणपत्र के साथ हस्ताक्षर करने के लिए प्रोत्साहित किया जाता है, और अहस्ताक्षरित एप्लेट्स चलाते समय चेतावनी संदेश दिखाई देते हैं।[28] इसके अलावा, जावा 7 अपडेट 51 से शुरू होने वाले अहस्ताक्षरित एप्लेट्स को डिफ़ॉल्ट रूप से ब्लॉक कर दिया गया था, जहा उन्हें जावा कंट्रोल पैनल में एक अपवाद बनाकर चलाया जा सकता है।[29]
अहस्ताक्षरित
अहस्ताक्षरित एप्लेट्स की सीमाओं को "ड्रैकियन" के रूप में समझा गया था, उनकी स्थानीय फ़ाइल प्रणाली तक कोई पहुंच नहीं है और वेब एक्सेस एप्लेट डाउनलोड साइट तक सीमित है, कई अन्य महत्वपूर्ण प्रतिबंध भी हैं। उदाहरण के लिए, वे सभी प्रणाली गुणों तक नहीं पहुंच सकते हैं, अपने स्वयं के क्लास लोडर का उपयोग कर सकते हैं, स्थानीय कोड को कॉल कर सकते हैं, स्थानीय प्रणाली पर बाहरी कमांड निष्पादित कर सकते हैं या जावा रिलीज के हिस्से के रूप में सम्मिलित कोर पैकेज से संबंधित कक्षाओं को फिर से परिभाषित कर सकते हैं। जबकि वे एक स्टैंडअलोन फ्रेम में चल सकते हैं, ऐसे फ्रेम में एक हेडर होता है, जो दर्शाता है कि यह एक अविश्वसनीय एप्लेट है। निषिद्ध विधि का सफल प्रारंभिक कॉल स्वचालित रूप से एक सुरक्षा छेद नहीं बनाता है क्योंकि अभिगम नियंत्रक कॉलिंग कोड के पूरे कॉल स्टैक की जांच करता है ताकि यह सुनिश्चित हो सके कि कॉल अनुचित स्थान से नहीं आ रही है।
किसी भी जटिल प्रणाली की तरह, जावा के पहली बार जारी होने के बाद से कई सुरक्षा समस्याओं की खोज की गई और उन्हें ठीक किया गया। इनमें से कुछ (जैसे कैलेंडर क्रमांकन सुरक्षा बग) कई वर्षों तक बने रहे और किसी को पता नहीं चला। अन्य वाइल्ड में मैलवेयर द्वारा उपयोग में खोजे गए हैं।[citation needed]
कुछ अध्ययनों में ब्राउज़र को क्रैश करने या केंद्रीय प्रसंस्करण इकाई संसाधनों का अत्यधिक उपयोग करने वाले एप्लेट्स का उल्लेख किया गया है, लेकिन इन्हें वास्तविक सुरक्षा खामियों के बजाय बाधा के रूप में वर्गीकृत किया गया है। हालाँकि, अहस्ताक्षरित एप्लेट संयुक्त हमलों में सम्मिलित हो सकते हैं जो प्रणाली के अन्य भागों में कई गंभीर कॉन्फ़िगरेशन त्रुटियों के संयोजन का फायदा उठाते हैं। एक अहस्ताक्षरित एप्लेट सीधे सर्वर पर चलाने के लिए और अधिक खतरनाक हो सकता है जहां इसे होस्ट किया गया है क्योंकि कोड बेस इसे सर्वर से बात करने की अनुमति देता है, इसके अंदर चलने से फ़ायरवॉल को बायपास किया जा सकता है। एक एप्लेट भी उस सर्वर पर डेनियल-ऑफ़-सर्विस के हमलों की कोशिश कर सकता है जहां इसे होस्ट किया गया है, लेकिन आमतौर पर वे लोग जो वेब साइट का प्रबंधन करते हैं, एप्लेट का प्रबंधन भी करते हैं, जिससे यह अनुचित हो जाता है। समुदाय इस समस्या को स्रोत कोड समीक्षा या समर्पित डोमेन पर चल रहे एप्लेट्स के माध्यम से हल कर सकते हैं।
अहस्ताक्षरित एप्लेट मूल सर्वर पर होस्ट किए गए मैलवेयर को डाउनलोड करने का भी प्रयास कर सकता है। हालाँकि यह केवल ऐसी फ़ाइल को एक अस्थायी फ़ोल्डर में संग्रहीत कर सकता है (क्योंकि यह क्षणिक डेटा है) और इसे निष्पादित करके हमले को पूरा करने का कोई साधन नहीं है। इस तरह फीनिक्स और साइबेरिया के कारनामों को फैलाने के लिए एप्लेट्स का उपयोग करने का प्रयास किया गया था,[citation needed] लेकिन ये कारनामे जावा का आंतरिक रूप से उपयोग नहीं करते हैं और कई अन्य तरीकों से भी वितरित किए गए थे।
हस्ताक्षरित
एक हस्ताक्षरित एप्लेट[30] में एक हस्ताक्षर होता है जिसे ब्राउज़र को दूरस्थ रूप से चलने वाले, स्वतंत्र प्रमाणपत्र प्राधिकरण सर्वर के माध्यम से सत्यापित करना चाहिए। इस हस्ताक्षर के निर्माण में विशेष उपकरण और प्राधिकरण सर्वर अनुरक्षकों के साथ सहभागिता सम्मिलित है। एक बार हस्ताक्षर सत्यापित हो जाने के बाद, वर्तमान मशीन का उपयोगकर्ता भी प्रमाणित हो जाता है, एक हस्ताक्षरित एप्लेट अधिक विशेषाधिकार प्राप्त कर सकता है, और एक साधारण स्टैंडअलोन प्रोग्राम के बराबर हो सकता है। तर्क यह है कि एप्लेट का लेखक अब जाना जाता है और किसी भी नुकसान के लिए जानबूझकर जिम्मेदार है।[vague] यह दृष्टिकोण एप्लेट्स को कई कार्यों के लिए उपयोग करने की अनुमति देता है जो क्लाइंट-साइड स्क्रिप्टिंग द्वारा अन्यथा संभव नहीं हैं। हालाँकि, इस दृष्टिकोण के लिए उपयोगकर्ता से अधिक जिम्मेदारी की आवश्यकता होती है, यह तय करना कि वह किस पर भरोसा करता है। संबंधित चिंताओं में एक गैर-उत्तरदायी प्राधिकरण सर्वर, प्रमाणपत्र जारी करते समय हस्ताक्षरकर्ता की पहचान का गलत मूल्यांकन, और ज्ञात एप्लेट प्रकाशक अभी भी कुछ ऐसा कर रहे हैं जिसे उपयोगकर्ता स्वीकार नहीं करेगा। इसलिए जावा 1.1 से प्रकट होने वाले हस्ताक्षरित एप्लेट्स में वास्तव में अधिक सुरक्षा चिंताएं हो सकती हैं।
स्व-हस्ताक्षरित
स्व-हस्ताक्षरित एप्लेट, जो स्वयं विकासक द्वारा हस्ताक्षरित एप्लेट हैं, संभावित रूप से सुरक्षा जोखिम पैदा कर सकते हैं, जावा प्लगइन्स स्व-हस्ताक्षरित एप्लेट के लिए प्राधिकरण का अनुरोध करते समय एक चेतावनी प्रदान करते हैं, क्योंकि एप्लेट के कार्य और सुरक्षा की गारंटी केवल विकासक द्वारा ही दी जाती है, और इसे स्वतंत्र रूप से सत्यापित नहीं किया गया है। इस तरह के स्व-हस्ताक्षरित प्रमाणपत्र आमतौर पर प्रकाशन से पहले केवल विकास के दौरान उपयोग किए जाते हैं जहां सुरक्षा का तृतीय-पक्ष सत्यापन महत्वहीन होता है, लेकिन अधिकांश एप्लेट विकासक्स यह सुनिश्चित करने के लिए तृतीय-पक्ष के हस्ताक्षर की तलाश करेंगे कि उपयोगकर्ता एप्लेट की सुरक्षा पर भरोसा करते हैं।
जावा सुरक्षा समस्याएं किसी क्लाइंट-साइड लिपिबद्धन प्लेटफॉर्म की समान समस्याओं से मौलिक रूप से भिन्न नहीं हैं[31][citation needed]. विशेष रूप से, हस्ताक्षरित एप्लेट्स से संबंधित सभी मुद्दे Microsoft माइक्रोसॉफ्ट एक्टिवएक्स घटकों पर भी लागू होते हैं।
2014 तक, स्व-हस्ताक्षरित और अहस्ताक्षरित एप्लेट्स अब सामान्य रूप से उपलब्ध जावा प्लगइन्स या जावा वेब स्टार्ट द्वारा स्वीकार नहीं किए जाते हैं। नतीजतन, विकासक्स जो जावा एप्लेट्स को तैनात करना चाहते हैं, उनके पास वाणिज्यिक स्रोतों से विश्वसनीय प्रमाणपत्र प्राप्त करने के अलावा कोई विकल्प नहीं है।
विकल्प
वैकल्पिक प्रौद्योगिकियां मौजूद हैं (उदाहरण के लिए, वेबअसेंबली[32] और जावास्क्रिप्ट) जो एक एप्लेट के साथ जो संभव था, उसके सभी या अधिक दायरे को संतुष्ट करती है। जावास्क्रिप्ट एक ही पृष्ठ में एप्लेट्स के साथ सह-अस्तित्व में हो सकता है,