Chris, Fine with me. I concur about the verbiage in the description.
Alan, Thanks for the background and pointer to other clarifications. Brian On Mar 19, 2015, at 8:23 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > I would personally close this as 'not a bug'. > > I see no value in trying add additional clarification around something that > has never, to the best of my knowledge, been the source of confusion. The > description in JIRA seems overly pedantic. > > -Chris. > > On 19/03/15 14:47, Alan Bateman wrote: >> On 19/03/2015 14:30, Brian Burkhalter wrote: >>> Please review at your convenience. This a doc-only change. >>> >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8074937 >>> Patch:http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ >>> <http://cr.openjdk.java.net/%7Ebpb/8074937/webrev.00/> >>> >>> This is in effect an amplification of extant javadoc suggested as an >>> enhancement by an external user. I performed some testing to verify >>> the accuracy of the suggested documentation change prior to crafting >>> the verbiage, and the criticism does seem to be well-founded in the >>> behavior of the APIs in question. >>> >>> It would be good however if someone with a more profound knowledge of >>> this area were to review the proposed documentation update for >>> accuracy, especially as it is not unlikely that there might be >>> platform-specific behavior with which these statements conflict. >> listen is documented on many platforms to be the maximum length of the >> queue of pending connections so not clear to me that you really want to >> change that. >> >> In ServerSocketChannel.bind then it is documented as: >> >> * <p> The {@code backlog} parameter is the maximum number of pending >> * connections on the socket. Its exact semantics are >> implementation specific. >> * In particular, an implementation may impose a maximum length or >> may choose >> * to ignore the parameter altogether. >> >> -Alan.
