मुझे पता है कि पैकेज java.lang हमारे द्वारा लिखे गए प्रत्येक जावा प्रोग्राम द्वारा स्वतः आयात किया जाता है, इसलिए इसमें सभी कक्षाएं स्वचालित रूप से हमारे लिए उपलब्ध होती हैं।क्यों jim.lang पैकेज autoimport?
मेरा सवाल यह है कि ऑटो आयात java.util और अन्य पैकेज भी आयात नहीं करते हैं? यह निश्चित रूप से कुछ टाइपिंग बचाएगा :)
तो कृपया समझाएं कि ऐसा क्यों नहीं किया गया है।
नामस्थान स्विच से बचने के लिए बहुत अधिक ऑटोमोटपोर्ट न करने का एक अच्छा कारण है। यदि java.util में सबकुछ स्वचालित रूप से आयात किया गया था और फिर आप 'मानचित्र' नामक एक अलग वर्ग को संदर्भित करना चाहते थे, उदाहरण के लिए, आपको इसे अपने पूर्ण-योग्य नाम से संदर्भित करना होगा।
इस धागे में अन्य उत्तरों के जवाब में, import वास्तव में आपकी कक्षा फ़ाइलों के आंतरिक प्रतिनिधित्व को संशोधित नहीं करता है। वास्तव में, कक्षा फ़ाइल संरचना का वर्णन करने वाले जेवीएम स्पेक में link है: देखें कि आयात कहीं भी संग्रहीत नहीं हैं।
+1, यह असली जवाब आईएमओ है। – MAK
+1: केवल इतना ही नहीं, लेकिन जावा क्लास लाइब्रेरी में भी कुछ नामनाम अलग-अलग नामस्थानों में दिखाई देते हैं। उदाहरण के लिए: java.util.List और java.awt.List। – Powerlord
यह एक तरह का है "ऐसा इसलिए है क्योंकि यह" उत्तर है। निश्चित रूप से, यदि आप एक और नक्शा (java.util) चाहते थे, तो आपको इसे पूरी तरह अर्हता प्राप्त करनी होगी, लेकिन यदि आप एक और प्रक्रिया (java.lang) चाहते हैं तो आपको अभी भी करना होगा। प्रश्न बनी हुई है: java.lang में कक्षाओं के सेट के बारे में इतना खास क्या है कि यह हमेशा आयात किया जाता है, और कुछ भी नहीं है? क्या गोस्लिंग सोचते थे कि हम सूची से अधिक बार स्ट्रिक्टैथ का उपयोग करेंगे? – Ken
सभी अच्छे आईडीई के स्वचालित रूप से आपके आयात को हल करेंगे, केवल एक संघर्ष होने पर ही संकेत मिलेगा (उसी वर्गनाम के साथ दो पैकेज)।
क्योंकि java.lang में कोर जावा भाषा कक्षाएं हैं, और java.util उदाहरण के लिए नहीं।
लेकिन कुछ अन्य भाषाओं, ग्रूवी तरह अपने आप आपके लिए java.util आयात करता है :)
मुझे लगता है कि java.lang के पीछे विचार यह है कि इन कक्षाओं में सभी भाषा और रनटाइम जो खास है करने के लिए कुछ कनेक्शन है, और अपने आप को लागू नहीं किया जा सकता है। आदिम रैपर, वीएम सुरक्षा और अनुमतियां और निरीक्षण, पैकेज और कक्षा लोडिंग - सभी चीजें जो जावा सिस्टम में अंतर्निहित होनी चाहिए। Java.util में सब कुछ, संग्रह की तरह, जबकि अविश्वसनीय रूप से उपयोगी, शुद्ध जावा में लागू किया जा सकता है। इसके कुछ हिस्सों (समय क्षेत्र दिमाग में आते हैं) को तीसरे पक्ष के पुस्तकालयों द्वारा भी बेहतर किया गया है।
या कम से कम, यह जावा 1.0 दिनों में सच था। आज, उदाहरण के लिए, इटरेटर भी भाषा के अभिन्न अंग है, क्योंकि यह स्वचालित रूप से प्रत्येक लूप के लिए उपयोग किया जाता है, है ना? लेकिन पीछे की संगतता हमेशा जावा के साथ एक बड़ी बात थी, इसलिए हम हमेशा के लिए इस असंगतता के साथ जीते हैं।
यह वास्तव में चीजों की व्याख्या नहीं करता है। वे सिर्फ java.lang की तुलना में कुछ भी नहीं कर सकते थे या ऑटोमपोर्ट नहीं कर सकते थे।ऑटोमोट्स एक सुविधा सुविधा है। – Antimony
मैं java.lang.System के साथ नामस्थान टक्कर के साथ आया (हमारे आवेदन में कक्षा नामक एक प्रणाली है)। एक स्पष्ट आयात ने मेरी समस्या हल की, लेकिन इसमें कुछ मिनट लग गए जब तक कि मैंने इंगित नहीं किया कि com.mycompany.classes.System ग्रहण द्वारा पहचानकर्ता प्रणाली के लिए स्वचालित रूप से आयात नहीं किया गया है क्योंकि यह पहले से ही java.lang में मौजूद है।
फिर भी, यह एक अच्छा विचार बहुत ज्यादा पहचान का वर्ग गुंजाइश अपवित्र करने के लिए नहीं है क्योंकि आपके कोड होगा org.classes.**look** com.application.**like** com.classes.**this**.
स्वत: आयात करने java.lang एक अच्छा विचार है, क्योंकि यह बहुत कोर वर्गों और इंटरफेस का इस्तेमाल किया होता है जावा में
@gameover, हो सकता है कि हर जावा कार्यक्रम वर्ग कि java.lang से आता है,
की जरूरत है लेकिन java.util वर्ग वर्ग कि या जरूरत Be My कि प्रोग्रामर पर निर्भर नहीं हैं। तो जावा के पास java.lang के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन है लेकिन हमें हमारे कार्यक्रम के अनुसार java.util कक्षाओं में आयात करने की आवश्यकता है।
ऑटो आयात भी कुछ स्मृति समस्या का कारण बनता है और कुछ बार यह संघर्ष कर सकता है। उदाहरण: जावा & एसक्यूएल में दिनांक प्रकार।
जो भी मूल कोर जावा ऑब्जेक्ट्स Java.lang पैकेज में परिभाषित किया गया है। उदाहरण: किसी भी डेटाटाइप & वापसी प्रकार सभी java.lang पैकेज में घोषित किए गए हैं ताकि कुछ बुनियादी कार्यक्रम भी हमें इस पैकेज आयात की आवश्यकता हो।
यह रनटाइम मेमोरी समस्याओं का कारण नहीं है। और संकलन समय के मुद्दों की संभावना सबसे अधिक महत्वहीन है –
java.lang पैकेज जावा प्रोग्राम बनाने के लिए मौलिक कक्षाएं प्रदान करता है। ऑब्जेक्ट क्लास पदानुक्रम की जड़ है इसलिए इसे प्रत्येक प्रोग्रामर के लिए उपलब्ध होना चाहिए कि प्रोग्रामर शुरुआती या विशेषज्ञ है या नहीं।
यदि हम अन्य पैकेजों के बारे में बात करते हैं तो इनका उपयोग कार्यक्रमों को बढ़ाने के लिए किया जाता है। उदाहरण के लिए, java.util पैकेज जिसका उपयोग केवल तब किया जाता है जब संग्रह कक्षाओं की आवश्यकता होती है। जबकि प्रत्येक कार्यक्रम में संग्रह कक्षाओं का उपयोग नहीं किया जाता है, जबकि प्रत्येक जावा कार्यक्रम के लिए बुनियादी डेटाटाइप आवश्यक होते हैं।
प्रोग्राम में अन्य कक्षाओं के अनावश्यक भार से बचने के लिए अन्य पैकेज ऑटो आयात नहीं किए जाते हैं जबकि आवश्यक पैकेज java.lang स्वतः आयात किया जाता है।
java.lang बनने के लिए पैकेज वास्तव में डिफ़ॉल्ट 1) है के लिए अलग अलग हो, जो कुछ भी हम जावा में चर घोषित कर रहे हैं program.that वस्तु में संग्रहीत किया जाएगा रहे हैं, वस्तु वर्ग java.lang package.it में उपलब्ध है वर्ग पदानुक्रम की सुपर क्लास है, कई हमने ऑब्जेक्ट क्लास विधि जैसे थ्रेड प्रोग्रामिंग में ऑपरेशन किया है। 2) कई बार यह कार्यक्रम विकसित करने के लिए वर्ग की आवश्यकता है, उस वर्ग java.lang पैकेज में उपलब्ध है, इसलिए, यह आवश्यक आयात करने के लिए है, जब जावा लोगों JDK विकसित की है, यह डिफ़ॉल्ट पैकेज,
था java.lang बिना पैकेज, विकास संभव नहीं है। लेकिन बिना java.util, java.io या कोई अन्य पैकेज, हम अभी भी किसी भी प्रोग्राम को लिख सकते हैं। यही कारण है कि java.lang पैकेज डिफ़ॉल्ट रूप से आयात किया जा रहा है।
अलग-अलग पैकेज होने का क्या उपयोग है यदि हम उन्हें केवल एक पैकेज में रख सकें और इसे स्वचालित रूप से आयात कर सकें? उसके बारे में सोचना। – MAK
हां .. इसके बारे में सोचा। सवाल क्यों है !! ऐसा क्यों नहीं किया जाता है? – gameover