आप कभी भी जावा फ़ाइल क्यों नहीं चाहते हैं जिसमें कोई सार्वजनिक कक्षा घोषित न हो?

Question

पुस्तक मैं SCJP योग्यता के लिए पढ़ रहा हूँ में एक बयान भी नहीं है, यह कहते हैं:

फ़ाइलें कोई सार्वजनिक वर्गों के साथ कोई नामकरण प्रतिबंध है

मुझसे पूछते हैं बना दिया है यही कारण है, आप कभी ऐसा क्यों करना चाहते हैं?

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

Answer 1

यह package-private कक्षाओं के लिए भी मान्य है। और आप एक ही पैकेज के भीतर पैकेज-निजी कक्षाओं का उपयोग कर सकते हैं। (और उस स्थिति में आपको इसे आयात करने की आवश्यकता नहीं है, क्योंकि यह एक ही पैकेज में है।)

उदाहरण के लिए, JapaneseImperialCalendar कक्षा पैकेज-निजी है, क्योंकि इसका उपयोग केवल Calendar.createCalendar(..) से किया जाता है - यह इसका हिस्सा नहीं है सार्वजनिक एपीआई। आप सीधे जापानी कैलेंडर को तुरंत चालू नहीं कर सकते हैं, लेकिन आप अभी भी का उपयोग अपने इंटरफ़ेस द्वारा कर सकते हैं। Collections.unmodifiableList(..) जैसे तरीकों से प्राप्त सभी अपरिवर्तनीय संग्रहों के लिए वही है - वे पैकेज-निजी हैं।

तो की .java फ़ाइल मनमाने ढंग से हो सकती थी। हालांकि, यह सलाह दी जाती है कि कक्षा के नाम के बाद भी पैकेज-निजी फाइलों का नामकरण करने के स्थापित अभ्यास से अलग न हो जाएं।

Answer 2

Java Classes से, आपके पास सार्वजनिक कक्षाएं और पैकेज कक्षाएं हैं। पैकेज कक्षाओं को "निजी" माना जाता है ताकि आप उन्हें केवल पैकेज के भीतर ही उपयोग कर सकें। यह डिफ़ॉल्ट है, यानी सार्वजनिक निर्दिष्ट है।

सार्वजनिक कक्षाएं, ज़ाहिर है, कक्षाएं जिन्हें आप कहीं भी बना सकते हैं।

Answer 3

आप package-info.java नाम की एक फ़ाइल बना सकते हैं, जिसमें केवल package कथन शामिल है। जावाडोक 1.5+ टूल इस पैकेज कथन पर एक javadoc टिप्पणी का इलाज करता है जैसे कि package.html फ़ाइल। इसके अतिरिक्त, आप इस कथन में @Generated जैसे पैकेज-स्तरीय एनोटेशन जोड़ सकते हैं, जो आप package.html में नहीं कर सकते हैं।

क्योंकि package-info मान्य जावा पहचानकर्ता नहीं है, इस फ़ाइल का कोई भी मौजूदा जावा क्लास (यानी पिछड़ा संगतता) के साथ कभी भी संघर्ष करने का कोई जोखिम नहीं है।

Answer 4

मैं गैर-प्रतिबंध से सहमत नहीं हूं। प्रत्येक जावा फ़ाइल में केवल एक शीर्ष स्तर की कक्षा होनी चाहिए, और फ़ाइल का नाम वर्ग का नाम, सार्वजनिक या नहीं होना चाहिए। मुझे नहीं लगता कि javac यह बहुत ज्यादा (या किसी भी इंसान) चाहते हैं

A.java 
    class B 

B.java 
    class A 

---

http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.3

7 है।संकुल

के लिए 2 होस्ट समर्थन प्रत्येक मेजबान कैसे संकुल, संकलन इकाइयों को निर्धारित करता है, और सबपैकेज बनाई गई हैं और संग्रहीत है, और जो संकलन इकाइयों एक विशेष संकलन में (§7.3) नमूदार हैं।

7.2.1 एक फाइल सिस्टम

एक अत्यंत साधारण उदाहरण के रूप में संकुल भंडारण,

---

http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html

दोनों स्रोत और वर्ग फ़ाइलों जड़ नाम होना आवश्यक है कि कक्षा की पहचान करें। उदाहरण के लिए, एक वर्ग MyClass नामक एक स्रोत फ़ाइल MyClass.java कहा जाता है और एक बाईटकोड वर्ग फ़ाइल MyClass.class कहा जाता है में संकलित में लिखा जाएगा।

Answer 5

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

java.util पैकेज

class JumboEnumSet<E extends Enum<E>> extends EnumSet<E> 

इस वर्ग में मौजूद पर एक नज़र डालें इसके अलावा एक ही पैकेज

class RegularEnumSet<E extends Enum<E>> extends EnumSet<E> 

तुम देखो उन दोनों साथ घोषणा की जाती है के भीतर देख नहीं स्पष्ट संशोधक। क्या आपने सोचा है कि पैकेज निजी प्रतिबंध क्यों है? यहाँ अद्भुत किताब प्रभावी जावा 2 संस्करण से कारण यहोशू बलोच # आइटम 1

वर्ग java.util.EnumSet (आइटम 32), द्वारा रिलीज 1.5 में शुरू की गई है, कोई सार्वजनिक कंस्ट्रक्टर्स है, केवल स्थिर कारखानों। अंतर्निहित enum प्रकार के आकार के आधार पर, वे दो कार्यान्वयन में से एक लौटते हैं: यदि इसमें अधिकांश एनम प्रकार हैं, तो स्थिर कारखानों में एक RegularEnumSet उदाहरण देता है, जिसे एकल द्वारा समर्थित किया जाता है, लंबा; अगर enum प्रकार में पच्चीस या अधिक तत्व हैं, तो कारखानियां एक जंबोइनमसेट उदाहरण लौटाती हैं, जो लंबे सरणी द्वारा समर्थित है।

ले जाएँ तेजी पर, वह आगे adds-

इन दो कार्यान्वयन वर्गों के अस्तित्व ग्राहकों के लिए अदृश्य है। यदि RegularEnumSet छोटे enum प्रकारों के प्रदर्शन लाभ प्रदान करने के लिए बंद कर दिया गया है, तो इसे बीमार प्रभावों के साथ भविष्य की रिलीज से समाप्त किया जा सकता है।इसी तरह, भविष्य में रिलीज एक तीसरा या चौथा एनमसेट के कार्यान्वयन को जोड़ सकता है यदि यह प्रदर्शन के लिए फायदेमंद साबित हुआ। ग्राहक न तो वस्तु के वर्ग के बारे में जानते हैं और न ही देखभाल करते हैं, उन्हें कारखाने से वापस मिलता है; वे केवल देखभाल करते हैं कि यह EnumSet का कुछ उप-वर्ग है।