जावा: सिस्टम पैरामीटर बनाम "नियमित" कमांड लाइन विकल्प

Question

हम जावा अनुप्रयोग को मानते हैं, एक पूर्णांक कमांड लाइन तर्क स्वीकार करते हैं, bubu कहें।

1. --bubu 5: -

   एक मान लिया जाये कि एक सभ्य कमांड लाइन पार्सर का उपयोग करता है (और मुझे क्या करना http://pholser.github.com/jopt-simple/) प्लस मन में डी जावा स्विच रखते हुए, इन विशिष्ट तरीके से कुछ इस कमांड लाइन पैरामीटर पारित करने के लिए कर रहे हैं (या --bubu=5 या --bubu5)

2. -Dbubu=5

कहाँ पहले एक कार्यक्रम तर्क है और कुछ कमांड लाइन पार्सर का उपयोग कर आवेदन के द्वारा नियंत्रित किया जाना चाहिए, क दूसरा दूसरा वीएम तर्क है और इसे जावा द्वारा पहले ही पार्स किया गया है, इसे Integer.getInteger("bubu")

मैं थोड़ी परेशान हूं। मुझे क्या उपयोग करना चाहिए? प्रणाली संपत्ति सुविधा का उपयोग करना:

• कुछ भी नहीं
• किसी भी कमांड लाइन पार्सर पुस्तकालय पर निर्भर नहीं करता
• सुविधाजनक प्रदान करता है (हालांकि अप्रत्याशित) एपीआई मूल्यों

जहां तक ​​प्राप्त करने के लिए खर्च करने लगता है जैसा कि मैं देख सकता हूं, केवल विपक्ष यह है कि सभी कमांड लाइन विकल्पों को -D ध्वज का उपयोग करना होगा।

कृपया, सलाह।

धन्यवाद।

संपादित

एक अन्य प्रणाली मापदंडों के लिए पेशेवरों - "वे प्रयोग करने योग्य हो तब भी जब आवेदन एक स्टैंड-अलोन अनुप्रयोग एक मुख्य से शुरू नहीं है, लेकिन यह भी है कि एप्लिकेशन को एक webapp या एक इकाई है परीक्षा।" - धन्यवाद https://stackoverflow.com/users/571407/jb-nizet

EDIT2

मुझे यहाँ और अधिक ध्यान केंद्रित होने दो। क्या सिस्टम पैरामीटर का उपयोग न करने के लिए हमेशा कोई गंभीर कारण है (एस्थेटिक्स के अलावा)?

EDIT3

ठीक है, मैं मैं इसे अब मिल लगता है। यदि मेरा कोड किसी वेब एप्लिकेशन द्वारा लोड होने की संभावना है, तो संभावित नाम टकराव का एक मुद्दा है, क्योंकि उसी वेब कंटेनर द्वारा होस्ट किए गए अन्य वेब एप्लिकेशन मेरे कोड के साथ सिस्टम प्रॉपर्टी स्पेस साझा करते हैं।

इसलिए, मुझे पहले से ही अपने सिस्टम गुणों को समझदार और असंबद्ध होना होगा। तो, अब bubu नहीं है, यह अब com.shunra.myapp.bubu है। अर्थ के बजाय एक सरल

-Dbubu=5 

मैं

-Dcom.shunra.myapp.bubu=5 

जो एक सरल कमांड लाइन आवेदन के लिए कम आकर्षक हो जाता है है।

एक अन्य कारण Mark Peters द्वारा दिया गया है, जो मेरे लिए बहुत अच्छा है।

Answer 1

मैं तर्क दूंगा कि लाभ Fortyrunner उद्धरण वास्तव में सिस्टम गुणों के लिए सबसे महत्वपूर्ण नकारात्मक है - वे उन लोगों के लिए उपलब्ध हैं जो उनके लिए पूछते हैं।

यदि ध्वज या विकल्प कमांड लाइन विकल्प के रूप में जाना जाता है, तो यह आपके कोड की परत या मॉड्यूल पर उपलब्ध होना चाहिए जो कमांड लाइन से इनपुट लेने से संबंधित है, कोई भी कोड जो इसके लिए पूछता है।

आप वैश्विक स्थिति से कुछ विनाशकारी युग्मन प्राप्त कर सकते हैं, और सिस्टम गुण किसी अन्य वैश्विक स्थिति से अलग नहीं हैं।

यह कहा गया है कि, यदि आप केवल एक त्वरित और गंदे सीएलआई प्रोग्राम बनाने की कोशिश कर रहे हैं, और चिंताओं और युग्मन को अलग करना आपके लिए बड़ी चिंता नहीं है, तो सिस्टम गुण आपको एक आसान तरीका देते हैं जो हालांकि (आईएमओ) खराब उपयोगकर्ता अनुभव। कुछ गेटोपेट लाइब्रेरी आपको एक अच्छा सीएलआई उपयोगकर्ता अनुभव बनाने के लिए बहुत अधिक समर्थन प्रदान करेगी।

Answer 2

प्रणाली गुण का मुख्य लाभ यह है कि वे आप इस कार्यक्रम के जीवन के दौरान किसी भी समय उपलब्ध हैं।

कमांड लाइन तर्क मुख्य विधि में ही उपलब्ध हैं (जब तक आप उन्हें जारी रहती है)।

Answer 3

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

संक्षेप में, जब एक सिस्टम में अधिकाधिक महत्वपूर्ण हो जाता है, यह अधिक से अधिक गुण हो सकता है। सिस्टम प्रॉपर्टी प्रीसेट के साथ, उपयोगकर्ताओं को केवल यह जानने की आवश्यकता हो सकती है कि उन्हें वास्तव में क्या चाहिए जब वे वास्तव में हैं। उदाहरण के लिए, मुझे केवल स्मृति को बढ़ाने की आवश्यकता होने पर ग्लासफ़िश के -XX:PermSize के बारे में जानने की आवश्यकता है।