यह विशेष रूप से जावा के संदर्भ में कुछ भी मतलब नहीं है।
एक वर्ग अयोग्य बस एक संपत्ति है जो एक वर्ग के सभी उदाहरणों के लिए है, हमेशा, कोई फर्क नहीं पड़ता कि अन्य कोड क्या करता है।
उदाहरण के लिए,
class X {
final Y y = new Y();
}
एक्स के पास वर्ग अयोग्य है कि एक yसंपत्ति है और यह कभी नहीं है nullऔर इसका प्रकार का मूल्य है Y।
class Counter {
private int x;
public int count() { return x++; }
}
दो महत्वपूर्ण आक्रमणकारियों को बनाए रखने में विफल रहता है
countसंभावित बहाव के कारण इसका नकारात्मक मान कभी नहीं लौटता है।- यह
countपुख्ता तौर पर नीरस वृद्धि करने वाली कॉल हैं।
संशोधित वर्ग उन दो आक्रमणकारियों को संरक्षित करता है।
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
लेकिन अपरिवर्तनीय को संरक्षित करने में विफल रहता है जो countसामान्य रूप से हमेशा सफल होने के लिए कहता है (अनुपस्थित टीसीबी-उल्लंघन ) the क्योंकि countएक अपवाद फेंक सकता है या यह ब्लॉक हो सकता है यदि कोई डेडलॉक धागा काउंटर के मॉनिटर का मालिक है।
कक्षाओं के साथ प्रत्येक भाषा कुछ वर्ग के आक्रमणकारियों को बनाए रखना आसान बनाती है, लेकिन दूसरों को नहीं। जावा कोई अपवाद नहीं है:
- जावा कक्षाओं में लगातार गुण या विधियां नहीं होती हैं, इसलिए इंटरफ़ेस आक्रमणकारियों को बनाए रखना आसान होता है।
- जावा कक्षाएं अपने
privateक्षेत्रों की रक्षा कर सकती हैं, इसलिए निजी डेटा पर भरोसा करने वाले आक्रमणकारियों को बनाए रखना आसान है।
- जावा कक्षाएं अंतिम हो सकती हैं, इसलिए आक्रमणकारी जो इस बात पर भरोसा करते हैं कि कोई कोड नहीं है जो एक दुर्भावनापूर्ण उपवर्ग का निर्माण करके किसी आक्रमणकारी का उल्लंघन करता है, उसे बनाए रखा जा सकता है।
- जावा
nullकई मायनों में मूल्यों को छलनी करने की अनुमति देता है, इसलिए इसे बनाए रखने के लिए कठिन है "एक वास्तविक मूल्य" अपरिवर्तनीय है।
- जावा में थ्रेड्स होते हैं, जिसका अर्थ है कि जो कक्षाएं सिंक्रनाइज़ नहीं होती हैं, उन्हें एक साथ होने वाले थ्रेड में अनुक्रमिक संचालन पर भरोसा करने वाले आक्रमणकारियों को बनाए रखने में परेशानी होती है।
- जावा में ऐसे अपवाद हैं, जो "हमेशा संपत्ति पी के साथ एक परिणाम देता है या कोई परिणाम नहीं देता है" जैसे आक्रमणकारियों को बनाए रखना आसान बनाता है, लेकिन "हमेशा परिणाम देता है" जैसे आक्रमणकारियों को बनाए रखना मुश्किल होता है।
† - एक बाह्यता या TCB उल्लंघन एक घटना है जो एक सिस्टम डिजाइनर आशावादी मान लिया गया है नहीं होगा है।
आमतौर पर हम सिर्फ इस बात पर भरोसा करते हैं कि मूल हार्डवेयर विज्ञापन के रूप में काम करता है जब उन पर निर्मित उच्च-स्तरीय भाषाओं के गुणों के बारे में बात की जाती है, और हमारे तर्क जो आक्रमण करते हैं, वे इसकी संभावना को ध्यान में नहीं रखते हैं:
- एक प्रोग्रामर डिबग हुक का उपयोग करके स्थानीय चर को प्रोग्राम के रूप में बदल सकता है जो कोड नहीं कर सकता है।
- आपके साथी लुकअप टेबल
setAccessibleको संशोधित करने के लिए प्रतिबिंब का उपयोग नहीं करते हैं private।
- लोकी ने भौतिकी को बदल दिया जिससे आपके प्रोसेसर को दो नंबरों की तुलना गलत तरीके से करनी पड़ी।
कुछ प्रणालियों के लिए हमारे TCB में सिस्टम के कुछ भाग शामिल हो सकते हैं, इसलिए हम ऐसा नहीं मान सकते
- एक व्यवस्थापक या विशेषाधिकार प्राप्त डेमन हमारी JVM प्रक्रिया को नहीं मारेंगे,
लेकिन हम यह मान सकते हैं
- हम एक विश्वसनीय ट्रांसेक्शनल फाइल-सिस्टम की जांच कर सकते हैं।
एक उच्च-स्तरीय प्रणाली, आमतौर पर इसका टीसीबी जितना बड़ा होता है, लेकिन जितनी अधिक अविश्वसनीय चीजें आप अपने टीसीबी से बाहर निकल सकते हैं, उतनी ही संभावना है कि आपके आक्रमणकारियों को पकड़ना होगा, और आपका सिस्टम लंबे समय में अधिक विश्वसनीय होगा।