जावा एप्लेट

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

जावा एप्लेट्स को जावा भाषा के पहले संस्करण में पेश किया गया था, जो 1995 में जारी किया गया था। 2013 में शुरू हुआ, NPAPI#समर्थन/बहिष्करण, एप्लेट्स के 2015-2017 तक चलने में पूरी तरह से असमर्थ होने के साथ। जावा एप्लेट्स को 2017 में जावा 9 द्वारा बहिष्कृत कर दिया गया था। जावा एप्लेट आमतौर पर जावा में लिखे जाते थे, लेकिन अन्य भाषाएँ जैसे ज्योथन, जेरुबी, पास्कल (प्रोग्रामिंग भाषा), Scala (प्रोग्रामिंग भाषा), NetRexx, या Eiffel (प्रोग्रामिंग भाषा) (SmartEiffel के माध्यम से) का भी उपयोग किया जा सकता है।

जावा एप्लेट बहुत तेज गति से चलते हैं और 2011 तक वे जावास्क्रिप्ट से कई गुना तेज थे। जावास्क्रिप्ट के विपरीत, जावा एप्लेट्स के पास 3डी हार्डवेयर त्वरण तक पहुंच थी, जो उन्हें गैर-तुच्छ, संगणना-गहन विज़ुअलाइज़ेशन के लिए अच्छी तरह से अनुकूल बनाता है। जैसा कि ब्राउज़र ने हार्डवेयर-त्वरित ग्राफिक्स के लिए कैनवास तत्व प्रौद्योगिकी (या विशेष रूप से 3D ग्राफिक्स के मामले में WebGL) के लिए समर्थन प्राप्त किया है, साथ ही समय-समय पर संकलन|बस-समय-समय पर संकलित जावास्क्रिप्ट, गति अंतर कम ध्यान देने योग्य हो गया है। चूंकि जावा बाइटकोड क्रॉस-प्लेटफॉर्म (या प्लेटफ़ॉर्म स्वतंत्र) है, जावा एप्लेट्स को Microsoft Windows, FreeBSD, Unix, macOS और Linux सहित कई प्लेटफ़ॉर्म के लिए क्लाइंट (कंप्यूटिंग) द्वारा निष्पादित किया जा सकता है। वे मोबाइल उपकरणों पर नहीं चलाए जा सकते थे, जो मानक Oracle JVM बायटेकोड चलाने का समर्थन नहीं करते हैं। एंड्रॉइड (ऑपरेटिंग सिस्टम) डिवाइस एंड्रॉइड रनटाइम के लिए संकलित जावा में लिखे कोड चला सकते हैं।

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

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

HTML में कोडित पृष्ठ एप्लेट को पास किए गए पैरामीटर को अपने भीतर एम्बेड कर सकते हैं। इस वजह से, पास किए गए पैरामीटर के आधार पर एक ही एप्लेट में एक अलग उपस्थिति हो सकती है।

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

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

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

जावा स्टेटिक लाइब्रेरी और क्रम पुस्तकालय पिछड़े-संगत हैं, जो किसी को कोड लिखने की इजाजत देता है जो जावा वर्चुअल मशीन के वर्तमान और भविष्य के दोनों संस्करणों पर चलता है।

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

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

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

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

जावा ब्राउज़र प्लग-इन NPAPI पर निर्भर था, जिसकी आयु और सुरक्षा समस्याओं के कारण लगभग सभी वेब ब्राउज़र विक्रेताओं ने इसके लिए समर्थन हटा दिया है या लागू नहीं करते हैं। जनवरी 2016 में, Oracle ने घोषणा की कि JDK 9 पर आधारित जावा रनटाइम वातावरण ब्राउज़र प्लग-इन को बंद कर देगा।

लाभ
जावा एप्लेट में निम्नलिखित में से कोई एक या सभी लाभ हो सकते हैं:
 * इसे FreeBSD, Linux, Microsoft Windows और macOS पर काम करना आसान था – यानी इसे क्रॉस-प्लेटफॉर्म बनाना है। 21वीं सदी के पहले दशक में एप्लेट्स को अधिकांश वेब ब्राउज़रों द्वारा समर्थित किया गया था; तब से, अधिकांश ब्राउज़रों ने सुरक्षा कारणों से एप्लेट समर्थन छोड़ दिया है।
 * केवल नवीनतम प्लग-इन (कंप्यूटिंग) | प्लग-इन संस्करण के बजाय एक ही एप्लेट एक ही समय में जावा के सभी स्थापित संस्करणों पर काम करेगा। हालाँकि, यदि किसी एप्लेट को जावा वर्चुअल मशीन (JRE) के बाद के संस्करण की आवश्यकता होती है, तो क्लाइंट को बड़े डाउनलोड के दौरान प्रतीक्षा करने के लिए मजबूर किया जाएगा।
 * अधिकांश वेब ब्राउज़र एप्लेट्स को वेब कैश करते हैं ताकि वे वेब पेज पर लौटते समय जल्दी से लोड हो सकें। उपयोग के साथ एप्लेट्स में भी सुधार हुआ: पहले एप्लेट के चलने के बाद, जेवीएम पहले से ही चल रहा था और बाद के एप्लेट्स जल्दी से शुरू हो गए (ब्राउज़र के नए सिरे से शुरू होने पर हर बार जेवीएम को फिर से शुरू करने की आवश्यकता होगी)। JRE संस्करण 1.5 और उच्चतर ने JVM को फिर से शुरू किया जब ब्राउज़र पृष्ठों के बीच नेविगेट करता है, एक सुरक्षा उपाय के रूप में जिसने उस प्रदर्शन लाभ को हटा दिया।
 * यह काम को सर्वर (कंप्यूटिंग) से क्लाइंट (कंप्यूटिंग) तक ले गया, जिससे वेब समाधान उपयोगकर्ताओं/क्लाइंटों की संख्या के साथ अधिक स्केलेबल हो गया।
 * यदि एक स्टैंडअलोन प्रोग्राम (जैसे Google धरती) एक वेब सर्वर से बात करता है, तो उस सर्वर को सामान्य रूप से उन उपयोगकर्ताओं के लिए सभी पूर्व संस्करणों का समर्थन करने की आवश्यकता होती है जिन्होंने अपने क्लाइंट सॉफ़्टवेयर को अद्यतन नहीं रखा है। इसके विपरीत, एक ब्राउज़र नवीनतम एप्लेट संस्करण को लोड (और कैश्ड) करता है, इसलिए लीगेसी संस्करणों का समर्थन करने की कोई आवश्यकता नहीं है।
 * एप्लेट स्वाभाविक रूप से बदलती उपयोगकर्ता स्थिति का समर्थन करता है, जैसे शतरंज की बिसात पर आकृति की स्थिति।
 * विकासकर्ता केवल एक मुख्य दिनचर्या (या तो एप्लेट की कक्षा में या एक अलग वर्ग में) बनाकर और एप्लेट पर init और start को कॉल करके एक एप्लेट को सीधे विकसित और डिबग कर सकते हैं, इस प्रकार अपने पसंदीदा जावा प्लेटफॉर्म में विकास की अनुमति देते हैं, मानक संस्करण विकास पर्यावरण। यह सुनिश्चित करने के लिए कि यह सुरक्षा प्रतिबंधों के अनुरूप है, AppletViewer प्रोग्राम या वेब ब्राउज़र में एप्लेट को फिर से परीक्षण करना था।
 * एक ब्राउज़र सुरक्षा एप्लेट की स्थानीय मशीन तक पहुंच नहीं थी और वह केवल उस सर्वर तक पहुंच सकता है जिससे वह आया था। यह एप्लेट्स को उनके द्वारा बदले जाने वाले देशी निष्पादन योग्यों की तुलना में चलाने के लिए अधिक सुरक्षित बनाता है। हालाँकि, एक हस्ताक्षरित एप्लेट को उस मशीन तक पूरी पहुँच प्राप्त हो सकती है जिस पर वह चल रहा है, यदि उपयोगकर्ता सहमत हो।
 * जावा एप्लेट तेज थे, मूल रूप से इंस्टॉल किए गए सॉफ्टवेयर के जावा प्रदर्शन के साथ।

नुकसान
अन्य क्लाइंट-साइड वेब तकनीकों की तुलना में जावा एप्लेट्स में निम्नलिखित नुकसान थे:


 * जावा एप्लेट जावा रनटाइम एनवायरनमेंट (जेआरई) पर निर्भर करेगा, जो एक जटिल और भारी सॉफ्टवेयर पैकेज है। उन्हें सामान्य रूप से वेब ब्राउज़र के लिए प्लग-इन (कंप्यूटिंग)|प्लग-इन की भी आवश्यकता होती है। कुछ संगठन केवल व्यवस्थापक द्वारा इंस्टॉल किए गए सॉफ़्टवेयर की अनुमति देते हैं। परिणामस्वरूप, उपयोगकर्ता एप्लेट्स को तब तक देखने में असमर्थ थे जब तक कि एक जेआरई और प्लग-इन की स्थापना का अनुरोध करने के लिए व्यवस्थापक से संपर्क करने का औचित्य साबित करने के लिए पर्याप्त महत्वपूर्ण न हो।
 * यदि किसी एप्लेट को सिस्टम पर उपलब्ध नए जेआरई की आवश्यकता है, तो इसे पहली बार चलाने वाले उपयोगकर्ता को बड़े जेआरई डाउनलोड को पूरा करने के लिए इंतजार करना होगा।
 * आईओएस या एंड्रॉइड (ऑपरेटिंग सिस्टम) पर मोबाइल ब्राउज़र, कभी भी जावा एप्लेट्स नहीं चलाते हैं। सभी प्लेटफार्मों पर एप्लेट्स के बहिष्करण से पहले ही, मोबाइल ऑपरेटिंग सिस्टम के उदय के साथ-साथ डेस्कटॉप ब्राउज़रों ने जावा एप्लेट समर्थन को समाप्त कर दिया।
 * एप्लेट्स की सामग्री को स्क्रीन रीडर्स के लिए उपलब्ध कराने के लिए कोई मानक नहीं था। इसलिए, एप्लेट्स ने विशेष जरूरतों वाले उपयोगकर्ताओं के लिए एक वेब साइट की पहुंच को नुकसान पहुंचाया।
 * जैसा कि किसी क्लाइंट-साइड स्क्रिप्टिंग के साथ होता है, सुरक्षा प्रतिबंधों ने कुछ अविश्वसनीय एप्लेट्स के लिए अपने वांछित लक्ष्यों को प्राप्त करना कठिन या असंभव बना दिया। केवल JAVA JRE स्थापना में java.policy फ़ाइल को संपादित करके कोई स्थानीय फाइल सिस्टम या सिस्टम क्लिपबोर्ड तक पहुंच प्रदान कर सकता है, या ब्राउज़र को एप्लेट प्रदान करने वाले नेटवर्क के अलावा अन्य नेटवर्क स्रोतों तक पहुंच प्रदान कर सकता है।
 * अधिकांश उपयोगकर्ता अविश्वसनीय और विश्वसनीय एप्लेट्स के बीच के अंतर के बारे में परवाह नहीं करते थे, इसलिए इस अंतर से सुरक्षा में ज्यादा मदद नहीं मिली। सभी एप्लेट्स को हटाने से पहले अविश्वसनीय एप्लेट्स को चलाने की क्षमता को अंततः इसे ठीक करने के लिए पूरी तरह से हटा दिया गया था।

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

1997: सन बनाम माइक्रोसॉफ्ट
1997 का मुकदमा, माइक्रोसॉफ्ट द्वारा संशोधित माइक्रोसॉफ्ट जावा वर्चुअल मशीन बनाने के बाद दायर किया गया था, जिसे इंटरनेट एक्सप्लोरर के साथ भेज दिया गया था। Microsoft ने लगभग 50 विधियाँ और 50 फ़ील्ड जोड़े java.awt, java.lang, और java.io संकुल के भीतर कक्षाओं में। अन्य संशोधनों में जावा दूरस्थ विधि मंगलाचरण क्षमता को हटाना और जावा मूल इंटरफ़ेस को JNI से Java नेटिव इंटरफ़ेस#Alternatives, एक अलग मानक में बदलना शामिल है। RMI को हटा दिया गया था क्योंकि यह केवल जावा से जावा संचार का आसानी से समर्थन करता है और Microsoft वितरित घटक ऑब्जेक्ट मॉडल तकनीक के साथ प्रतिस्पर्धा करता है। एप्लेट्स जो इन परिवर्तनों पर भरोसा करते थे या अनजाने में उनका उपयोग करते थे, केवल माइक्रोसॉफ्ट के जावा सिस्टम के भीतर ही काम करते थे। सन ने ट्रेडमार्क के उल्लंघन के लिए मुकदमा दायर किया, क्योंकि जावा का बिंदु यह था कि कोई मालिकाना विस्तार नहीं होना चाहिए और वह कोड हर जगह काम करना चाहिए। Microsoft Sun को $20 मिलियन का भुगतान करने के लिए सहमत हो गया, और Sun केवल संशोधनों के बिना और सीमित समय के लिए Java का उपयोग करने के लिए Microsoft को सीमित लाइसेंस देने पर सहमत हो गया।

2002: सन बनाम माइक्रोसॉफ्ट
माइक्रोसॉफ्ट ने अपनी खुद की असंशोधित जावा वर्चुअल मशीन को शिप करना जारी रखा। इन वर्षों में यह बहुत पुराना हो गया था फिर भी इंटरनेट एक्सप्लोरर के लिए डिफ़ॉल्ट था। बाद के एक अध्ययन से पता चला कि इस समय के एप्लेट्स में अक्सर उनकी अपनी कक्षाएं होती हैं जो स्विंग (जावा) और अन्य नई सुविधाओं को सीमित तरीके से दर्पण करती हैं। 2002 में, सन ने एक अविश्वास मुकदमा दायर किया, जिसमें दावा किया गया कि माइक्रोसॉफ्ट के अवैध विमुद्रीकरण के प्रयासों ने जावा प्लेटफॉर्म को नुकसान पहुंचाया है। सन ने माइक्रोसॉफ्ट से विंडोज के हिस्से के रूप में जावा तकनीक के सन के वर्तमान, बाइनरी कार्यान्वयन को वितरित करने, पुराने माइक्रोसॉफ्ट डेस्कटॉप ऑपरेटिंग सिस्टम के लिए अनुशंसित अद्यतन के रूप में वितरित करने और माइक्रोसॉफ्ट की वर्चुअल मशीन के वितरण को रोकने की मांग की (जैसा कि इसके लाइसेंसिंग समय, पूर्व मुकदमे में सहमत था, था) खत्म हो चुका)। माइक्रोसॉफ्ट ने लंबित एंटीट्रस्ट मुद्दों के लिए $700 मिलियन, पेटेंट मुद्दों के लिए $900 मिलियन और भविष्य में सन के सॉफ्टवेयर का उपयोग करने के लिए $350 मिलियन रॉयल्टी शुल्क का भुगतान किया।

सुरक्षा
बहुत भिन्न सुरक्षा मॉडल वाले दो एप्लेट प्रकार थे: हस्ताक्षरित एप्लेट और अहस्ताक्षरित एप्लेट। जावा एसई 7 अपडेट 21 (अप्रैल 2013) से शुरू होकर एप्लेट्स और वेब-स्टार्ट ऐप्स को एक विश्वसनीय प्रमाणपत्र के साथ हस्ताक्षर करने के लिए प्रोत्साहित किया जाता है, और अहस्ताक्षरित एप्लेट्स चलाते समय चेतावनी संदेश दिखाई देते हैं। इसके अलावा, जावा 7 अपडेट 51 से शुरू होने वाले अहस्ताक्षरित एप्लेट्स को डिफ़ॉल्ट रूप से ब्लॉक कर दिया गया था; उन्हें जावा कंट्रोल पैनल में एक अपवाद बनाकर चलाया जा सकता है।

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

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

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

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

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

जावा सुरक्षा समस्याएं किसी क्लाइंट-साइड स्क्रिप्टिंग प्लेटफॉर्म की समान समस्याओं से मौलिक रूप से भिन्न नहीं हैं. विशेष रूप से, हस्ताक्षरित एप्लेट्स से संबंधित सभी मुद्दे Microsoft ActiveX घटकों पर भी लागू होते हैं।

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

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

यह भी देखें

 * एक्टिवएक्स
 * कर्ल (प्रोग्रामिंग भाषा)
 * जकार्ता सर्वलेट
 * जावा वेब स्टार्ट
 * JavaFX
 * समृद्ध वेब अनुप्रयोग
 * वेबजीएल

बाहरी संबंध

 * Latest version of Sun Microsystems' Java Virtual Machine (includes browser plug-ins for running Java applets in most web browsers).
 * Information about writing applets from Oracle
 * Demonstration applets from Sun Microsystems (JDK 1.4 – include source code)