जावा एप्लेट

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

जावा एप्लेट्स को जावा भाषा के पहले संस्करण में पेश किया गया था, जो 1995 में जारी किया गया था। 2013 की शुरुआत में, प्रमुख वेब ब्राउज़रों ने एप्लेट्स को चलाने के लिए उपयोग की जाने वाली अंतर्निहित प्रौद्योगिकी के लिए समर्थन को समाप्त करना शुरू कर दिया, साथ ही एप्लेट्स 2015-2017 तक चलने में पूरी तरह से असमर्थ हो गए। जावा एप्लेट्स को 2017 में जावा 9 द्वारा बहिष्कृत कर दिया गया था।

जावा एप्लेट आमतौर पर जावा में लिखे जाते थे, लेकिन अन्य भाषाएँ जैसे ज्योथन, जेरुबी, पास्कल (प्रोग्रामिंग भाषा), स्काला (प्रोग्रामिंग भाषा), नेटरेक्स, या एफिल (प्रोग्रामिंग भाषा) (स्मार्टएफिल के माध्यम से) का भी उपयोग किया जा सकता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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

बाहरी संबंध

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