2010-08-24 8 views
5

क्या मेरे classpath में जावा 6 वाइल्डकार्ड का उपयोग करने में कोई नुकसान है? जैसेमैं अपने क्लासपाथ में वाइल्डकार्ड का उपयोग क्यों नहीं करूंगा?

C:> set CLASSPATH=.\lib\* 

मुझे लगता है कि जहां दो जार कि दोनों एक ही पथ के साथ एक वर्ग को शामिल कर रहे हैं तो एक वाइल्ड कार्ड का उपयोग परिणाम है कि नीचे ट्रैक करने के लिए कड़ी मेहनत कर रहे हैं को जन्म दे सकती देख सकते हैं।

लेकिन इसके अलावा, क्या इसके बारे में जागरूक होने के लिए कुछ और है?

+0

fwiw, मेरे lib फ़ोल्डर को पैकेजिंग चरण के हिस्से के रूप में appassembler प्लगइन का उपयोग करके मेरी निर्भरता से मेरे निर्भरता से निर्मित किया जाता है। क्लासपाथ को परिभाषित करने के लिए मेरा पीओएम अंतिम दस्तावेज है। –

उत्तर

2

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

मैं आमतौर पर उपयोग की जाने वाली जार फ़ाइलों की संख्या को कम करने की कोशिश करता हूं, और उन्हें मैन्युअल रूप से लिंक करता हूं। मुझे एहसास है कि यह व्यक्तिगत वरीयता है।

0

आप संभावित रूप से JVM को खोजने के लिए बहुत सारे स्थान दे रहे हैं, इससे कुछ ओवरहेड हो सकते हैं क्योंकि कक्षाएं लोड की जाती हैं - मुझे लगता है कि एक चालाक JVM यह कुशलतापूर्वक करेगा।

1

आप ऐसा करके अवांछित कक्षाएं लोड कर सकते हैं, और यदि एक ही पुस्तकालय के दो संस्करण हैं; अच्छा, कबाब।

1

एक स्पष्ट क्लासपाथ क्या पुस्तकालयों (और शायद इसके संस्करण क्या है!) के दस्तावेज़ीकरण के रूप में सर्वर पर निर्भर करता है।

यदि आप वाइल्डकार्ड का उपयोग करते हैं तो आप इसे खो देते हैं - अगर इसे कहीं और दस्तावेज नहीं किया गया है, तो अगर किसी को lib फ़ोल्डर (या आप इसे गलती से हटा दें) के बिना ऐप की प्रति प्राप्त करते हैं, तो उन्हें सभी को ट्रैक करने में बहुत कठिन समय होगा ClassNotFoundError एस को देखकर, बार-बार ऐप चलाने के माध्यम से निर्भरता और उम्मीद है कि सभी पुस्तकालयों ने समझदार पैकेज नामों का उपयोग किया है।

0

मेरी पहली पलटा था env.CLASSPATH, लेकिन दूसरी सोचा पर उपयोग नहीं करते हैं और जब तक के बारे में सोच भी इसे नहीं करना चाहिए क्यों मैं विचार likeing, कम से कम एक स्थानीय विकास और परीक्षण पर्यावरण के लिए शुरू कर दिया (और कम से कम कुछ समय के लिए)

लाभ इस दृष्टिकोण का है कि आप अपने सभी आम पुस्तकालयों (log4j, dom4j, Joda समय, गूगल संग्रह, Apache Commons चिड़ियाघर, के साथ एक स्थानीय फ़ोल्डर रख सकते .. ।)। तो आप लंबे समय तक टाइपिंग लंबी कक्षा के तर्कों को बर्बाद किए बिना अपने सभी एप्लिकेशन को खोल से संकलित और निष्पादित कर सकते हैं।

और अभी भी -cp तर्क का उपयोग करने के लिए स्वतंत्र है, क्योंकि यह वैश्विक CLASSPATH सेटिंग को प्रतिस्थापित करता है।

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

तो उत्पादन के लिए, कोई वैश्विक 'क्लासस्पैट' नहीं है और क्लासपाथ स्ट्रिंग में कोई वाइल्डकार्ड नहीं है।

हानिकारक ऊपर जैसा वातावरण में वाइल्डकार्ड पथ का उपयोग करने के लिए: थोड़ी देर के बाद भी कई परियोजनाएं एकल लाइब्रेरी फ़ोल्डर पर निर्भर करती हैं। आप पुस्तकालय को अद्यतन करने या पुराने को हटाने का दुष्प्रभाव नहीं जानते हैं। और बड़े आवेदन के लिए यह पता लगाना मुश्किल हो सकता है कि पूल से कौन से पुस्तकालयों की वास्तव में आवश्यकता है।आप उत्पाद में अप्रयुक्त libs को जोड़ना समाप्त कर सकते हैं क्योंकि आप अनिश्चित हैं कि एप्लिकेशन उस lib के बिना चलाएगा।

तो मेरा निष्कर्ष - विकास, परीक्षण, प्रोटोटाइप के लिए एक अच्छा शॉर्टकट लेकिन उत्पादन के लिए जोखिम भरा। उत्पादन के लिए मैं वाइल्डकार्ड के बिना क्लासपाथ स्ट्रिंग्स (ऑटोगनेरेटेड) पसंद करूंगा।

+0

मैं $ CLASSPATH बनाम -cp के बारे में नहीं पूछ रहा था। मैं कभी भी उत्पादन वातावरण में $ CLASSPATH का उपयोग नहीं करूँगा। मैं सिर्फ सवाल को स्पष्ट करने की कोशिश कर रहा था जैसा मैं कर सकता था। –

+0

मुझे पता है कि सवाल केवल वाइल्डकार्ड के बारे में था, जवाब * विस्तारित * है;) –

संबंधित मुद्दे