Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification [v2]

2021-02-03 Thread Julia Boes
On Wed, 3 Feb 2021 14:19:27 GMT, Alan Bateman wrote: >> Julia Boes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> small adjustment > > src/java.base/share/classes/java/net/InetSocketAddress.java line 387: > >> 385: * To retrieve a

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification [v2]

2021-02-03 Thread Alan Bateman
On Wed, 3 Feb 2021 14:17:58 GMT, Julia Boes wrote: >> This change clarifies the InetSocketAddress::toString specification, which >> was recently updated to reflect an implementation change [1]. The >> specification is not changed, but it is enhanced with two examples and some >> more verbiage,

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification [v2]

2021-02-03 Thread Julia Boes
> This change clarifies the InetSocketAddress::toString specification, which > was recently updated to reflect an implementation change [1]. The > specification is not changed, but it is enhanced with two examples and some > more verbiage, as per earlier suggestions on the net-dev mailing list [

Integrated: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-03 Thread Julia Boes
l This pull request has now been integrated. Changeset: b0ee7a86 Author:Julia Boes URL: https://git.openjdk.java.net/jdk/commit/b0ee7a86 Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod 8241995: Clarify InetSocketAddress::toString specification Reviewed-by: michaelm, chegar

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-03 Thread Michael McMahon
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote: > This change clarifies the InetSocketAddress::toString specification, which > was recently updated to reflect an implementation change [1]. The > specification is not changed, but it is enhanced with two examples and some > more verbiage, as

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-03 Thread Chris Hegarty
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote: > This change clarifies the InetSocketAddress::toString specification, which > was recently updated to reflect an implementation change [1]. The > specification is not changed, but it is enhanced with two examples and some > more verbiage, as

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-03 Thread Jaikiran Pai
On Wed, 3 Feb 2021 11:36:28 GMT, Julia Boes wrote: >> Maybe could say "rather than parsing the output of toString()" instead of >> "rather than parsing the string representation". Might be clearer? > > Ok, how about this: "rather than parsing the string returned by this > toString() method"? T

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-03 Thread Julia Boes
On Tue, 2 Feb 2021 16:14:10 GMT, Michael McMahon wrote: >> This change clarifies the InetSocketAddress::toString specification, which >> was recently updated to reflect an implementation change [1]. The >> specification is not changed, but it is enhanced with two examples and some >> more verb

Re: RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-02 Thread Michael McMahon
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote: > This change clarifies the InetSocketAddress::toString specification, which > was recently updated to reflect an implementation change [1]. The > specification is not changed, but it is enhanced with two examples and some > more verbiage, as

Re: 8241995: Clarify InetSocketAddress::toString specification

2021-02-02 Thread Julia Boes
: Chris Hegarty , OpenJDK Network Dev list Subject: Re: 8241995: Clarify InetSocketAddress::toString specification Hello Chris, I missed this thread previously. This suggested change to the javadoc looks good to me and the example now makes it clear on what to expect. As for the last paragraph of

RFR: JDK-8241995: Clarify InetSocketAddress::toString specification

2021-02-02 Thread Julia Boes
This change clarifies the InetSocketAddress::toString specification, which was recently updated to reflect an implementation change [1]. The specification is not changed, but it is enhanced with two examples and some more verbiage, as per earlier suggestions on the net-dev mailing list [2][3].

Re: 8241995: Clarify InetSocketAddress::toString specification

2021-02-02 Thread Jaikiran Pai
Hello Chris, I missed this thread previously. This suggested change to the javadoc looks good to me and the example now makes it clear on what to expect. As for the last paragraph of the javadoc, I'm just adding to the suggestions already made by others in this thread. Perhaps the following

Re: 8241995: Clarify InetSocketAddress::toString specification

2020-04-14 Thread Daniel Fuchs
On 14/04/2020 15:00, Michael McMahon wrote: Hi Chris,     possible wording for your last paragraph: To retrieve a string representation of the hostname, or in the absence of a hostname, the string form of the address, use {@link #getHostString()}, rather than parsing the toString string represen

Re: 8241995: Clarify InetSocketAddress::toString specification

2020-04-14 Thread Michael McMahon
OpenJDK Network Dev list *Subject:* 8241995: Clarify InetSocketAddress::toString specification As noted in a recent thread [1], the wording of InetSocketAddress::toString could be improved a little, to avoid any potential confusion about how and when "" is displayed. It was also suggeste

Re: 8241995: Clarify InetSocketAddress::toString specification

2020-04-03 Thread mark sheppard
2020 17:26 To: OpenJDK Network Dev list Subject: 8241995: Clarify InetSocketAddress::toString specification As noted in a recent thread [1], the wording of InetSocketAddress::toString could be improved a little, to avoid any potential confusion about how and when "" is displayed. I

8241995: Clarify InetSocketAddress::toString specification

2020-04-03 Thread Chris Hegarty
As noted in a recent thread [1], the wording of InetSocketAddress::toString could be improved a little, to avoid any potential confusion about how and when "" is displayed. It was also suggested that a link to getHostString could be added. Below is an initial suggestion. It does not change the spe