2009-12-02 5 views
21

यदि आप सूर्य की मालिकाना जावा कक्षाओं का उपयोग करते हैं तो कंपाइलर डिस्प्ले चेतावनियां। मेरा मानना ​​है कि इन वर्गों का उपयोग करना आम तौर पर एक बुरा विचार है। मैंने इसे कहीं पढ़ा। हालांकि, चेतावनियों के अलावा वहां कोई मौलिक कारण हैं कि आपको उनका उपयोग क्यों नहीं करना चाहिए?सूर्य की मालिकाना जावा कक्षाओं का उपयोग करना एक बुरा अभ्यास है?

+2

कि पर्याप्त सामान्य सरकारी जावा एपीआई में सन्निहित हो जाएगा किसी भी कार्यक्षमता। क्या वास्तव में सूर्य वर्गों में कुछ ऐसा है जो आपको आवश्यक है और मानक जावा एपीआई के माध्यम से नहीं किया जा सकता है? क्या आप एक उदाहरण दे सकते हैं? –

+0

(मैंने कभी-कभी xml प्रसंस्करण के लिए आंतरिक xerces का उपयोग करके खुद को पकड़ लिया) –

+0

अच्छी तरह से xxp का उपयोग कर XML को संसाधित करते समय xx डिफ़ॉल्ट एक्सएमएल कार्यान्वयन है। नीचे पहुंचने और सीधे xerces का उपयोग करने की कोई आवश्यकता नहीं है। –

उत्तर

48

क्योंकि वे आंतरिक API हैं: वे एक अप्रलेखित या असमर्थित तरह से परिवर्तन के अधीन हैं और वे (अपने मामले में सूर्य) एक विशिष्ट JRE/JDK करने के लिए बाध्य कर रहे हैं, अपने कार्यक्रमों के पोर्टेबिलिटी सीमित।

ऐसे एपीआई के उपयोग से बचने का प्रयास करें, हमेशा सार्वजनिक दस्तावेज और निर्दिष्ट कक्षा को प्राथमिकता दें।

+3

'com.sun। *' के अंतर्गत कुछ एपीआई प्रयोगात्मक हैं (मूल एपीटी एपीआई उदाहरण के लिए थी)। आईआईआरसी, एलेक्स बकली इन एपीआई की विभिन्न स्थितियों पर एक ब्लॉग है। लेकिन हां, सामान्य रूप से वे अद्यतन रिलीज में और विक्रेताओं के बीच बदल सकते हैं या गायब हो सकते हैं। –

+1

मैंने इंटेलिजेंस सुझावों से com.sun को बाहर करने के लिए अपना जावा संपादक (इंटेलिजे आइडिया) सेट किया है। आपके सुझाव के लिए धन्यवाद। – skiabox

7

हां, क्योंकि कोई भी गारंटी नहीं देता है कि ये कक्षाएं या एपीआई अगली जावा रिलीज के साथ समान होगी और मुझे लगता है कि यह गारंटी नहीं है कि वे कक्षाएं अन्य विक्रेताओं से जावा संस्करणों में उपलब्ध हैं।

तो आप अपने कोड को विशेष जावा संस्करण में जोड़ते हैं और कम से कम पोर्टेबिलिटी खो देते हैं।

4

सूर्य की मालिकाना जावा कक्षाएं उनके जावा कार्यान्वयन का हिस्सा हैं, जावा एपीआई का हिस्सा नहीं, उनका उपयोग अनियंत्रित और असमर्थित है। चूंकि वे आंतरिक हैं, इसलिए किसी भी समय किसी भी कारण से सूर्य JVM का कार्य करने वाली टीम निर्णय ले सकती है।

इसके अलावा सूर्य का जावा कार्यान्वयन केवल एकमात्र नहीं है! आपका कोड ओरेकल/बीईए और आईबीएम जैसे अन्य विक्रेताओं से जेवीएम को पोर्टेबल नहीं कर पाएगा।

9

एक गैर सूर्य JVM के साथ अपने कोड चलाने की कोशिश करें और देखो क्या होता ...

(आपका कोड एक ClassNotFound अपवाद के साथ असफल हो जायेगी)

+4

यह समस्या की पहचान करने के लिए एक मान्य सुझाव है (* हालांकि उचित उत्तर नहीं है *)। – Esko

+1

@Esko, sigh, ने एक स्पष्टीकरण नोट जोड़ा ... –

+4

+1 एक बहुत व्यावहारिक उदाहरण के लिए +1 जो कि एक अनुमानित भविष्य की समस्या पर विचार करेगा – Brian

1

मैं हाल ही में एक मामले कि एक वास्तविक दुनिया से पता चला था जब आप इन कक्षाओं का उपयोग करते हैं तो आप हिट कर सकते हैं: हमारे पास कोड था जो संकलित नहीं करेगा क्योंकि एक विधि जो सूरज पर उपयोग कर रही थी। * कक्षा बस उबंटू पर ओपनजेडीके में मौजूद नहीं थी। तो मुझे लगता है कि इन कक्षाओं का उपयोग करते समय आप अब 'जावा 5 के साथ काम करता है' जैसी चीजें नहीं कह सकते हैं, क्योंकि यह केवल एक निश्चित जावा कार्यान्वयन पर काम करेगा।

+0

मैं दृढ़ता से विकास के लिए उपयोग करने के बजाय एक अलग मंच और JVM पर अपने unittests चलाने की सलाह दे सकता हूं। बहुत सारी रोचक चीजें दिखती हैं। –

19

JDK 6 Documentation में Note About sun.* Packages शीर्षक वाला एक लिंक शामिल है। यह, जावा 1.2 डॉक्स से एक दस्तावेज़ है तो sun.* के लिए संदर्भ व्यवहार किया जाना चाहिए जैसे कि वे कहा com.sun.*

यह सबसे महत्वपूर्ण बिंदु हैं:

वर्गों है कि सूर्य जावा 2 के साथ शामिल एसडीके, मानक संस्करण, पैकेज समूहों में java.*, javax.*, org.* और sun.* पर गिरें। sun.* पैकेज जावा प्लेटफ़ॉर्म का मानक हिस्सा हैं और भविष्य में का समर्थन किया जाएगा। सामान्य तौर पर, संकुल ऐसे sun.*, कि जावा मंच के बाहर हैं के रूप में, ओएस प्लेटफॉर्म (सोलारिस, विंडोज, लिनक्स, लबादा, आदि) भर में अलग हो सकता है और एसडीके संस्करणों के साथ बिना किसी पूर्व सूचना के किसी भी समय बदल सकते हैं (1.2, 1.2.1, 1.2.3, आदि)।प्रोग्राम जिसमें sun.* पैकेज पर सीधे कॉल शामिल हैं 100% शुद्ध जावा नहीं हैं।

और

प्रत्येक कंपनी को लागू करता है कि जावा मंच अपने स्वयं के निजी रास्ते में ऐसा ही करेगा। sun.* में कक्षाएं SDK में वर्तमान जावा मंच के सूर्य कार्यान्वयन का समर्थन कर रहे हैं: sun.* कक्षाएं जावा मंच वर्गों काम सन जावा 2 एसडीके के लिए " कवर के अंतर्गत" बनाने के क्या कर रहे हैं। ये कक्षाएं सामान्य रूप से अन्य विक्रेता के जावा प्लेटफ़ॉर्म पर मौजूद नहीं होंगी। यदि आपका जावा प्रोग्राम नाम से "sun.package.Foo" मांगता है, तो यह क्लास नॉटफाउंड एरर के साथ विफल हो सकता है, और आप जावा में विकसित होने का एक बड़ा लाभ खो चुके हैं।

+5

"कई सालों बाद" टिप्पणी के रूप में: इस बात की कोई गारंटी नहीं है कि 'com.sun। * '' Com.oracle' में नहीं बदलेगा। * क्योंकि सूर्य अब मौजूद नहीं है। – Powerlord

+0

यह सही नहीं है। कई 'com.sun। * 'पैकेज दस्तावेज विनिर्देश का हिस्सा हैं। उनके बिना जेएनडीआई एलडीएपी या कोसनामिंग कोड लिखना असंभव होगा। मुद्दा 'सूर्य। *' पैकेज है, जो एक पूरी तरह से अलग पदार्थ हैं और विशेष रूप से इस तरह के दस्तावेज हैं। – EJP

+1

बीटीडब्ल्यू, 'सूर्य। *' और 'com.sun। *' कक्षाओं का उपयोग करने की कोशिश कर रहा है, जावा 9 पर शानदार रूप से असफल हो जाएंगे। – Powerlord

2

यहाँ Oracle की जवाब है: Why Developers Should Not Write Programs That Call 'sun' Packages

+3

जबकि यह सैद्धांतिक रूप से सवाल का जवाब दे सकता है, [यह बेहतर होगा] (http: // मेटा। stackexchange.com/q/8259) यहां उत्तर के आवश्यक हिस्सों को शामिल करने के लिए, और संदर्भ के लिए लिंक प्रदान करें। – BoltClock