जावा स्रोत कोड संकुल के बारे में सोचें एक बड़े पदानुक्रमित नामस्थान के रूप में। वाणिज्यिक अनुप्रयोग आमतौर पर 'com.mycompany.myapp' के अंतर्गत रहते हैं (इस एप्लिकेशन की वेबसाइट 'http://myapp.mycompany.com' हालांकि यह स्पष्ट रूप से हमेशा मामला नहीं है)।
आप अपने मैप पैकेज के तहत सामान कैसे व्यवस्थित करते हैं, यह आपके लिए काफी हद तक निर्भर है। निष्पादन योग्य (.exe), डीएलएल और निम्न-स्तरीय कक्षाओं के बीच आप सी # के लिए जो भेद बनाते हैं वह जावा में एक ही रूप में मौजूद नहीं है। सभी जावा स्रोत कोड को .class फ़ाइलों में संकलित किया गया है (जिनकी सामग्री 'बाइटकोड' कहा जाता है) जिसे कई प्लेटफ़ॉर्म पर जावा वर्चुअल मशीन (JVM) द्वारा निष्पादित किया जा सकता है। इसलिए उच्च स्तरीय/निम्न-स्तरीय कक्षाओं में कोई अंतर्निहित भेद नहीं है, जब तक कि आप अपने पैकेजिंग के माध्यम से ऐसे स्तरों को श्रेय न दें। पैकेजिंग का एक आम तरीका है:
- com.mycompany.myapp: मुख्य वर्ग; MyApp (मुख्य विधि के साथ)
- com.mycompany.myapp.model: डोमेन मॉडल कक्षाएं; ग्राहक, आदेश, आदि
- com.mycompany.myapp.ui: यूजर इंटरफेस (प्रस्तुति या दृश्य) कोड
- com.mycompany.myapp.service: आपके आवेदन के भीतर सेवाओं, यानी 'व्यापार तर्क'
- कॉम। mycompany.myapp.util: सहायक कई स्थानों
इस एक स्टैंडअलोन जावा एप्लिकेशन पता चलता है में प्रयोग किया जाता कक्षाएं, यह अलग हो सकता है अगर यह कई ढाँचे में से एक का उपयोग कर एक webapp है।
ये पैकेज आपकी परियोजना में निर्देशिका पदानुक्रम से मेल खाते हैं। ग्रहण का उपयोग करते समय, इस तरह के पदानुक्रम की जड़ को 'स्रोत निर्देशिका' कहा जाता है। एक परियोजना एकाधिक स्रोत निर्देशिकाओं को परिभाषित कर सकती है, आमतौर पर 'मुख्य' और 'परीक्षण' स्रोत निर्देशिका।
अपनी परियोजना में फ़ाइलों का उदाहरण:
src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar
और utilities_1_0.jar अंदर:
com/acme/foo/BarUtils.class
BarUtils.class यह इतना मंच स्वतंत्र बाईटकोड रूप में है कि हो सकता है, एक संकलित जावा वर्ग है किसी भी JVM पर चलाएं। आम तौर पर जर्फ़ाइल में केवल संकलित कक्षाएं होती हैं, हालांकि आप कभी-कभी जार का एक संस्करण डाउनलोड कर सकते हैं जिसमें स्रोत (.java) फ़ाइलें भी शामिल हैं। यह उपयोगी है यदि आप एक जार फ़ाइल के मूल स्रोत कोड को पढ़ने में सक्षम होना चाहते हैं जिसका आप उपयोग कर रहे हैं।
उपरोक्त उदाहरण में बार, बारटेस्ट और बारयूटिल सभी एक ही पैकेज com.acme.foo में हैं, लेकिन शारीरिक रूप से आपके हार्डडिस्क पर विभिन्न स्थानों पर रहते हैं।
कक्षाएं जो सीधे स्रोत निर्देशिका में रहती हैं, 'डिफ़ॉल्ट पैकेज' में होती हैं, आमतौर पर कक्षाओं को रखने के लिए एक अच्छा विचार नहीं है क्योंकि यह स्पष्ट नहीं है कि कौन सी कंपनी और एप्लिकेशन वर्ग संबंधित है और आप नाम विवाद प्राप्त कर सकते हैं यदि आपके क्लासपाथ में आपके द्वारा जोड़े गए किसी भी जार फ़ाइल में डिफ़ॉल्ट पैकेज में एक ही नाम वाला एक वर्ग होता है।
अब यदि आप इस एप्लिकेशन को तैनात करते हैं, तो इसे सामान्य रूप से .class फ़ाइलों में संकलित किया जाएगा और एक .jar में बंडल किया जाएगा (जो मूल रूप से .zip फ़ाइल के साथ एक फैंसी नाम और कुछ मेनिफेस्ट जानकारी है)। एप्लिकेशन को चलाने के लिए .jar बनाना आवश्यक नहीं है, लेकिन आपके आवेदन को तैनात/वितरित करते समय आसान है। मैनिफेस्ट जानकारी का उपयोग करके आप एक .jar फ़ाइल 'निष्पादन योग्य' बना सकते हैं, ताकि उपयोगकर्ता आसानी से इसे चला सके, [ए] देखें।
आमतौर पर आप कई पुस्तकालयों का भी उपयोग करेंगे, यानी इंटरनेट से प्राप्त मौजूदा .jar फाइलें। डेटाबेस आदि तक पहुंचने के लिए लॉग 4j (लॉगिंग फ्रेमवर्क) या जेडीबीसी पुस्तकालयों के बहुत ही सामान्य उदाहरण हैं। इसके अलावा आपके पास अपने स्वयं के उप-मॉड्यूल हो सकते हैं जो अलग जारफाइल (जैसे 'utilities_1_0.jar' ऊपर) में तैनात किए गए हैं। जारफाइल पर चीजें कैसे विभाजित होती हैं एक तैनाती/वितरण पदार्थ है, फिर भी वे सभी जावा स्रोत कोड के लिए सार्वभौमिक नेमस्पेस साझा करते हैं। तो असल में, आप सभी जारफाइल को अनजिप कर सकते हैं और सामग्री को एक बड़ी निर्देशिका संरचना में डाल सकते हैं यदि आप चाहते थे (लेकिन आप आमतौर पर नहीं करते)।
जावा अनुप्रयोग चलाते समय जो एकाधिक पुस्तकालयों का उपयोग/होता है, आप आमतौर पर 'क्लासपाथ नरक' के रूप में जाना जाता है। जावा के सबसे बड़े दोषों में से एक जैसा कि हम जानते हैं। (नोट: मदद माना जाता है on the way)। कमांड लाइन पर जावा एप्लिकेशन चलाने के लिए (यानी ग्रहण से नहीं) आपको क्लासपाथ पर प्रत्येक एकल .jar फ़ाइल स्थान निर्दिष्ट करना होगा। जब आप जावा के कई ढांचे (मेवेन, स्प्रिंग, ओएसजीआई, ग्रैडल) में से एक का उपयोग कर रहे हैं तो आमतौर पर इस दर्द को कम करने के लिए समर्थन का कुछ रूप होता है।यदि आप एक वेब एप्लिकेशन बना रहे हैं तो आपको आम तौर पर अपनी पसंद के वेब कंटेनर (टोमकैट, जेट्टी, ग्लासफ़िश) में चीज़ को आसानी से तैनात करने में सक्षम होने के लिए अपने लेयरिंग/परिनियोजन सम्मेलनों का पालन करना होगा।
मुझे आशा है कि यह कुछ सामान्य अंतर्दृष्टि देता है कि चीजें जावा में कैसे काम करती हैं!
[ए] MyApp एप्लिकेशन के निष्पादन योग्य जार बनाने के लिए आपको अपने पथ पर एक जेडीके की आवश्यकता है। तब (बिन या लक्ष्य) निर्देशिका अपने संकलन में निम्न आदेश पंक्ति का उपयोग करें:
java -jar myapp.jar
या डबल-क्लिक जार फ़ाइल द्वारा:
jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp
फिर आप के साथ कमांड लाइन से निष्पादित कर सकते हैं। ध्यान दें कि आपको उस मामले में जावा कंसोल नहीं दिखाई देगा, इसलिए यह केवल उन अनुप्रयोगों के लिए उपयोगी है जिनके पास अपना स्वयं का जीयूआई (एक स्विंग ऐप की तरह) है या जो पृष्ठभूमि में चल सकता है (सॉकेट सर्वर की तरह)।
इसलिए, जो भी आप कहते हैं, वह सब समझ में आता है, लेकिन जब मैं एक्लिप्स को फ़ोल्डर के पदानुक्रम के साथ कॉन्फ़िगर करता हूं इस तरह: com \ mydomain \ myapp \ util फिर घोषणा के साथ एक स्रोत फ़ाइल जोड़ें: पैकेज com.mydomain.myapp.util; तब ग्रहण उपयोग फ़ोल्डर के तहत नए फ़ोल्डरों का एक पूरा भैंस बनाता है: com \ mydomain \ myapp \ util \ com \ mydomain \ myapp \ util \ src \ myclass.java –
आप ग्रहण स्रोत फ़ोल्डर के साथ अपने पैकेज पदानुक्रम को भ्रमित कर रहे हैं। ग्रहण स्रोत फ़ोल्डर कुछ 'src/main/java /' जैसा होना चाहिए (यदि आप मेवेन सम्मेलनों का पालन करते हैं)। यह आपके पैकेज पदानुक्रम के लिए बस शुरुआती बिंदु है; फ़ोल्डर 'src/main/java' डिफ़ॉल्ट पैकेज को इंगित करेगा। इस फ़ोल्डर के तहत ग्रहण पैकेज से मेल खाने के लिए फ़ोल्डर उत्पन्न करेगा, इसलिए आपकी उदाहरण कक्षा /src/main/java/com/mydomain/myapp/util/myclass.java –
में समाप्त हो जाएगी क्या इस फ़ोल्डर संरचना के साथ गिटहब पर एक जावा प्रोजेक्ट है एक वास्तविक दुनिया का उदाहरण? –