ეს ორი ბრძანება Java-ს გამშვებს ერთსა და იმავე კონფიგურაციას არ აძლევს. გამოიყენეთ თქვენი 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 კლიენტმა კვლავ უნდა გამოიყენოს ის Java ქსელური კონფიგურაცია. Apache HttpClient 5-ისთვის, ნება დართეთ კლიენტს გამოიყენოს სისტემური თვისებები. პროქსის ავთენტიფიკაციას საკუთარი მხარდაჭერილი ინტერფეისი სჭირდება.

დაკავშირებული სტატიები