JDK राज

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

क्लीनर

हर अच्छा जावा प्रोग्रामर जानता है कि फाइनली दुष्ट हैं । लेकिन इस मामले में उन्हें कैसे बदला जा सकता है, अगर कोई गारंटी नहीं है कि हमारे पुस्तकालय का उपयोग करने वाले हर कोई, सभ्य प्रोग्रामर के रूप में, बंद होगा ()? आखिर JDK के अंदर क्या इस्तेमाल होता है?
सिस्टम क्लासेस में, Sun.misc.Cleaner, फैंटम रीफरेंस के आधार पर, फाइनल के लिए अधिक विश्वसनीय और हल्के प्रतिस्थापन के रूप में उपयोग किया जाता है। जैसे ही कचरा संग्रहकर्ता यह पता लगाता है कि क्लीनर द्वारा संदर्भित ऑब्जेक्ट प्रेत-पहुंच योग्य हो गया है , निर्दिष्ट Runnable लॉन्च किया जाएगा, आमतौर पर संसाधनों को मुक्त करने के लिए:

public NeedsCleanup() { this.resource = unsafe.allocateMemory(16*1024*1024); Cleaner.create(this, new Destructor(resource)); } private static class Destructor implements Runnable { final long resource; Destructor(long resource) { this.resource = resource; } public void run() { unsafe.freeMemory(resource); } } 

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

MappedByteBuffer को अनमैप करना

और यहाँ JDK सिस्टम कक्षाओं में क्लीनर का एक उदाहरण है।
जिन लोगों ने FileChannel.map () के माध्यम से जावा में मेमोरी-मैप की गई फ़ाइलों का उपयोग किया था, शायद उन्हें एक बार से अधिक पछतावा हुआ कि MappedByteBuffer के पास कोई अनमैप () विधि नहीं थी। उसके कारण हैं।
लेकिन, जैसा कि कहा जा रहा है, यदि आप नहीं कर सकते, लेकिन वास्तव में चाहते हैं, तो आप कर सकते हैं। MappedByteBuffer का कार्यान्वयन बफर संग्रह के बाद अनुपलब्ध होने पर कचरा संग्रहण के बाद क्लीनर को निष्पादित करने के लिए बनाता है। तो, इस क्लीनर को मैन्युअल रूप से भी कहा जा सकता है:

  public static void unmap(MappedByteBuffer bb) { if (bb instanceof sun.nio.ch.DirectBuffer) { ((sun.nio.ch.DirectBuffer) bb).cleaner().clean(); } } 

SharedSecrets

एक पेचीदा नाम, है ना? sun.misc.SaringSecrets एक उपयोगिता वर्ग है जो सिस्टम कक्षाओं के कुछ निजी डेटा तक पहुंचने के लिए इंटरफेस प्रदान करता है। हालांकि वहाँ बहुत दिलचस्प नहीं है। आप कह सकते हैं, किसी भी भरी हुई कक्षा के निरंतर पूल में जा सकते हैं ... बस यह मत पूछिए कि क्यों :)
जावा फाइलडेसिटर ऑब्जेक्ट से एक देशी (ओएस-लेवल) फाइल डिस्क्रिप्टर प्राप्त करने के लिए मुझे जो कुछ मिलता था, उससे। यह इस तरह किया जाता है:

  public static int getNativeFD(FileDescriptor fd) { return SharedSecrets.getJavaIOFileDescriptorAccess().get(fd); } 

या यहां एक और उदाहरण है कि कैसे कंसोल के एन्कोडिंग का पता लगाया जाए जिससे जावा एप्लिकेशन चल रहा है:

  if (System.console() != null) { System.out.println(SharedSecrets.getJavaIOAccess().charset()); } 

SignalHandler

लेकिन क्या आप जानते हैं कि जावा प्रोग्राम में POSIX सिग्नल को पकड़ना और प्रोसेस करना संभव है, उदाहरण के लिए, SIGINT?
हाँ, sun.misc.ignal और sun.misc.SignalHandler कक्षाओं का उपयोग।
हालाँकि, मैं इस पर ध्यान नहीं दूंगा, क्योंकि इस विषय पर पहले ही एक लेख आ चुका है ।

MagicAccessor

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

 // ----- A.java ----- class A { private int privateField = 5; } // ----- B.java ----- class B extends sun.reflect.MagicAccessorBridge { public static void main(String[] args) { A a = new A(); a.privateField = 10; System.out.println(a.privateField); } } // ----- MagicAccessorBridge.java ----- package sun.reflect; public class MagicAccessorBridge extends MagicAccessorImpl { // Since MagicAccessorImpl is package-private, we'll make a public bridge } 

केवल एक समस्या: केवल जेवीएम मैजिक एक्सेसर के बारे में जानता है, लेकिन जेवैक नहीं, जो लगातार अनधिकृत पहुंच पर शपथ लेना जारी रखेगा। उदाहरण का परीक्षण करने के लिए, आपको पहले कक्षा A में सार्वजनिक करने के लिए फ़ील्ड संशोधक को बदलना होगा, सब कुछ संकलित करना होगा, फिर निजी संशोधक को वापस करना होगा और वर्ग A को अलग-अलग करना होगा। बेशक, यह असुविधाजनक है, इसलिए, व्यवहार में, MagicAccessorImpl से विरासत में केवल तभी समझ में आता है जब कक्षा गतिशील रूप से उत्पन्न होती है। वैसे, JDK ट्रेजरी में इस मामले के लिए उपकरण हैं: sun.tools.asm.Assembler और पूरा पैकेज sun.tools.asm।

चेतावनी: सूर्य स्वामित्व एपीआई

जैसे ही आप उपरोक्त वर्गों में से किसी एक के साथ या सूरज से किसी अन्य के साथ अपने कार्यक्रम को पतला करने का प्रयास करते हैं। * पैकेज, आपको निश्चित रूप से संकलक से चेतावनी मिलेगी

चेतावनी: sun.misc.Unsafe सन मालिकाना एपीआई है और भविष्य में रिलीज में हटाया जा सकता है

जो किसी भी एनोटेशन से दबाया नहीं जा सकता है, और ठीक है!

आप खुश हो सकते हैं या परेशान हो सकते हैं, लेकिन जेडीके 7 में, आखिरकार, कष्टप्रद चेतावनी को छिपाना संभव हो गया। हालांकि, फिर से, केवल एक गुप्त कुंजी की मदद से :)

एक विधि या वर्ग में एनोटेशन जोड़ें
@SuppressWarnings("sunapi")

और पैरामीटर के साथ javac चलाएं
javac -XDenableSunApiLintControl TestUnsafe.java

यह सब, प्रयोग का रास्ता स्पष्ट है!