RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

[Chris Hegarty]

Arno,

> On 16 Jan 2017, at 11:23, Zeller, Arno <arno.zeller at sap.com> wrote:
> 
> Hi Michael and Chris,
> 
> I see that in with "RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404" you fix a problem 
> on macOS that does occur, because macOS is the only platform that sets a default proxy from the system
> settings. On all other platforms the system settings are only used if -Djava.net.useSystemProxies is set to true.
> 
> Do you know if there is a reason behind this behaviour?

The system proxies are used, by default, on Mac OS X to maintain compatibility
from Apple's Java 6 to OpenJDK 7 with Mac support ( 7 is the first OpenJDK
version that supports Mac ). 

> I would suggest that all platforms behave similar?

Maybe early on in a future release we could attempt to do this.

> A 
> reason could be that Mac users are often desktop users that are happy to have the VM use their system 
> settings by default. But I guess this will apply for Windows  desktop Users too and even for Linux or Solaris 
> users.
> 
> My webrev keeps the old behavior on macOS but I can change it :-)

Please keep the current behaviour, as you are proposing.

> The current behavior in the webrev is:
> 
> Default - without any properties:
> - macOS: If a proxy was manually added in the system settings it is used to populate the http.proxyHost/Port,... 
>   properties (will not work with an auto config URL aka PAC file or WPAD settings).
> - all other platforms: no proxy.
> 
> java.net.useSystemProxies=true:
> - macOS and Windows - use System functionality to get a proxy lists for a given URL. This works now with PAC 
>   files or WPAD settings.
> - All UNIX versions excluding macOS: if Gnome 2.0 is configured to use a proxy we use the system functionality
>  (available since gio lib 2.26) or we read the settings from gconf and use them to populate the
>   http.proxyHost/Port,... properties - the later will again not work with PAC files or WPAD.
> 
> http.proxyHost/Port,... properties are set:
> - On all platforms these properties have highest priority and will disable the use of system settings. 
> 
> Of course by changing the default behavior we would behave incompatible to old releases. What do you think 
> shall be done? 

Not in 9, but maybe in a future release.

> Another thing to improve could be the usage of the environment variables on UNIX system. Currently  they are 
> ignored, but It is pretty easy to parse http_proxy, https_proxy, ftp_proxy and no_proxy environment variables
> to set the default proxy properties on UNIX. My experience is that these variables are used more often than 
> the gnome settings.

My personal preference is to move more towards the system’s proxies, rather
than yet another way of setting proxies.

-Chris.

> Best regards,
> Arno
> 
>> -----Original Message-----
>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
>> Zeller, Arno
>> Sent: Mittwoch, 11. Januar 2017 15:21
>> To: Chris Hegarty <chris.hegarty at oracle.com>
>> Cc: net-dev at openjdk.java.net
>> Subject: RE: RFR:8170868: DefaultProxySelector should use system defaults on
>> Windows, MacOS and Gnome
>> 
>> Hi Chris,
>> 
>> I have addressed your comments in a new webrev. Can you please have a
>> look at this one?
>> 
>> http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/
>> 
>> I created src/java.base/share/native/libnet/proxy_util.c/h and these files
>> contain now the common used native parts.
>> And I rewrote the code to return an array of Proxy objects from native code -
>> so I do no longer call back to Java to add an object to the list.
>> 
>> Best regards,
>> Arno
>> 
>>> -----Original Message-----
>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>>> Sent: Dienstag, 3. Januar 2017 15:04
>>> To: Zeller, Arno <arno.zeller at sap.com>
>>> Cc: net-dev at openjdk.java.net
>>> Subject: Re: RFR:8170868: DefaultProxySelector should use system
>>> defaults on Windows, MacOS and Gnome
>>> 
>>> Arno,
>>> 
>>>> On 27 Dec 2016, at 11:44, Zeller, Arno <arno.zeller at sap.com> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Thanks for having a look at my change:
>>>> 
>>>>> 1) It seems awful to have to deal with LinkedList in native code. How
>>>>>  about returning an array from native, and then converting that into
>>>>>  whatever list type is appropriate at the Java level.
>>>> With the current implementation on Mac I do not know upfront how many
>>> items the list will contain and therefore I preferred to use the
>>> LinkedList from native code.
>>>> I can of course change the implementation on Mac to first generate a
>>>> fully
>>> resolved native list and then I can use NewObjectArray to generate an
>>> Array of Proxy objects to return. This will avoid calling to java to
>>> add an element to the list. Do you think this will be better?
>>> 
>>> Yes. Thanks.
>>> 
>>>>> 2) I would prefer the use of List.of(...), and list.of() for empty, since
>>>>>  these are immutable and efficient list implementations.
>>>> I thought about that but I tried to not return an immutable List
>>>> because the
>>> Javadoc of Proxy.select does not state anything about the returned List
>>> (if it is immutable or not) and I feared to break compatibility by
>>> returning an immutable List.
>>>> If you think this is no problem I will of course prefer to always
>>>> return the
>>> same immutable NO_PROXY list object.
>>> 
>>> I would prefer an immutable list. Maybe we file, a separate, issue to
>>> amend the spec to say "returns an immutable list …”.
>>> 
>>>>> 3) Is the comment “Inspired ...” necessary / appropriate?
>>>> I will change it to the comment proposed by Volker.
>>> 
>>> Ok.
>>> 
>>>>> 4) Can some of the native initialization code be moved to a platform
>>>>>  independent location, to remove duplication?
>>>> Would it be ok if I move the definition of the static variables and
>>>> the
>>> implementation of 'static int initJavaClass(...)' to a header file in
>>> the shared branch. I.e.
>>> src/java.base/shared/native/libnet/DefaultProxySelector.h and include this
>> in the MacOSX, Windows and the Unix implementations?
>>> 
>>> Yes.
>>> 
>>>>> 5) The new file has a shared copyright header. I see similar SAP
>>>>>  headers in a few files, but none shared with the Oracle header.
>>>>>  How did you arrive at this format?
>>>> The format was suggested to me by Volker :-)
>>> 
>>> Ok.
>>> 
>>> -Chris.