जावा में सीरियलाइजेशन: एक ब्लैक बॉक्स के अंदर कैसे दिखें

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

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


अनुवादक से:
शनिवार। शाम को। इस दिन कुछ भी नहीं किया गया था, लेकिन अचानक मुझे याद आया कि यह जांचना अच्छा होगा कि हमारा काम हडूप क्लस्टर पर कैसा है, ठीक उसी तरह जैसे हमारे विवेक को शांत करने के लिए - समस्या हल हो गई है ...

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

लेकिन वहाँ यह था!
खडुप ने गवाही दी कि इस दुर्भाग्यपूर्ण शनिवार को एक भी कार्य पूरा नहीं हुआ।
क्रैश का कारण पिछले एक से कुछ अलग था: कार्य ट्रैकर कार्य शुरू नहीं कर सका, क्योंकि इसमें कार्य कॉन्फ़िगरेशन की xml-file को लोड करने के लिए पर्याप्त मेमोरी नहीं थी।

बेशक, मुझे तुरंत आश्चर्य हुआ कि किस प्रकार के राक्षसी विन्यास वहां संग्रहीत हैं? काश, एक बड़ा हिस्सा पचास मेगाबाइट के क्रमिक रूप से बूँद द्वारा कब्जा कर लिया गया था। बूँद में एक दर्जन विभिन्न वर्गों की वस्तुओं का ग्राफ शामिल है, जिनके लिए निश्चित रूप से मेरे पास कोई स्रोत नहीं है।

अकेले कामचलाऊ उपकरणों की मदद से शनिवार शाम को इस बहु-मेगाबाइट बाइनरी के साथ क्या किया जा सकता है?

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

यह एक हैक है, ज़ाहिर है, लेकिन कभी-कभी बिना हैक के - कहीं नहीं।

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

दरअसल, लेख:

जब एक सार्वजनिक एपीआई पर्याप्त नहीं है

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

उदाहरण के लिए, आपके पास एक दूरस्थ RMI ऑब्जेक्ट के लिए एक स्टब है, और आप जानना चाहते हैं कि यह किस पते या पोर्ट के माध्यम से कनेक्ट होगा, या कौन सा RMI सॉकेट फैक्टरी (RMIClientSocketFactory) का उपयोग करेगा। मानक RMI API स्टब से जानकारी निकालने का कोई तरीका नहीं प्रदान करता है। Deserialization के बाद कार्य करने के लिए ठूंठ के लिए, यह जानकारी क्रमबद्ध रूप में मौजूद होनी चाहिए। इसलिए, हम आवश्यक जानकारी प्राप्त कर सकते हैं यदि हम केवल किसी तरह से क्रमबद्ध स्टब को पार्स कर सकते हैं।

दूसरा उदाहरण जेएमएक्स एपीआई से लिया गया है । MBean सर्वर के अनुरोधों को QueryExp इंटरफ़ेस द्वारा दर्शाया गया है। QueryExp उदाहरण क्वेरी वर्ग विधियों का उपयोग करके बनाया गया है। यदि आपकी वस्तु QueryExp से संबंधित है, तो आपको कैसे पता चलेगा कि यह क्या प्रश्न करता है? JMX API पता लगाने का कोई तरीका नहीं देता है। जानकारी को क्रमबद्ध रूप में प्रस्तुत किया जाना चाहिए ताकि जब कोई ग्राहक किसी दूरस्थ सर्वर से अनुरोध करे, तो उसे सर्वर पर पुनर्स्थापित किया जा सके। यदि हम क्रमबद्ध रूप देख सकते हैं, तो हम यह निर्धारित कर सकते हैं कि अनुरोध क्या था।

दूसरे उदाहरण ने मुझे इस पुस्तकालय को लिखने के लिए प्रेरित किया। मौजूदा मानक JMX कनेक्टर जावा क्रमांकन पर आधारित हैं, इसलिए उन्हें QueryExps के किसी विशेष हैंडलिंग की आवश्यकता नहीं है। लेकिन नई वेब सेवाओं में
जेएसआर 262 में पेश किया गया कनेक्टर क्रमबद्धता के लिए एक्सएमएल का उपयोग करता है। QueryExp को पार्स कैसे करें, फिर इसे XML में बदलें? उत्तर सरल है: क्रमबद्ध QueryExp के अंदर देखने के लिए WS कनेक्टर इस लाइब्रेरी के संस्करण का उपयोग करता है।

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

हम वस्तुओं के निजी क्षेत्रों में घुस जाते हैं

यदि आपके पास उन कक्षाओं का स्रोत कोड है जिनमें आप रुचि रखते हैं, तो प्रलोभन बस वांछित डेटा प्राप्त करने और लेने के लिए है। RMI स्टब के साथ उदाहरण में, हम प्रयोगात्मक रूप से पता लगा सकते हैं कि getRef () स्टब विधि sun.rmi.server.UnicastRef देता है, और JDK स्रोतों का अध्ययन करने के बाद, हमें पता चलता है कि इस वर्ग में ref.f के प्रकार का फ़ील्ड शामिल है sun.rmi.transport.LiveRef, जानकारी की जरूरत है कि समय के साथ। इसलिए हमें इस कोड जैसा कुछ मिलता है (लेकिन मैं इसे पहले से कहूंगा, आपको ऐसा नहीं करना चाहिए):

import sun.rmi.server.*; import sun.rmi.transport.*; import java.rmi.*; import java.rmi.server.*; public class StubDigger { public static getPort(RemoteStub stub) throws Exception { RemoteRef ref = stub.getRef(); UnicastRef uref = (UnicastRef) ref; Field refField = UnicastRef.class.getDeclaredField("ref"); refField.setAccessible(true); LiveRef lref = (LiveRef) refField.get(uref); return lref.getPort(); } } 

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

(यह कोड JDK 5 के लिए लिखा गया था। जैसा कि यह निकला, JDK 6 में LiveRef ने सार्वजनिक getPort () विधि का अधिग्रहण किया, इसलिए अब आपको Field.setAccessible की आवश्यकता नहीं है। लेकिन किसी भी मामले में, आपको सूरज पर निर्भर नहीं होना चाहिए। * कक्षाएं।)

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

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

अनुक्रमित रूप का विवरण जावदोक में प्रत्येक वर्ग के लिए देखें भी लागू किया जा रहा है। आप सभी सार्वजनिक JDK वर्गों के क्रमबद्ध रूपों को एक विशाल पृष्ठ पर पा सकते हैं।

नमस्ते सिरियलिसिस!

क्रमबद्ध वस्तुओं के मेटाडेटा प्राप्त करने के लिए मेरी लाइब्रेरी को "सीरियल विश्लेषण" शब्दों के संयोजन से, सीरियलियलिसिस कहा जाता है।

मैं एक सरल उदाहरण दूंगा कि यह कैसे काम करता है। यह कोड ...

  SEntity sint = SerialScan.examine(new Integer(5)); System.out.println(sint); 

... यह लाएगा ...

 SObject(java.lang.Integer){ value = Prim(int){5} } 

इससे पता चलता है कि java.lang.Integer प्रकार की एक वस्तु, जिसे हमने SerialScan.examine को दिया था, को ऑब्जेक्ट के रूप में क्रमबद्ध किया जाता है, जिसमें अंदर int के एकल क्षेत्र के साथ एक वस्तु होती है। यदि हम प्रलेखित क्रमबद्ध रूप java.lang.Integer की जाँच करते हैं , तो हम देखेंगे कि यह वही है जो अपेक्षित था।

यदि आप स्रोत कोड java.lang.Integer को देखते हैं, तो आप देखेंगे कि वर्ग में भी एक ही प्रकार का फ़ील्ड है int:

 /** * The value of the <code>Integer</code>. * * @serial */ private final int value; 

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

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

यदि हम ArrayList के क्रमबद्ध रूप में देखते हैं, तो हम देखेंगे कि इसमें वह जानकारी है जो हम खोज रहे हैं। यह क्रमबद्ध फ़ील्ड आकार को इंगित करता है, जो सूची में आइटम की संख्या है, लेकिन वह नहीं है जो हमें चाहिए। लेकिन WriteObject पद्धति में द्विआधारी डेटा में वही होता है जो आपको चाहिए:

सीरियल डेटा:
आंतरिक ArrayList की लंबाई होती है, और इसके पीछे - दिए गए क्रम में सभी तत्व (प्रत्येक वस्तु के रूप में)।

अगर हम यह कोड चलाते हैं ...

 List<Integer> list = new ArrayList<Integer>(); list.add(5); SObject slist = (SObject) SerialScan.examine(list); System.out.println(slist); 

... तो हमें निम्नलिखित निष्कर्ष मिलता है ...

 SObject(java.util.ArrayList){ size = SPrim(int){1} -- data written by class's writeObject: SBlockData(blockdata){4 bytes of binary data} SObject(java.lang.Integer){ value = SPrim(int){5} } } 

यहाँ हम अपने आप को क्रमबद्धता के अंधेरे जंगल में पाते हैं। ऑब्जेक्ट फ़ील्ड को अनुक्रमित करने के अलावा, या इसके बजाय, एक क्लास में राइटऑबजेक्ट (ObjectOutputStream) विधि हो सकती है जो ऑब्जेक्टOutputStream.writeInt प्रकार के तरीकों का उपयोग करके किसी स्ट्रीम को मनमाना डेटा लिखती है। क्लास में संबंधित रीडऑबजेक्ट विधि भी होनी चाहिए, जो एक ही डेटा को पढ़ती है, और @serialData टैग की मदद से यह लिखना आवश्यक है कि वास्तव में WriteObject विधि क्या लिखती है, जैसे कि यह ArrayList में किया गया था।

Serialysis में राइटऑबजेक्ट डेटा SObject.getAnnotations () विधि के माध्यम से प्राप्त किया जा सकता है, जो एक सूची देता है। ObjectOutputStream.writeObject (ऑब्जेक्ट) विधि का उपयोग करके दर्ज की गई प्रत्येक वस्तु इस सूची में एक SObject के रूप में दिखाई देती है। DataOutput ( writeInt , writeUTF वगैरह ) से विरासत में मिली ObjectOutputStream विधियों में एक या एक से अधिक लगातार कॉल द्वारा दर्ज किए गए डेटा के प्रत्येक टुकड़े को SBlockData के रूप में दर्शाया गया है। एक अनुक्रमित धारा आपको इस टुकड़े के भीतर व्यक्तिगत तत्वों का चयन करने की अनुमति नहीं देती है; यह जानकारी लेखक और पाठक के बीच, @serialData टैग में प्रलेखित है।

ArrayList के दस्तावेज़ीकरण के आधार पर, हम इस तरह से सरणी का आकार प्राप्त कर सकते हैं:

 SObject slist = (SObject) SerialScan.examine(list); List<SEntity> writeObjectData = slist.getAnnotations(); SBlockData data = (SBlockData) writeObjectData.get(0); DataInputStream din = data.getDataInputStream(); int alen = din.readInt(); System.out.println("Array length: " + alen); 

कैसे Serialysis मेरा परीक्षण कार्य हल करती है

पूर्ण स्रोत कोड को स्वीकार करते हुए, मैं केवल QueryExp समस्या के समाधान की रूपरेखा तैयार करूंगा, जिसके बारे में मैंने शुरुआत में बात की थी। मान लीजिए कि मेरे पास QueryExp इस तरह बनाया गया है:

 QueryExp query = Query.or(Query.gt(Query.attr("Version"), Query.value(5)), Query.eq(Query.attr("SupportsSpume"), Query.value(true))); 

इसका अर्थ है: "मुझे 5 से अधिक वर्जन विशेषता वाले एमबीयनर्स दें या सत्य के बराबर सपोर्टस्पर्म विशेषता।" JDK में इस अनुरोध के लिए .String () इस तरह दिखता है:

 ((Version) > (5)) or ((SupportsSpume) = (true)) 

और यह वही है जो SerialScan.examine का परिणाम दिखता है:

 SObject(javax.management.OrQueryExp){ exp1 = SObject(javax.management.BinaryRelQueryExp){ relOp = SPrim(int){0} exp1 = SObject(javax.management.AttributeValueExp){ attr = SString(String){"version"} } exp2 = SObject(javax.management.NumericValueExp){ val = SObject(java.lang.Long){ value = SPrim(long){5} } } } exp2 = SObject(javax.management.BinaryRelQueryExp){ relOp = SPrim(int){4} exp1 = SObject(javax.management.AttributeValueExp){ attr = SString(String){"supportsSpume"} } exp2 = SObject(javax.management.BooleanValueExp){ val = SPrim(boolean){true} } } } 

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

अब RMI स्टब में पोर्ट नंबर की समस्या को हल करने वाला कोड:

  public static int getPort(RemoteStub stub) throws IOException { SObject sstub = (SObject) SerialScan.examine(stub); List<SEntity> writeObjectData = sstub.getAnnotations(); SBlockData sdata = (SBlockData) writeObjectData.get(0); DataInputStream din = sdata.getDataInputStream(); String type = din.readUTF(); if (type.equals("UnicastRef")) return getPortUnicastRef(din); else if (type.equals("UnicastRef2")) return getPortUnicastRef2(din); else throw new IOException("Can't handle ref type " + type); } private static int getPortUnicastRef(DataInputStream din) throws IOException { String host = din.readUTF(); return din.readInt(); } private static int getPortUnicastRef2(DataInputStream din) throws IOException { byte hasCSF = din.readByte(); String host = din.readUTF(); return din.readInt(); } 

इसे समझने के लिए, क्रमबद्ध रिमोटऑबजेक्ट फॉर्म के विवरण पर एक नज़र डालें।

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

निष्कर्ष

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

इसके अलावा, यह सत्यापित करने का एक अच्छा तरीका है कि आपकी अपनी कक्षाएं ठीक उसी तरह क्रमबद्ध हैं जैसी आप उम्मीद करते हैं।

आप यहाँ से Serialysis लाइब्रेरी डाउनलोड कर सकते हैं: http://weblogs.java.net/blog/emcmanus/serialysis.zip ।