Java.io क्यों नहीं था। सरलीज़ेज़ेबल जावा 5 में बहिष्कृत?

Question

पूर्व जावा 5 में, कोई टिप्पणी नहीं थी। नतीजतन आप कक्षा में मेटाडेटा नहीं जोड़ सके।

public class MyClass implements Serializable { 
    ... 
    private transient Bla field; 
    ... 
} 

:

एक वर्ग के रूप serializable की तरह कुछ चिह्नित करने के लिए, आप Serializable इंटरफ़ेस को लागू करने के लिए किया था (जो सिर्फ इतना है कि, एक मार्कर है) और गैर serializable के रूप में एक क्षेत्र चिह्नित करने के लिए आगे transient खोजशब्दों का उपयोग यदि आवश्यक हो,

अब आप सैद्धांतिक रूप से एनोटेशन का उपयोग कर सकता (यह उनके लिए एक सही उपयोग है) और है:

@Serializable 
public class MyClass { 
    ... 
    @Transient 
    private Bla field; 
    ... 
} 

लेकिन इंटरफ़ेस और कीवर्ड पदावनत नहीं थे और कोई टिप्पणी जावा 5 में जोड़ा गया इनका स्थान ले लेंगे ।

इंटरफ़ेस और कीवर्ड रखने के इस निर्णय के लिए क्या विचार हैं?

बेशक पूर्व जावा 5 कोड के साथ संगतता का मुद्दा है, लेकिन कुछ बिंदु पर यह समाप्त होगा (उदा। जेनिक्स की नई विशेषताओं से संबंधित, जेएलएस निर्दिष्ट करता है कि It is possible that future versions of the Java programming language will disallow the use of raw types)। तो क्यों serialized एनोटेशन के लिए रास्ता तैयार नहीं है?

कोई विचार? (हालांकि मैं ठोस संदर्भ पसंद करेंगे: डी जो मैं खोजने में असमर्थ था)

Answer 1

इंटरफेस है, इसलिए पद्धतियां प्रकार Serializable की वस्तुओं को स्वीकार करने में परिभाषित किया जा सकता है:

public void registerObject(Serializable obj); 

Answer 2

Serializable और transient वास्तव में कर रहे दो चीजें जिन्हें एनोटेशन द्वारा प्रतिस्थापित किया जा सकता था।

वे शायद पदावनत नहीं किया गया है क्योंकि वहाँ प्रोग्राम हैं जो Serializable का उपयोग का एक बहुत रहे हैं और यह लाखों लोगों की डेवलपर्स अगर अगर संकलक अचानक प्रतिवाद चेतावनी के हजारों बाहर उगल शुरू होगा के लिए कष्टप्रद हो गया होता।

मानक जावा एपीआई में कई अन्य चीजें हैं जिन्हें बहुत पहले हटा दिया जा सकता था - उदाहरण के लिए, विरासत संग्रह कक्षा Vector और Hashtable (और मुझे यकीन है कि आप आसानी से कई और चीजें पा सकते हैं)। और ऐसी कई चीजें हैं जिन्हें एनोटेशन का उपयोग करके लागू किया जा सकता था (उदाहरण के लिए कीवर्ड volatile, strictfp और synchronized)।

Answer 3

जरुर वहाँ पूर्व जावा 5 कोड के साथ संगतता का मुद्दा है ...

हां। यह समस्या की जड़ है।

• वे में (जैसे) जावा 5 Serializable इंटरफ़ेस @deprecated है, तो वर्ष पूर्व जावा 5 कोड के बहुत सारे चेतावनी (या त्रुटियों संकलक स्विच के आधार पर) देना होगा।

• Serializable का उपयोग करने में वास्तव में कुछ भी गलत नहीं है और लोगों को इसे बदलने के लिए "मजबूर" करना कष्टप्रद है। (लोगों के पास बेहतर चीजें हैं ...)

• जब लोगों ने अपने कोड में "निश्चित" किया है, तो यह अब प्री-जावा 5 कंपाइलर का उपयोग करके संकलित नहीं होगा, या प्री-जावा 5 जेवीएम पर चलाएगा।

• उन चीजों को करने का एक बुरा विचार है जो संकलक व्यवस्थित रूप से "रोना भेड़िया" बनाते हैं।

... लेकिन कुछ का कहना है कि खत्म हो जाएगा पर।

हकीकत में, इस वास्तव में हो रहा की संभावना (IMO) छोटा है। जहां तक ​​मुझे पता है, सूर्य/ओरेकल के पास कभी एक बहिष्कृत सुविधा को हटा दिया गया है। Thread.stop() और दोस्तों जैसे खतरनाक भी नहीं।

---

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

Answer 4

बहिष्करण उन चीजों के लिए है जो सक्रिय रूप से हानिकारक हैं। आप जो सुझाव दे रहे हैं वह आठ साल के मौजूदा जावा कोड (उस समय) के लेखकों को फिर से लिखने के लिए मजबूर कर रहा है, बिना किसी लाभ के, केवल बहिष्करण कंपाइलर चेतावनियों को बंद करने के लिए, जावा 1.4 के साथ उनके पूर्ण कोड पर वापस जाने के लिए । यह उपयोगी नहीं होगा।