जावा के प्रॉक्सी फ़्लैग मुख्य क्लास से पहले रखें
प्रॉक्सी सिस्टम प्रॉपर्टी को जावा लॉन्चर को दें, बजाय उन्हें गलती से ऐप्लिकेशन आर्ग्युमेंट के रूप में पहुँचाने के।
ये दोनों कमांड जावा लॉन्चर को एक ही कॉन्फ़िगरेशन नहीं देते। अपने HTTP प्रॉक्सी का होस्ट और पोर्ट इस्तेमाल करें; HTTP प्रॉक्सी सूची अनुमत सार्वजनिक रूट के लिए उम्मीदवार देती है:
java -Dhttp.proxyHost=proxy.example.net -Dhttp.proxyPort=8080 -jar app.jar
java -jar app.jar -Dhttp.proxyHost=proxy.example.net -Dhttp.proxyPort=8080
पहले में लॉन्चर को सिस्टम-प्रॉपर्टी विकल्प मिलते हैं। दूसरे में app.jar के बाद के टोकन ऐप्लिकेशन आर्ग्युमेंट बन जाते हैं। जब तक ऐप्लिकेशन जानबूझकर उन्हें पार्स न करे, वे JVM के प्रॉक्सी प्रॉपर्टी सेट नहीं करते।
-jar की जगह मुख्य क्लास का नाम देने पर भी यही सीमा लागू होती है। JVM विकल्प क्लास के नाम से पहले और ऐप्लिकेशन-विशिष्ट आर्ग्युमेंट उसके बाद रखें।
IDE, सर्विस रैपर या लॉन्च स्क्रिप्ट द्वारा बनाए गए असली स्टार्टअप कमांड की जाँच करें। इसका “program arguments” लेबल वाला फ़ील्ड VM विकल्पों के फ़ील्ड से अलग हो सकता है।
सही जगह केवल प्रॉपर्टी देती है। HTTP क्लाइंट को अभी भी वह जावा नेटवर्किंग कॉन्फ़िगरेशन इस्तेमाल करना होता है। Apache HttpClient 5 के लिए, क्लाइंट को सिस्टम प्रॉपर्टी इस्तेमाल करने दें। प्रॉक्सी प्रमाणीकरण के लिए अपना समर्थित इंटरफ़ेस चाहिए।