2012-04-30 10 views
19

मैंने क्लाइंट और सर्वर बनाया और फिर क्लाइंट साइड में क्लाइंट साइड में क्लास साइडिंग के लिए एक क्लास जोड़ा, फिर बस मेरे हार्ड ड्राइव में क्लाइंट के फ़ोल्डर में गया और इसे कॉपी करें सर्वर correponding स्थान, क्रमशः classname.class और classname.java दोनों।java.io.InvalidClassException: स्थानीय वर्ग असंगत:

यह मेरी अपनी लैपटॉप में अच्छी तरह से काम लेकिन जब मैं अन्य प्रणाली, जब मैं परियोजनाओं फ़ोल्डरों खोला और ग्राहक सर्वर से कनेक्ट करने की कोशिश करता है के बाद, निम्न त्रुटि दिखाई देता है पर मेरे काम जारी रखना चाहते हैं:

Exception in thread "main" java.io.InvalidClassException: projectname.clasname; local class incompatible: stream classdesc serialVersionUID = -6009442170907349114, local class serialVersionUID = 6529685098267757690 
    at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562) 
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) 
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) 
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) 
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) 
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) 

क्या चल रहा है? क्या ऐसा इसलिए है क्योंकि मैंने आईडीई के पुराने संस्करण के साथ प्रोग्राम चलाया था?

संपादित

import java.io.Serializable; 
import java.net.URL; 


public class KeyAdr implements Serializable{ 

     private static final long serialVersionUID = 6529685098267757690L; 


public URL adr; 
public String key; 


} 

उत्तर

27

एक वर्ग स्पष्ट रूप से कोड में एक private static final long serialVersionUID को परिभाषित नहीं करता है यह स्वतः जेनरेट किया जाएगा, और कोई गारंटी नहीं कि विभिन्न मशीनों एक ही आईडी उत्पन्न होगा नहीं है; ऐसा लगता है कि वास्तव में क्या हुआ। यदि वर्ग किसी भी तरह से अलग हैं (वर्ग के विभिन्न संस्करणों का उपयोग करके) स्वत: उत्पन्न serialVersionUID एस भी अलग होगा।

से

Serializable इंटरफेस के docs:

एक serializable वर्ग स्पष्ट रूप से एक serialVersionUID घोषित नहीं होता है, तो क्रमबद्धता क्रम वर्ग के विभिन्न पहलुओं के आधार पर उस वर्ग के लिए एक डिफ़ॉल्ट serialVersionUID मूल्य की गणना करेगा, के रूप में वर्णित जावा (टीएम) ऑब्जेक्ट सीरियलाइजेशन विशिष्टता में। हालांकि, यह दृढ़ता से की सिफारिश की गई है कि सभी धारावाहिक वर्ग स्पष्ट रूप से serialVersionUID मानों की घोषणा करते हैं, क्योंकि डिफ़ॉल्ट serialVersionUID गणना कक्षा विवरणों के प्रति अत्यधिक संवेदनशील होती है जो संकलक कार्यान्वयन के आधार पर भिन्न हो सकती हैं, और इस प्रकार deserialization के दौरान अप्रत्याशित InvalidClassExceptions हो सकता है। इसलिए, विभिन्न जावा कंपाइलर कार्यान्वयन में एक सतत serialVersionUID मान की गारंटी के लिए, एक धारावाहिक वर्ग को एक स्पष्ट serialVersionUID मान घोषित करना होगा। यह भी दृढ़ता से सलाह दी जाती है कि स्पष्ट serialVersionUID घोषणाएं private संशोधक का उपयोग जहां संभव हो, क्योंकि ऐसी घोषणाएं केवल तुरंत घोषित कक्षा पर लागू होती हैं - serialVersionUID फ़ील्ड विरासत वाले सदस्यों के रूप में उपयोगी नहीं हैं। ऐरे कक्षाएं एक स्पष्ट serialVersionUID घोषित नहीं कर सकती हैं, इसलिए उनके पास हमेशा डिफ़ॉल्ट गणना मूल्य होता है, लेकिन serialVersionUID मानों के मिलान की आवश्यकता सरणी कक्षाओं के लिए माफ कर दी जाती है।

आप वर्ग परिभाषा में एक serialVersionUID परिभाषित करना चाहिए, उदा .:

class MyClass implements Serializable { 
    private static final long serialVersionUID = 6529685098267757690L; 
    ... 
+0

परिभाषा में serialVersionUID को समायोजित करने के लिए कैसे? – lonesome

+0

अभी भी एक ही त्रुटि होती है – lonesome

+0

यह अजीब बात है। मैं दोबारा जांच करूंगा कि दोनों पक्ष कक्षा के नवीनतम संस्करण का उपयोग कर रहे हैं। – trutheality

0

मेरा मानना ​​है कि ऐसा होता है क्योंकि आप क्लाइंट और सर्वर पर एक ही कक्षा के विभिन्न संस्करणों का उपयोग करें। यह अलग-अलग डेटा फ़ील्ड या विधियां हो सकती हैं

0

जावा में सीरियलाइजेशन दीर्घकालिक दृढ़ता या परिवहन प्रारूप के रूप में नहीं है - यह इसके लिए बहुत नाजुक है। कक्षा बाइटकोड और जेवीएम में मामूली अंतर के साथ, आपका डेटा अब और पठनीय नहीं है।अपने कार्य के लिए एक्सएमएल या जेएसओएन डाटा-बाइंडिंग का उपयोग करें (XStream उपयोग करने में तेज़ और आसान है, और विकल्पों में से एक टन है)

+2

मैं दृढ़ता के लिए एक डिग्री से सहमत हो सकता हूं लेकिन जावा सीरियलाइजेशन को परिवहन प्रारूप के रूप में उपयोग करने में कुछ भी गलत नहीं है। यदि कोई जावा धारावाहिकता की अवधारणाओं को 'serialVersionUID' की अवधारणाओं को नहीं जानता है तो यह बहुत नाजुक है। –

+0

तब भी यह नाजुक है। –

+0

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

0

अपवाद संदेश स्पष्ट रूप से कक्षा संस्करणों को बोलता है, जिसमें क्लास मेटा डेटा भी शामिल होगा समय के साथ बदल गया है। दूसरे शब्दों में, सीरियलाइजेशन के दौरान कक्षा संरचना de-serialization के दौरान समान नहीं है। यह शायद सबसे अधिक "चल रहा है" है।

संबंधित मुद्दे