My colleague Arno did some work on this for Java 9/10 (see https://bugs.openjdk.java.net/browse/JDK-8170868)
Added him on CC as well as I'm not sure he's following net-dev. Daniel Fuchs <daniel.fu...@oracle.com> schrieb am Mi., 25. Sep. 2019, 12:56: > Hi, > > On 25/09/2019 08:20, Alan Bateman wrote: > > On 24/09/2019 23:47, mark.reinh...@oracle.com wrote: > >> Using network proxies with Java applications is still, after all these > >> years, painful on Linux. > >> > >> Is there a reason not to change the default value of the system property > >> `java.net.useSystemProxies` [1] to `true`? > > This is a problematic area, I think Daniel Fuchs looked into it recently > > to see what should be changed. > > When we where in the process of standardizing the HTTP client I did some > investigation to see if we could make the HTTP client more user friendly > for Docker applications. Namely I wanted whatever was defined in the > http_proxy env variables to be used by default, if no system property > was defined to override them. That's when I discovered that the > launcher on mac was explicitly setting system properties as a means > to enable the default system proxy - so there was no way to distinguish > whether those had been set by the user or not, and whether the env > variables should take precedence or not. I stopped my investigation > there. > > > One thing on Linux is that is that useSystemProxies will look for gconf > > or GNOME configuration. That seems legacy now and the JDK should > > probably be looking at the http_proxy and https_proxy env variables to > > be consistent with other tools. > > It's close to the issue I ran into. > > I think the main issue with using system proxy configuration by default > > is testing the JDK. The macOS port is the one case where system proxies > > are used by default and it has been problematic to test when the proxy > > configuration on tests systems isn't setup correctly (the equivalent of > > noProxy in particular). > > I have updated many of the networking tests to explicitly specify > openConnection(Proxy.NO_PROXY) in my effort with test stabilization, > though I suspect many still remains that don't do that - in particular > with tests in other area than networking that may use > URL.openConnection (JCK tests might need some updates too). > But on this front - we probably are in a better place now than > we used to be. > > One other thing is that as far as I can tell the default system > proxy configuration used by the JDK (at least on my machine) > does not seem to recognize '::1' as an address that shouldn't > go through the proxy - so currently any http test that uses > the IPv6 loopback and runs on some machine where a proxy is > configured could end up failing with error 500 Bad Gateway > (which in part prompted my effort into updating tests to use > explicitly NO_PROXY). > This is something we should fix in the default proxy selector. > Though I'm not sure there's a unified syntax to do that. > > > Another part to this is to enumerates the APIs and features that that > > could or should use the proxy configuration. The legacy URL protocol > > handlers for sure but there are other areas that might need attention. > > Yes. > > > > > -Alan > > best regards, > > -- daniel >
