From julia.boes at oracle.com  Wed Apr  1 10:19:15 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Wed, 1 Apr 2020 11:19:15 +0100
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
 <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>
Message-ID: <79a70622-1969-e014-b775-24a14523d8ba@oracle.com>

Hi Jaikiran,

>>> By the way, keeping aside the breaking nature of this change, the 
>>> current javadoc, I think doesn't reflect what the current 
>>> implementation returns for unresolved addresses. The javadoc states:
>>>
>>> "If the address is unresolved, |<unresolved>| is displayed in place 
>>> of the address literal."
>>>
>>> Note, the "in place of the address literal" part. However, in the 
>>> current implementation[6], it returns something like - 
>>> "localhost/<unresolved>:2182". So it doesn't just display the 
>>> "<unresolved>" literal in the address part but suffixes it to the 
>>> address part. Should that be clarified?
>>>
>> The InetSocketAddress string representation defers, partly, to 
>> InetAddress::toString, which specifies the ?hostname / literal IP 
>> address? form. It is this address literal that is replaced with 
>> ?<unresolved>?. If this is not clear from this spec, then it can be 
>> clarified.
>>
> Now that you explained it to me, I see what you mean and what that 
> javadoc means. I hadn't paid attention to the "This String is 
> constructed by calling toString() on the InetAddress and concatenating 
> the port number (with a colon)". Looking at the javadoc on 
> InetAddress.toString(), it does state the returned string to be of the 
> form "hostname/literal IP address" (example: 
> google.com/172.217.160.142). So when it says that "<unresolved> is 
> displayed in place of the address literal", it actually is talking 
> about the part that follows the "/" character in the output returned 
> by the InetAddress.toString().
>
> I'll be honest - I didn't even know that up until this release, the 
> output of this API was something like google.com/172.217.160.142:80. I 
> had it in my mind that the output was google.com:80. That's why when 
> the new javadoc said "in place of the address literal", I thought it 
> was talking about replacing "google.com" with "<unresolved>"
>
> I don't know if it's just me who couldn't fully understand it until 
> this was explained. For me, a {@link InetSocket.toString()} in the 
> javadoc and a couple of example representations of what the output of 
> toString() would look like would have made it easier. But I do 
> understand that the javadoc may not be the right place for such level 
> of details.
>
Based on the feedback, we updated the related release note to better 
explain "literal IP address" and to include a pointer to 
InetSocketAddress::getHostString.

https://www.oracle.com/technetwork/java/javase/14all-relnotes-5809668.html#JDK-8225499

Cheers,

Julia


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/4550e8fb/attachment-0001.htm>

From chris.hegarty at oracle.com  Wed Apr  1 11:03:06 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Apr 2020 12:03:06 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
Message-ID: <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>


> On 31 Mar 2020, at 18:46, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 31/03/2020 18:27, Chris Hegarty wrote:
>> :
>> - In DatagramSocket::createDelegate, "enable broadcast if possible? - Possibly due to refactoring, but I cannot reconcile this with the old implementation.
> DatagramSocket is specified to make a best attempt to enable this option so I think it's in the right place. At a clean-up, the attempt in PDSI.datagramSocketCreate could be removed.

Ok, that explains why it was difficult to reconcile in the webrev.

I now see that ?best-effort? is not implemented on unix platforms, but rather fail-fast ( an exception is thrown if the option cannot be set ). Let?s just remove this now superfluous native code as it is confusing.

>> :
>> 
>> - The set of socket options is now per datagram/multicast socket instance, rather than on the class of the socket. I don?t think that this is an issue, just an observation and a confirmation that it is deliberate.
> The set of socket options supported by a custom DSI will likely be different to the default impl so it needs to be an instance field. I suspect this is a long standing bug.


Since this issue is orthogonal to the JEP, I filed the following issue to track it:
  https://bugs.openjdk.java.net/browse/JDK-8241988 <https://bugs.openjdk.java.net/browse/JDK-8241988>

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/4d5759a2/attachment.htm>

From jai.forums2013 at gmail.com  Wed Apr  1 12:48:05 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 1 Apr 2020 18:18:05 +0530
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <79a70622-1969-e014-b775-24a14523d8ba@oracle.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
 <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>
 <79a70622-1969-e014-b775-24a14523d8ba@oracle.com>
Message-ID: <333b7e44-f2b7-1cd5-f707-4897f2b6e487@gmail.com>


On 01/04/20 3:49 pm, Julia Boes wrote:
>
> Hi Jaikiran,
>
>>>> By the way, keeping aside the breaking nature of this change, the
>>>> current javadoc, I think doesn't reflect what the current
>>>> implementation returns for unresolved addresses. The javadoc states:
>>>>
>>>> "If the address is unresolved, |<unresolved>| is displayed in place
>>>> of the address literal."
>>>>
>>>> Note, the "in place of the address literal" part. However, in the
>>>> current implementation[6], it returns something like -
>>>> "localhost/<unresolved>:2182". So it doesn't just display the
>>>> "<unresolved>" literal in the address part but suffixes it to the
>>>> address part. Should that be clarified?
>>>>
>>> The InetSocketAddress string representation defers, partly, to
>>> InetAddress::toString, which specifies the ?hostname / literal IP
>>> address? form. It is this address literal that is replaced with
>>> ?<unresolved>?. If this is not clear from this spec, then it can be
>>> clarified.
>>>
>> Now that you explained it to me, I see what you mean and what that
>> javadoc means. I hadn't paid attention to the "This String is
>> constructed by calling toString() on the InetAddress and
>> concatenating the port number (with a colon)". Looking at the javadoc
>> on InetAddress.toString(), it does state the returned string to be of
>> the form "hostname/literal IP address" (example:
>> google.com/172.217.160.142). So when it says that "<unresolved> is
>> displayed in place of the address literal", it actually is talking
>> about the part that follows the "/" character in the output returned
>> by the InetAddress.toString().
>>
>> I'll be honest - I didn't even know that up until this release, the
>> output of this API was something like google.com/172.217.160.142:80.
>> I had it in my mind that the output was google.com:80. That's why
>> when the new javadoc said "in place of the address literal", I
>> thought it was talking about replacing "google.com" with "<unresolved>"
>>
>> I don't know if it's just me who couldn't fully understand it until
>> this was explained. For me, a {@link InetSocket.toString()} in the
>> javadoc and a couple of example representations of what the output of
>> toString() would look like would have made it easier. But I do
>> understand that the javadoc may not be the right place for such level
>> of details.
>>
> Based on the feedback, we updated the related release note to better
> explain "literal IP address" and to include a pointer to
> InetSocketAddress::getHostString.
>
> https://www.oracle.com/technetwork/java/javase/14all-relnotes-5809668.html#JDK-8225499
>
Thank you Julia - that's descriptive enough, IMO.

-Jaikiran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/ed4d208c/attachment.htm>

From chris.hegarty at oracle.com  Wed Apr  1 13:10:26 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Apr 2020 14:10:26 +0100
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <333b7e44-f2b7-1cd5-f707-4897f2b6e487@gmail.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
 <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>
 <79a70622-1969-e014-b775-24a14523d8ba@oracle.com>
 <333b7e44-f2b7-1cd5-f707-4897f2b6e487@gmail.com>
Message-ID: <32D490C7-EFAD-4232-A80C-7F8A27821FA3@oracle.com>



> On 1 Apr 2020, at 13:48, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>>>> ...
>>> Now that you explained it to me, I see what you mean and what that javadoc means. I hadn't paid attention to the "This String is constructed by calling toString() on the InetAddress and concatenating the port number (with a colon)". Looking at the javadoc on InetAddress.toString(), it does state the returned string to be of the form "hostname/literal IP           address" (example: google.com/172.217.160.142). So when it says that "<unresolved> is displayed in place of the address literal", it actually is talking about the part that follows the "/" character in the output returned by the InetAddress.toString().
>>> 
>>> I'll be honest - I didn't even know that up until this release, the output of this API was something like google.com/172.217.160.142:80. I had it in my mind that the output was google.com:80. That's why when the new javadoc said "in place of the address literal", I thought it was talking about replacing "google.com" with "<unresolved>"
>>> 
>>> I don't know if it's just me who couldn't fully understand it until this was explained. For me, a {@link InetSocket.toString()} in the javadoc and a couple of example representations of what the output of toString() would look like would have made it easier. But I do understand that the javadoc may not be the right place for such level of details.
>>> 
We can improve the spec wording of this method.

I filed the following issue to track just that:
  https://bugs.openjdk.java.net/browse/JDK-8241995

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/18b0088f/attachment.htm>

From chris.hegarty at oracle.com  Wed Apr  1 13:29:53 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Apr 2020 14:29:53 +0100
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of
 socket options 
Message-ID: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>

DatagramSocket incorrectly caches the first set of socket options that
it encounters (through an invocation of supportedOptions()),
subsequently returning that set of options regardless of what the
particular datagram socket impl actually supports.

Webrev:
  https://cr.openjdk.java.net/~chegar/8241988/webrev/
JIRA:
  https://bugs.openjdk.java.net/browse/JDK-8241988

This issue has been filed so as to extract the long(ish) standing issue
from the work being done to support JEP 373 [1]. The code changes in 
this review are only slightly different to the changes being proposed in
the review for 373 [1], so can be merged will little effort.

-Chris.

[1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013748.html

From macanaoire at hotmail.com  Wed Apr  1 14:12:23 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 1 Apr 2020 14:12:23 +0000
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options 
In-Reply-To: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
References: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
Message-ID: <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Chris,
      just looking at the supportedOptions method in the two classes
DatagramSocket and MulticastSocket, if I haven't misread them, are
they not the same?
As such MulticastSocket could inherit that method from DatagramSocket ?
(without the necessity to override)

regards
Mark

________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Chris Hegarty <chris.hegarty at oracle.com>
Sent: Wednesday 1 April 2020 13:29
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

DatagramSocket incorrectly caches the first set of socket options that
it encounters (through an invocation of supportedOptions()),
subsequently returning that set of options regardless of what the
particular datagram socket impl actually supports.

Webrev:
  https://cr.openjdk.java.net/~chegar/8241988/webrev/
JIRA:
  https://bugs.openjdk.java.net/browse/JDK-8241988

This issue has been filed so as to extract the long(ish) standing issue
from the work being done to support JEP 373 [1]. The code changes in
this review are only slightly different to the changes being proposed in
the review for 373 [1], so can be merged will little effort.

-Chris.

[1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013748.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/9633fc77/attachment-0001.htm>

From chris.hegarty at oracle.com  Wed Apr  1 15:04:30 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Apr 2020 16:04:30 +0100
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options
In-Reply-To: <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
 <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>


> On 1 Apr 2020, at 15:12, mark sheppard <macanaoire at hotmail.com> wrote:
> 
> Hi Chris,
>       just looking at the supportedOptions method in the two classes
> DatagramSocket and MulticastSocket, if I haven't misread them, are
> they not the same?
> As such MulticastSocket could inherit that method from DatagramSocket ?
> (without the necessity to override)

Good idea Mark.

Updated webrev:
  https://cr.openjdk.java.net/~chegar/8241988/webrev.01/

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/263455b4/attachment.htm>

From daniel.fuchs at oracle.com  Wed Apr  1 15:17:24 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 1 Apr 2020 16:17:24 +0100
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options
In-Reply-To: <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>
References: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
 <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>
Message-ID: <6a1a31fb-87eb-b7bd-ecba-520f1ae16eed@oracle.com>

Looks good to me Chris!

best regards,

-- daniel

On 01/04/2020 16:04, Chris Hegarty wrote:
> 
>> On 1 Apr 2020, at 15:12, mark sheppard <macanaoire at hotmail.com 
>> <mailto:macanaoire at hotmail.com>> wrote:
>>
>> Hi Chris,
>> ? ? ? just looking at the supportedOptions method in the two classes
>> DatagramSocket and MulticastSocket, if I haven't misread them, are
>> they not the same?
>> As such MulticastSocket could inherit that method from DatagramSocket ?
>> (without the necessity to override)
> 
> Good idea Mark.
> 
> Updated webrev:
> https://cr.openjdk.java.net/~chegar/8241988/webrev.01/
> 
> -Chris.
> 


From mark.sheppard at oracle.com  Wed Apr  1 15:45:02 2020
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 1 Apr 2020 08:45:02 -0700 (PDT)
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options
Message-ID: <284378ca-152d-48fa-aae2-091884439e4f@default>


thanks Chris 


:+1 


regards 
Mark 

----- Original Message ----- 
From: chris.hegarty at oracle.com 
To: macanaoire at hotmail.com, mark.sheppard at oracle.com, net-dev at openjdk.java.net 
Sent: Wednesday, 1 April, 2020 4:04:33 PM GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options 







On 1 Apr 2020, at 15:12, mark sheppard < macanaoire at hotmail.com > wrote: 


Hi Chris, 
just looking at the supportedOptions method in the two classes 
DatagramSocket and MulticastSocket, if I haven't misread them, are 
they not the same? 
As such MulticastSocket could inherit that method from DatagramSocket ? 
(without the necessity to override) 

Good idea Mark. 


Updated webrev: 
https://cr.openjdk.java.net/~chegar/8241988/webrev.01/ 


-Chris. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/3befe9b4/attachment.htm>

From macanaoire at hotmail.com  Wed Apr  1 16:03:41 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 1 Apr 2020 16:03:41 +0000
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>,
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
Message-ID: <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Michael et al.,
    just looking at the webrev ... the change in URLClassPath seems reasonable.
The change in JarURLConnection  has implications and would change the semantics of
the getJarFile method.

using the example accompanying this JBS item to demonstrate an issue caused by the caching mechanism
within the URLConnection framework, it should be noted that the jar URL is referencing
an non existent entry in the jar file entry. Thus some form of exception would be anticipated in this scenario.

With the proposed change, this will return a JarFile regardless of whether a referenced resource (URL) exists or not.

Examining  the call flows it can be observed that
the getJarFile invokes connect. This will retrieve a jar file via JarFileFactory
 and then, because the URL references an entry in the jar file, attempts
 to access the entry resulting in a  null return,  which generates a FNF exception to be thrown.

Also note that an explicit invocation of connect on the JarURLConnection instance will result in the FNFException.

the change in the JarURLConnection will return a jar file in this test scenario and not the FNF exception. Based on the methods
spec is that acceptable behaviour change?


public abstract JarFile getJarFile throws IOException

Return the JAR file for this connection.

Returns:
the JAR file for this connection. If the connection is a connection to an entry of a JAR file, the JAR file object is returned
Throws:
IOException<https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html> - if an IOException occurs while trying to connect to the JAR file for this connection.
See Also:
URLConnection.connect()<https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#connect()>
and connect says
"Opens a communications link to the resource referenced by this URL, if such a connection has not already been established."

So should the getJarFile return be a reference to JarFile for an URL specifying an non existent entry  i.e. the resource doesn't exist?
Is the resource associated with a JarURLConnection the encapsulated JarFile? Or the target in the specified  in the URL ?

There are a series of similar behaviour anomalies in this area URL/URLConnection/JarURLConnection (on Windows) and in general they
can be attributed to the internal caching  mechanism, which is enabled OOTB, and its impact on the closing of file resource in Exception conditions scenarios.

Disabling caching for jar protocol , which will allow consistent and correct behaviour is one possibility.

As such an alternative or workaround  is to disable caching for the jar protocol
via the URLConnection::setDefaultUseCaches() on Windows where an application
may want to delete a jar file resource, for example:

URLConnection.setDefaultUseCaches("jar", false);

best regards
Mark

________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Monday 16 March 2020 12:39
To: Alex Kashchenko <akashche at redhat.com>
Cc: net-dev at openjdk.java.net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi Alex,

(and redirecting the thread to net-dev)

It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior
rather than the spec.

But, more important I think is the behavior change of the fix itself and
that will require
careful review which we can't commit to immediately. We will try and get
back to you
about it in a week or so.

Thanks,

Michael.

On 14/03/2020 00:08, Alex Kashchenko wrote:
> Hi,
>
> Based on these maillist threads:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html
>
>
> I am looking for comments and suggestions, whether the following
> change to JarURLConnection.getJarFile() behaviour may be acceptable:
>
> If, during connect() call, jarFile itself was created successfully,
> but access to (non-existent) jarEntry failed - return this jarFile to
> caller instead of throwing exception.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
>
> This change also allows to fix JDK-8232854 with the minimal change to
> URLClassPath (included with the patch).
>
> This change doesn't cause regression failures in java/net.
>
> This change causes one compatibility failure, when getManifest()
> doesn't throw expected IOException when URL points to non-existent
> class inside JAR.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/09571440/attachment-0001.htm>

From Alan.Bateman at oracle.com  Wed Apr  1 16:51:19 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Apr 2020 17:51:19 +0100
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options
In-Reply-To: <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>
References: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
 <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>
Message-ID: <94630b79-7ae7-3459-d885-a012e8d6c758@oracle.com>

On 01/04/2020 16:04, Chris Hegarty wrote:
> :
>
> Updated webrev:
> https://cr.openjdk.java.net/~chegar/8241988/webrev.01/
>
Looks good although I can't immediately see why options is package private

I assume the tests runs in /othervm because of the 
setDatagramSocketImplFactory.

-Alan


From daniel.fuchs at oracle.com  Wed Apr  1 17:42:20 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 1 Apr 2020 18:42:20 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due
 to "SocketException: No buffer space available"
Message-ID: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>

Hi,

Please find below a fix for:

8241786: 3 DatagramChannel tests and 2 MulticastSocket tests
          fail due to "SocketException: No buffer space available"
https://bugs.openjdk.java.net/browse/JDK-8241786

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/

The real fix is in these three files:

DefaultInterface.java (macOS): is modified to prefer interfaces
     that have non link local addresses
NetworkConfiguration.java (test lib): is modified to skip
     interfaces that have only link-local addresses (whether IPv4
     or IPv6) for multicasting.
MulticastSocket/SetOutgoingIf.java: this test does its own thing,
     and is modified similarly to NetworkConfiguration

Additional cleanup:

The other tests are just modified to add diagnostic and use 
try-with-resources whenever possible, and also use /othervm to avoid 
some undesirable side effects (like not seeing any trace):

MulticastSocket/SetLoopbackMode.java
MulticastSocket/SetLoopbackModeIPv4.java
DatagramChannel/AdaptorMulticasting.java
DatagramChannel/MulticastSendReceiveTests.java
DatagramChannel/Promiscuous.java

best regards,

-- daniel

From chris.hegarty at oracle.com  Wed Apr  1 18:07:15 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Apr 2020 19:07:15 +0100
Subject: RFR [15] 8241988 DatagramSocket incorrectly caches the first set
 of socket options
In-Reply-To: <94630b79-7ae7-3459-d885-a012e8d6c758@oracle.com>
References: <0BA7E883-078F-4FDC-B6FE-9D307461C75B@oracle.com>
 <DBBPR09MB3014C4E0FD90BAF0029B9E4BDFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <BC6725C8-B616-4E10-A7D6-7112E6BC4B5A@oracle.com>
 <94630b79-7ae7-3459-d885-a012e8d6c758@oracle.com>
Message-ID: <F109D2CF-1CC0-4223-895D-968571D212B3@oracle.com>


> On 1 Apr 2020, at 17:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 01/04/2020 16:04, Chris Hegarty wrote:
>> :
>> 
>> Updated webrev:
>> https://cr.openjdk.java.net/~chegar/8241988/webrev.01/
>> 
> Looks good although I can't immediately see why options is package private

It can be private. I?ll make that change before pushing.

> I assume the tests runs in /othervm because of the setDatagramSocketImplFactory.

Correct.

-Chris.

From Alan.Bateman at oracle.com  Wed Apr  1 19:50:31 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Apr 2020 20:50:31 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
Message-ID: <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>



On 01/04/2020 18:42, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests
> ???????? fail due to "SocketException: No buffer space available"
> https://bugs.openjdk.java.net/browse/JDK-8241786
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/
>
> The real fix is in these three files:
>
> DefaultInterface.java (macOS): is modified to prefer interfaces
> ??? that have non link local addresses
> NetworkConfiguration.java (test lib): is modified to skip
> ??? interfaces that have only link-local addresses (whether IPv4
> ??? or IPv6) for multicasting.
> MulticastSocket/SetOutgoingIf.java: this test does its own thing,
> ??? and is modified similarly to NetworkConfiguration
>
> Additional cleanup:
>
> The other tests are just modified to add diagnostic and use 
> try-with-resources whenever possible, and also use /othervm to avoid 
> some undesirable side effects (like not seeing any trace):
>
> MulticastSocket/SetLoopbackMode.java
> MulticastSocket/SetLoopbackModeIPv4.java
> DatagramChannel/AdaptorMulticasting.java
> DatagramChannel/MulticastSendReceiveTests.java
> DatagramChannel/Promiscuous.java
The change to java.net.DefaultInterface to workaround bad configurations 
on macOS looks good. Hopefully existing usages of the 1-arg joinGroup 
will migrate to the 2-arg variant and avoid needing the JDK to choose on 
multi-homed systems.

DefaultInterface might be better in a test infra class (in java/net) to 
avoid duplicate it in several tests.

The updates to the DatagramChannel tests look okay but I think we should 
change the new trace messages added to AdaptorMulticasting to be 
consistent with the existing trace, e.g. the test cycles through the 
families and interfaces and prints output like this following before 
each run:

Test family=INET, multicast group=/225.4.5.6, interface=en0

The changes in the patch duplicate a subset of this in a different 
format. It might be simpler to just not duplicate it but print just 
print the name of the sub-tests, whatever is easiest.

NetworkConfiguration looks okay although I could imagine the comment 
added at L101-103 not being clearer for future maintainers. I think 
we'll need to do a cleanup of this test class at some point.

-Alan



From macanaoire at hotmail.com  Wed Apr  1 23:14:31 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 1 Apr 2020 23:14:31 +0000
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>,
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>,
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>

 p.s.

I had also meant to say in the response below, that the proposed getJaFile solution is
perfectly reasonable and would allow a recoverable strategy in an related
scenario where a URLConnection:: connect,  for the same type of entry URL,
throws a FNFException resulting in the same type of "resource leak".
But, in this case, with the proposed change the JarFile can be retrieved and closed.

regards
Mark



________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of mark sheppard <macanaoire at hotmail.com>
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon <michael.x.mcmahon at oracle.com>; Alex Kashchenko <akashche at redhat.com>
Cc: Mark Sheppard <mark.sheppard at oracle.com>; net-dev at openjdk.java.net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi Michael et al.,
    just looking at the webrev ... the change in URLClassPath seems reasonable.
The change in JarURLConnection  has implications and would change the semantics of
the getJarFile method.

using the example accompanying this JBS item to demonstrate an issue caused by the caching mechanism
within the URLConnection framework, it should be noted that the jar URL is referencing
an non existent entry in the jar file entry. Thus some form of exception would be anticipated in this scenario.

With the proposed change, this will return a JarFile regardless of whether a referenced resource (URL) exists or not.

Examining  the call flows it can be observed that
the getJarFile invokes connect. This will retrieve a jar file via JarFileFactory
 and then, because the URL references an entry in the jar file, attempts
 to access the entry resulting in a  null return,  which generates a FNF exception to be thrown.

Also note that an explicit invocation of connect on the JarURLConnection instance will result in the FNFException.

the change in the JarURLConnection will return a jar file in this test scenario and not the FNF exception. Based on the methods
spec is that acceptable behaviour change?


public abstract JarFile getJarFile throws IOException

Return the JAR file for this connection.

Returns:
the JAR file for this connection. If the connection is a connection to an entry of a JAR file, the JAR file object is returned
Throws:
IOException<https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html> - if an IOException occurs while trying to connect to the JAR file for this connection.
See Also:
URLConnection.connect()<https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#connect()>
and connect says
"Opens a communications link to the resource referenced by this URL, if such a connection has not already been established."

So should the getJarFile return be a reference to JarFile for an URL specifying an non existent entry  i.e. the resource doesn't exist?
Is the resource associated with a JarURLConnection the encapsulated JarFile? Or the target in the specified  in the URL ?

There are a series of similar behaviour anomalies in this area URL/URLConnection/JarURLConnection (on Windows) and in general they
can be attributed to the internal caching  mechanism, which is enabled OOTB, and its impact on the closing of file resource in Exception conditions scenarios.

Disabling caching for jar protocol , which will allow consistent and correct behaviour is one possibility.

As such an alternative or workaround  is to disable caching for the jar protocol
via the URLConnection::setDefaultUseCaches() on Windows where an application
may want to delete a jar file resource, for example:

URLConnection.setDefaultUseCaches("jar", false);

best regards
Mark

________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Monday 16 March 2020 12:39
To: Alex Kashchenko <akashche at redhat.com>
Cc: net-dev at openjdk.java.net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi Alex,

(and redirecting the thread to net-dev)

It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior
rather than the spec.

But, more important I think is the behavior change of the fix itself and
that will require
careful review which we can't commit to immediately. We will try and get
back to you
about it in a week or so.

Thanks,

Michael.

On 14/03/2020 00:08, Alex Kashchenko wrote:
> Hi,
>
> Based on these maillist threads:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html
>
>
> I am looking for comments and suggestions, whether the following
> change to JarURLConnection.getJarFile() behaviour may be acceptable:
>
> If, during connect() call, jarFile itself was created successfully,
> but access to (non-existent) jarEntry failed - return this jarFile to
> caller instead of throwing exception.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
>
> This change also allows to fix JDK-8232854 with the minimal change to
> URLClassPath (included with the patch).
>
> This change doesn't cause regression failures in java/net.
>
> This change causes one compatibility failure, when getManifest()
> doesn't throw expected IOException when URL points to non-existent
> class inside JAR.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200401/1fae3904/attachment-0001.htm>

From chris.hegarty at oracle.com  Thu Apr  2 08:40:53 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 2 Apr 2020 09:40:53 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
Message-ID: <63D83EB8-7CA6-407B-97DC-AF4133417FD5@oracle.com>

Daniel,

> On 1 Apr 2020, at 18:42, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests
>         fail due to "SocketException: No buffer space available"
> https://bugs.openjdk.java.net/browse/JDK-8241786

Good work. A really tough issue to diagnose.

This is a functional change that affects the product build. Maybe that
would be a little clearer from a different bug synopsis. Suggest
something like:

  Improve heuristic to determine default network interface on macOS

> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/

DefaultInterface.java

  Unless I'm mistaken, the first IPv4+IPv6+nonLinkLocal interface is not
necessarily returned. The second will be returned if there are two such
interfaces. I'm not saying that this is necessarily a problem, just
trying to reconsile the code with the comment. Maybe the `preferred` can
be skipped, just returning such an IPv4+IPv6+nonLinkLocal if found.

-Chris.

From daniel.fuchs at oracle.com  Thu Apr  2 08:48:57 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Apr 2020 09:48:57 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>
Message-ID: <e11ac9c8-b5e9-ead9-9852-d990206af63e@oracle.com>

Hi Alan,

On 01/04/2020 20:50, Alan Bateman wrote:
> The change to java.net.DefaultInterface to workaround bad configurations 
> on macOS looks good. Hopefully existing usages of the 1-arg joinGroup 
> will migrate to the 2-arg variant and avoid needing the JDK to choose on 
> multi-homed systems.

Thanks.

> DefaultInterface might be better in a test infra class (in java/net) to 
> avoid duplicate it in several tests.

I have considered that. The problem is that it requires the test that
uses it to add @modules java.base/java.net:+open directive in the test
itself. At the moment only one test uses it - so there is no
duplication (yet). Maybe we should wait until we need it elsewhere
before thinking of ways to move it to the test library?

> The updates to the DatagramChannel tests look okay but I think we should 
> change the new trace messages added to AdaptorMulticasting to be 
> consistent with the existing trace, e.g. the test cycles through the 
> families and interfaces and prints output like this following before 
> each run:
> 
> Test family=INET, multicast group=/225.4.5.6, interface=en0 >
> The changes in the patch duplicate a subset of this in a different 
> format. It might be simpler to just not duplicate it but print just 
> print the name of the sub-tests, whatever is easiest.

When I ran this test it was failing in timeout with *no* traces.
I hate that. I added traces to figure out at which point it was
failing. There might be a bit of duplication in the information,
but I'd rather have that than wonder if the test is actually
doing what I think it does. When unexplainable things happen,
I start doubting everything ;-)

If you insist I'll reluctantly remove the redundant information,
but I do think it helps.

> NetworkConfiguration looks okay although I could imagine the comment 
> added at L101-103 not being clearer for future maintainers. I think 
> we'll need to do a cleanup of this test class at some point.

I'll see if I can clarify this - or maybe I'll just remove it.
I agree it could be confusing.

best regards,

-- daniel

> 
> -Alan
> 


From Alan.Bateman at oracle.com  Thu Apr  2 08:56:05 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Apr 2020 09:56:05 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <e11ac9c8-b5e9-ead9-9852-d990206af63e@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>
 <e11ac9c8-b5e9-ead9-9852-d990206af63e@oracle.com>
Message-ID: <26688831-e801-3d17-54f3-22ec3db585c4@oracle.com>



On 02/04/2020 09:48, Daniel Fuchs wrote:
> :
>
>> DefaultInterface might be better in a test infra class (in java/net) 
>> to avoid duplicate it in several tests.
>
> I have considered that. The problem is that it requires the test that
> uses it to add @modules java.base/java.net:+open directive in the test
> itself. At the moment only one test uses it - so there is no
> duplication (yet). Maybe we should wait until we need it elsewhere
> before thinking of ways to move it to the test library?
Okay, I was assuming it would end up being used by several 
MulticastSocket tests.

> :
>
> When I ran this test it was failing in timeout with *no* traces.
> I hate that. I added traces to figure out at which point it was
> failing. There might be a bit of duplication in the information,
> but I'd rather have that than wonder if the test is actually
> doing what I think it does. When unexplainable things happen,
> I start doubting everything ;-)
>
> If you insist I'll reluctantly remove the redundant information,
> but I do think it helps.
All I'm asking is that additional tracing being consistent with the 
existing traces. Stack traces and thread dumps the most useful when 
there is a timeout or test timeout. I wonder if there is an? issue with 
the timeout/failure handler right now so you should have got one here in 
the event that the receive blocks indefinitely.

-Alan

From daniel.fuchs at oracle.com  Thu Apr  2 09:33:41 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Apr 2020 10:33:41 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <63D83EB8-7CA6-407B-97DC-AF4133417FD5@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <63D83EB8-7CA6-407B-97DC-AF4133417FD5@oracle.com>
Message-ID: <de0a5c67-9a82-4677-bf7d-1a24066d9007@oracle.com>

Hi Chris,

On 02/04/2020 09:40, Chris Hegarty wrote:
> This is a functional change that affects the product build. Maybe that
> would be a little clearer from a different bug synopsis. Suggest
> something like:
> 
>    Improve heuristic to determine default network interface on macOS

I can do that - or I can split the change if needed: that is push
the changes to DefaultInterface on its on?
Maybe I should add an @bug 8241786 to some of these tests too.

>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/
> 
> DefaultInterface.java
> 
>    Unless I'm mistaken, the first IPv4+IPv6+nonLinkLocal interface is not
> necessarily returned.

Damn. Good catch! But that's your bug Chris: it was already there :-)

http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.02

includes yours and Alan's feedback.

-- daniel

> The second will be returned if there are two such
> interfaces. I'm not saying that this is necessarily a problem, just
> trying to reconsile the code with the comment. Maybe the `preferred` can
> be skipped, just returning such an IPv4+IPv6+nonLinkLocal if found.
> 
> -Chris.
> 


From jai.forums2013 at gmail.com  Thu Apr  2 10:02:19 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 2 Apr 2020 15:32:19 +0530
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <32D490C7-EFAD-4232-A80C-7F8A27821FA3@oracle.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
 <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>
 <79a70622-1969-e014-b775-24a14523d8ba@oracle.com>
 <333b7e44-f2b7-1cd5-f707-4897f2b6e487@gmail.com>
 <32D490C7-EFAD-4232-A80C-7F8A27821FA3@oracle.com>
Message-ID: <87f6de7d-f3fe-3d97-cf57-fc158710fbfe@gmail.com>

Thank you Chris.

-Jaikiran

On 01/04/20 6:40 pm, Chris Hegarty wrote:
>
>
>> On 1 Apr 2020, at 13:48, Jaikiran Pai <jai.forums2013 at gmail.com
>> <mailto:jai.forums2013 at gmail.com>> wrote:
>>>>> ...
>>>>
>>>> Now that you explained it to me, I see what you mean and what that
>>>> javadoc means. I hadn't paid attention to the "This String is
>>>> constructed by calling toString() on the InetAddress and
>>>> concatenating the port number (with a colon)". Looking at the
>>>> javadoc on InetAddress.toString(), it does state the returned
>>>> string to be of the form "hostname/literal IP address" (example:
>>>> google.com/172.217.160.142 <http://google.com/172.217.160.142>). So
>>>> when it says that "<unresolved> is displayed in place of the
>>>> address literal", it actually is talking about the part that
>>>> follows the "/" character in the output returned by the
>>>> InetAddress.toString().
>>>>
>>>> I'll be honest - I didn't even know that up until this release, the
>>>> output of this API was something like google.com/172.217.160.142:80
>>>> <http://google.com/172.217.160.142:80>. I had it in my mind that
>>>> the output was google.com:80 <http://google.com:80>. That's why
>>>> when the new javadoc said "in place of the address literal", I
>>>> thought it was talking about replacing "google.com
>>>> <http://google.com>" with "<unresolved>"
>>>>
>>>> I don't know if it's just me who couldn't fully understand it until
>>>> this was explained. For me, a {@link InetSocket.toString()} in the
>>>> javadoc and a couple of example representations of what the output
>>>> of toString() would look like would have made it easier. But I do
>>>> understand that the javadoc may not be the right place for such
>>>> level of details.
>>>>
> We can improve the spec wording of this method.
>
> I filed the following issue to track just that:
> ??https://bugs.openjdk.java.net/browse/JDK-8241995
>
> -Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200402/99076960/attachment-0001.htm>

From chris.hegarty at oracle.com  Thu Apr  2 14:11:53 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 2 Apr 2020 15:11:53 +0100
Subject: RFR [15] 8242044: Add basic HTTP/1.1 support to the HTTP/2 Test Server
Message-ID: <EE3DE181-C832-4D0F-94F5-0B1052366C9E@oracle.com>

To more easily write HTTP Client test scenarios for different protocol
versions and different TLS versions, it would be very convenient if the
HTTP/2 server, that is part of the JDK regression test suite, was able
to issue basic HTTP/1.1 responses.

This enhance adds minimal support, which effectively returns a canned
200 - OK - response to all non-upgrade HTTP/1.1 requests, as well as
secure connections that do not negotiate the h2 ALPN. This new
functionality is opt-in so as to not inadvertently affect existing tests
which assume HTTP/2 only support.

https://cr.openjdk.java.net/~chegar/8242044/webrev/

-Chris.

From daniel.fuchs at oracle.com  Thu Apr  2 14:39:30 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Apr 2020 15:39:30 +0100
Subject: RFR [15] 8242044: Add basic HTTP/1.1 support to the HTTP/2 Test
 Server
In-Reply-To: <EE3DE181-C832-4D0F-94F5-0B1052366C9E@oracle.com>
References: <EE3DE181-C832-4D0F-94F5-0B1052366C9E@oracle.com>
Message-ID: <a2d803df-0715-c30b-b62f-27e00ad70fc3@oracle.com>

Looks good to me Chris.

best regards,

-- daniel

On 02/04/2020 15:11, Chris Hegarty wrote:
> To more easily write HTTP Client test scenarios for different protocol
> versions and different TLS versions, it would be very convenient if the
> HTTP/2 server, that is part of the JDK regression test suite, was able
> to issue basic HTTP/1.1 responses.
> 
> This enhance adds minimal support, which effectively returns a canned
> 200 - OK - response to all non-upgrade HTTP/1.1 requests, as well as
> secure connections that do not negotiate the h2 ALPN. This new
> functionality is opt-in so as to not inadvertently affect existing tests
> which assume HTTP/2 only support.
> 
> https://cr.openjdk.java.net/~chegar/8242044/webrev/
> 
> -Chris.
> 


From michael.x.mcmahon at oracle.com  Thu Apr  2 15:55:37 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 2 Apr 2020 16:55:37 +0100
Subject: RFR [15] 8242044: Add basic HTTP/1.1 support to the HTTP/2 Test
 Server
In-Reply-To: <a2d803df-0715-c30b-b62f-27e00ad70fc3@oracle.com>
References: <EE3DE181-C832-4D0F-94F5-0B1052366C9E@oracle.com>
 <a2d803df-0715-c30b-b62f-27e00ad70fc3@oracle.com>
Message-ID: <29e26c40-fc49-5881-dc58-88d62c3b712d@oracle.com>

+1

Michael

On 02/04/2020 15:39, Daniel Fuchs wrote:
> Looks good to me Chris.
>
> best regards,
>
> -- daniel
>
> On 02/04/2020 15:11, Chris Hegarty wrote:
>> To more easily write HTTP Client test scenarios for different protocol
>> versions and different TLS versions, it would be very convenient if the
>> HTTP/2 server, that is part of the JDK regression test suite, was able
>> to issue basic HTTP/1.1 responses.
>>
>> This enhance adds minimal support, which effectively returns a canned
>> 200 - OK - response to all non-upgrade HTTP/1.1 requests, as well as
>> secure connections that do not negotiate the h2 ALPN. This new
>> functionality is opt-in so as to not inadvertently affect existing tests
>> which assume HTTP/2 only support.
>>
>> https://cr.openjdk.java.net/~chegar/8242044/webrev/
>>
>> -Chris.
>>
>

From chris.hegarty at oracle.com  Fri Apr  3 08:59:10 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 3 Apr 2020 09:59:10 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <de0a5c67-9a82-4677-bf7d-1a24066d9007@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <63D83EB8-7CA6-407B-97DC-AF4133417FD5@oracle.com>
 <de0a5c67-9a82-4677-bf7d-1a24066d9007@oracle.com>
Message-ID: <113A2261-001E-4418-8D07-49C51897AEAB@oracle.com>

Daniel,

> On 2 Apr 2020, at 10:33, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 02/04/2020 09:40, Chris Hegarty wrote:
>> This is a functional change that affects the product build. Maybe that
>> would be a little clearer from a different bug synopsis. Suggest
>> something like:
>>   Improve heuristic to determine default network interface on macOS
> 
> I can do that -

An updated synopsis should be fine.

> or I can split the change if needed: that is push
> the changes to DefaultInterface on its on?
> Maybe I should add an @bug 8241786 to some of these tests too.
> 
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/
>> DefaultInterface.java
>>   Unless I'm mistaken, the first IPv4+IPv6+nonLinkLocal interface is not
>> necessarily returned.
> 
> Damn. Good catch! But that's your bug Chris: it was already there :-)
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.02

LGTM.

-Chris.

From daniel.fuchs at oracle.com  Fri Apr  3 11:04:32 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Apr 2020 12:04:32 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <26688831-e801-3d17-54f3-22ec3db585c4@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>
 <e11ac9c8-b5e9-ead9-9852-d990206af63e@oracle.com>
 <26688831-e801-3d17-54f3-22ec3db585c4@oracle.com>
Message-ID: <67864fc4-804a-28fd-5345-749dc190a345@oracle.com>

Hi Alan,

Hopefully that's fixed now. Only change is in AdaptorMulticasting.java

http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03

best regards,

-- daniel

On 02/04/2020 09:56, Alan Bateman wrote:
> All I'm asking is that additional tracing being consistent with the 
> existing traces. Stack traces and thread dumps the most useful when 
> there is a timeout or test timeout. I wonder if there is an? issue with 
> the timeout/failure handler right now so you should have got one here in 
> the event that the receive blocks indefinitely.


From Alan.Bateman at oracle.com  Fri Apr  3 11:31:47 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Apr 2020 12:31:47 +0100
Subject: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail
 due to "SocketException: No buffer space available"
In-Reply-To: <67864fc4-804a-28fd-5345-749dc190a345@oracle.com>
References: <da204267-0ea0-aff2-42db-803beb4ce406@oracle.com>
 <f4c562fd-81fc-2a81-44b9-ffc7cff1ae38@oracle.com>
 <e11ac9c8-b5e9-ead9-9852-d990206af63e@oracle.com>
 <26688831-e801-3d17-54f3-22ec3db585c4@oracle.com>
 <67864fc4-804a-28fd-5345-749dc190a345@oracle.com>
Message-ID: <c48308bc-47a7-f5eb-a0bf-b0969c9477ff@oracle.com>



On 03/04/2020 12:04, Daniel Fuchs wrote:
> Hi Alan,
>
> Hopefully that's fixed now. Only change is in AdaptorMulticasting.java
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03
Thanks, looks good.

-Alan

From patrick.concannon at oracle.com  Fri Apr  3 13:47:15 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 3 Apr 2020 06:47:15 -0700 (PDT)
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
Message-ID: <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>

Hi,

Thanks for the feedback. 



Lance - I swapped out expectThrows for assertThrows, as requested.

Chris - I put in an extra check in the tests to ensure that the new code 
doesn?t interfere with the Security Manager checks already present in 
the source.

The new webrev can be found here: 
http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/

 
<http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/>


Kind regards,

Patrick

On 31/03/2020 15:33, Chris Hegarty wrote:
> Patrick,
>
>> On 31 Mar 2020, at 15:08, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>>> ..
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8240533
>>> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/
> Look good Patrick.
>
> The check is deliberately performed after the security manager checks, right? If so, it is worth asserting this in a test.
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200403/32c75fac/attachment.htm>

From chris.hegarty at oracle.com  Fri Apr  3 16:08:32 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 3 Apr 2020 09:08:32 -0700 (PDT)
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
Message-ID: <57F70695-2696-423F-8286-354723E778E9@oracle.com>

Hi Patrick,

> On 3 Apr 2020, at 14:47, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> ...
> 
> Chris - I put in an extra check in the tests to ensure that the new code doesn?t interfere with the Security Manager checks already present in the source.

Thank you Patrick.

> The new webrev can be found here: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/
> 
> 

I have just a few more minor comments:

I think there is a small cut?n?paste issue with test/jdk/java/nio/channels/DatagramChannel/SendPortZero.java

  59  * @run testng/othervm -Djava.net.preferIPv4Stack=true ConnectPortZero  <<< should be SendPortZero

typo:   Execption in two test summary tags

There is no need to use two instance initializers, when one will suffice ;-) :

 123         { perms.add(
 124                 new SocketPermission("127.0.0.1:0", "connect")); }
 125         { perms.add(
 126                 new SocketPermission("0.0.0.0:0", "connect")); }

Just:
  { perms.add(new SocketPermission("127.0.0.1:0", "connect"));
    perms.add(new SocketPermission("0.0.0.0:0", "connect"));  }

Thanks,
-Chris.









From daniel.fuchs at oracle.com  Fri Apr  3 16:16:22 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Apr 2020 17:16:22 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
Message-ID: <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>

Hi Patrick,

  120         { perms.add(new SocketPermission("127.0.0.1:0",
  121                 "connect,accept")); }
  122         { perms.add(new SocketPermission("0.0.0.0:0",
  123                 "connect,accept")); }

there in other tests - I think a single permission:

     { perms.add(new SocketPermission("*:0")); }

would be more robust as it would take care of both IPv6 and IPv4 in one
go. We should strive to avoid to hard-code 127.0.0.1 and 0.0.0.0
in tests.

best regards,

-- daniel

On 03/04/2020 14:47, Patrick Concannon wrote:
> Hi,
> 
> Thanks for the feedback. 


> 
> Lance - I swapped out expectThrows for assertThrows, as requested.
> 
> Chris - I put in an extra check in the tests to ensure that the new code 
> doesn?t interfere with the Security Manager checks already present in 
> the source.
> 
> The new webrev can be found here: 
> http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/

 
> <http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/>
> 
> 
> Kind regards,
> 
> Patrick
> 
> On 31/03/2020 15:33, Chris Hegarty wrote:
>> Patrick,
>>
>>> On 31 Mar 2020, at 15:08, Daniel Fuchs<daniel.fuchs at oracle.com>  wrote:
>>>
>>>> ..
>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8240533
>>>> webrev:http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/
>> Look good Patrick.
>>
>> The check is deliberately performed after the security manager checks, right? If so, it is worth asserting this in a test.
>>
>> -Chris.
>>


From chris.hegarty at oracle.com  Fri Apr  3 17:26:41 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 3 Apr 2020 18:26:41 +0100
Subject: 8241995: Clarify InetSocketAddress::toString specification
Message-ID: <29F15FC0-AB25-433C-B232-1D73EEA78CCD@oracle.com>

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 "<unresolved>" is displayed. It was also suggested that a link
to getHostString could be added.

Below is an initial suggestion. It does not change the spec, just adds
some examples and guidance. I'm relatively happy with the examples, but
less so with the final advise paragraph. Suggestions welcome.


-  /**
-   * Constructs a string representation of this InetSocketAddress.
-   * This String is constructed by calling toString() on the InetAddress
-   * and concatenating the port number (with a colon). If the address
-   * is an IPv6 address, the IPv6 literal is enclosed in square brackets.
-   * If the address is {@linkplain #isUnresolved() unresolved},
-   * {@code <unresolved>} is displayed in place of the address literal.
-   *
-   * @return  a string representation of this object.
-   */
-  public String toString() { ... }
---
+  /**
+   * Constructs a string representation of this InetSocketAddress.
+   * This String is constructed by calling {@link InetAddress#toString()}
+   * on the InetAddress and concatenating the port number (with a colon).
+   *
+   * <p> If the address is an IPv6 address, the IPv6 literal is enclosed in
+   * square brackets, for example: {@code "localhost/[0:0:0:0:0:0:0:1]:80"}.
+   * If the address is {@linkplain #isUnresolved() unresolved},
+   * {@code <unresolved>} is displayed in place of the address literal, for
+   * example {@code "foo/<unresolved>:80"}.
+   *
+   * <p> To retrieve a string representation of the hostname, or the string
+   * form of the address if it doesn't have a hostname, use {@link
+   * #getHostString()}, rather than parsing the string representation.
+   *
+   * @return  a string representation of this object.
+   */
+  public String toString() { ... }

-Chris

[1]  https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013747.html


From macanaoire at hotmail.com  Fri Apr  3 20:39:38 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Fri, 3 Apr 2020 20:39:38 +0000
Subject: 8241995: Clarify InetSocketAddress::toString specification
In-Reply-To: <29F15FC0-AB25-433C-B232-1D73EEA78CCD@oracle.com>
References: <29F15FC0-AB25-433C-B232-1D73EEA78CCD@oracle.com>
Message-ID: <DBBPR09MB30146892C7C9FE7A53AEB80BDFC70@DBBPR09MB3014.eurprd09.prod.outlook.com>

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 representation.

or

It is advised to use {@link#getHostString()} to obtain a hostname string, or
in the absence of a hostname, a string form of the address. Do not rely on
parsing the toString() return value to obtain a hostname string.

regards
Mark




________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Chris Hegarty <chris.hegarty at oracle.com>
Sent: Friday 3 April 2020 17:26
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
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 "<unresolved>" is displayed. It was also suggested that a link
to getHostString could be added.

Below is an initial suggestion. It does not change the spec, just adds
some examples and guidance. I'm relatively happy with the examples, but
less so with the final advise paragraph. Suggestions welcome.


-  /**
-   * Constructs a string representation of this InetSocketAddress.
-   * This String is constructed by calling toString() on the InetAddress
-   * and concatenating the port number (with a colon). If the address
-   * is an IPv6 address, the IPv6 literal is enclosed in square brackets.
-   * If the address is {@linkplain #isUnresolved() unresolved},
-   * {@code <unresolved>} is displayed in place of the address literal.
-   *
-   * @return  a string representation of this object.
-   */
-  public String toString() { ... }
---
+  /**
+   * Constructs a string representation of this InetSocketAddress.
+   * This String is constructed by calling {@link InetAddress#toString()}
+   * on the InetAddress and concatenating the port number (with a colon).
+   *
+   * <p> If the address is an IPv6 address, the IPv6 literal is enclosed in
+   * square brackets, for example: {@code "localhost/[0:0:0:0:0:0:0:1]:80"}.
+   * If the address is {@linkplain #isUnresolved() unresolved},
+   * {@code <unresolved>} is displayed in place of the address literal, for
+   * example {@code "foo/<unresolved>:80"}.
+   *
+   * <p> To retrieve a string representation of the hostname, or the string
+   * form of the address if it doesn't have a hostname, use {@link
+   * #getHostString()}, rather than parsing the string representation.
+   *
+   * @return  a string representation of this object.
+   */
+  public String toString() { ... }

-Chris

[1]  https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013747.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200403/dcd86fdc/attachment-0001.htm>

From patrick.concannon at oracle.com  Sat Apr  4 15:26:48 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Sat, 4 Apr 2020 16:26:48 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
 <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>
Message-ID: <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>

Hi Chris and Daniel,


Well spotted, Chris. Thanks for that!

Thanks too Daniel, that's a good idea. I've made those changes and 
included them in a new webrev, which you can find below.

http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.02/


Kind regards,

Patrick

On 03/04/2020 17:16, Daniel Fuchs wrote:
> Hi Patrick,
>
> ?120???????? { perms.add(new SocketPermission("127.0.0.1:0",
> ?121???????????????? "connect,accept")); }
> ?122???????? { perms.add(new SocketPermission("0.0.0.0:0",
> ?123???????????????? "connect,accept")); }
>
> there in other tests - I think a single permission:
>
> ??? { perms.add(new SocketPermission("*:0")); }
>
> would be more robust as it would take care of both IPv6 and IPv4 in one
> go. We should strive to avoid to hard-code 127.0.0.1 and 0.0.0.0
> in tests.
>
> best regards,
>
> -- daniel
>
> On 03/04/2020 14:47, Patrick Concannon wrote:
>> Hi,
>>
>> Thanks for the feedback. 


>>
>> Lance - I swapped out expectThrows for assertThrows, as requested.
>>
>> Chris - I put in an extra check in the tests to ensure that the new 
>> code doesn?t interfere with the Security Manager checks already 
>> present in the source.
>>
>> The new webrev can be found here: 
>> http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/

 
>> <http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/>
>>
>>
>> Kind regards,
>>
>> Patrick
>>
>> On 31/03/2020 15:33, Chris Hegarty wrote:
>>> Patrick,
>>>
>>>> On 31 Mar 2020, at 15:08, Daniel Fuchs<daniel.fuchs at oracle.com>? 
>>>> wrote:
>>>>
>>>>> ..
>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8240533
>>>>> webrev:http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/ 
>>>>>
>>> Look good Patrick.
>>>
>>> The check is deliberately performed after the security manager 
>>> checks, right? If so, it is worth asserting this in a test.
>>>
>>> -Chris.
>>>
>

From lance.andersen at oracle.com  Sat Apr  4 17:00:10 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 4 Apr 2020 13:00:10 -0400
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
 <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>
 <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>
Message-ID: <8CFED7A4-CDBA-4969-A9C4-77B574297F33@oracle.com>

Hi Patrick,

This looks good to me..


Best
Lance

> On Apr 4, 2020, at 11:26 AM, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> Hi Chris and Daniel,
> 
> 
> Well spotted, Chris. Thanks for that!
> 
> Thanks too Daniel, that's a good idea. I've made those changes and included them in a new webrev, which you can find below.
> 
> http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.02/
> 
> 
> Kind regards,
> 
> Patrick
> 
> On 03/04/2020 17:16, Daniel Fuchs wrote:
>> Hi Patrick,
>> 
>>  120         { perms.add(new SocketPermission("127.0.0.1:0",
>>  121                 "connect,accept")); }
>>  122         { perms.add(new SocketPermission("0.0.0.0:0",
>>  123                 "connect,accept")); }
>> 
>> there in other tests - I think a single permission:
>> 
>>     { perms.add(new SocketPermission("*:0")); }
>> 
>> would be more robust as it would take care of both IPv6 and IPv4 in one
>> go. We should strive to avoid to hard-code 127.0.0.1 and 0.0.0.0
>> in tests.
>> 
>> best regards,
>> 
>> -- daniel
>> 
>> On 03/04/2020 14:47, Patrick Concannon wrote:
>>> Hi,
>>> 
>>> Thanks for the feedback. 
> 
> 
>>> 
>>> Lance - I swapped out expectThrows for assertThrows, as requested.
>>> 
>>> Chris - I put in an extra check in the tests to ensure that the new code doesn?t interfere with the Security Manager checks already present in the source.
>>> 
>>> The new webrev can be found here: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/
> 
>>> <http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/>
>>> 
>>> 
>>> Kind regards,
>>> 
>>> Patrick
>>> 
>>> On 31/03/2020 15:33, Chris Hegarty wrote:
>>>> Patrick,
>>>> 
>>>>> On 31 Mar 2020, at 15:08, Daniel Fuchs<daniel.fuchs at oracle.com>  wrote:
>>>>> 
>>>>>> ..
>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8240533
>>>>>> webrev:http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/ 
>>>> Look good Patrick.
>>>> 
>>>> The check is deliberately performed after the security manager checks, right? If so, it is worth asserting this in a test.
>>>> 
>>>> -Chris.
>>>> 
>> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200404/db1b171b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200404/db1b171b/oracle_sig_logo.gif>

From daniel.fuchs at oracle.com  Mon Apr  6 08:17:15 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 6 Apr 2020 09:17:15 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
 <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>
 <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>
Message-ID: <5012e625-155d-9b6c-3008-d59699dbe11a@oracle.com>

Looks good to me Patrick!

best regards,

-- daniel

On 04/04/2020 16:26, Patrick Concannon wrote:
> Hi Chris and Daniel,
> 
> 
> Well spotted, Chris. Thanks for that!
> 
> Thanks too Daniel, that's a good idea. I've made those changes and 
> included them in a new webrev, which you can find below.
> 
> http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.02/
> 
> 
> Kind regards,
> 
> Patrick


From chris.hegarty at oracle.com  Mon Apr  6 09:49:08 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 6 Apr 2020 10:49:08 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <5012e625-155d-9b6c-3008-d59699dbe11a@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
 <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>
 <0911616f-d0dd-877c-de99-1c2cd85f7b1a@oracle.com>
 <f65c7cd1-e302-753f-75c7-c3d89aa14671@oracle.com>
 <bb491549-11fe-5366-2c85-048c3a8afb7f@oracle.com>
 <5012e625-155d-9b6c-3008-d59699dbe11a@oracle.com>
Message-ID: <5676BA5A-2D67-4DC3-B618-6583B91B44B0@oracle.com>



> On 04/04/2020 16:26, Patrick Concannon wrote:
>> Hi Chris and Daniel,
>> Well spotted, Chris. Thanks for that!
>> Thanks too Daniel, that's a good idea. I've made those changes and included them in a new webrev, which you can find below.
>> http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.02/

LGTM.

-Chris.


From claes.redestad at oracle.com  Mon Apr  6 10:29:02 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 6 Apr 2020 12:29:02 +0200
Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for
 some cases (Was: Re: [NEW BUG] Small optimization in
 URLStreamHandler.parseURL)
In-Reply-To: <d4cbdcd7-25e7-7693-3d4b-cc8313646366@oracle.com>
References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de>
 <d4cbdcd7-25e7-7693-3d4b-cc8313646366@oracle.com>
Message-ID: <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com>

Hi,

(including  net-dev at .. since this is in java.net)

I intend to sponsor this trivial patch provided by Christoph:

diff -r 65b345254ca3 
src/java.base/share/classes/java/net/URLStreamHandler.java
--- a/src/java.base/share/classes/java/net/URLStreamHandler.java	Thu Apr 
02 05:44:04 2020 +0000
+++ b/src/java.base/share/classes/java/net/URLStreamHandler.java	Mon Apr 
06 12:27:09 2020 +0200
@@ -266,8 +266,8 @@
                           spec.substring(start, limit);

              } else {
-                String separator = (authority != null) ? "/" : "";
-                path = separator + spec.substring(start, limit);
+                path = spec.substring(start, limit);
+                path = (authority != null) ? "/" + path : path;
              }
          } else if (queryOnly && path != null) {
              int ind = path.lastIndexOf('/');


Bug: https://bugs.openjdk.java.net/browse/JDK-8242186

Let me know if there are any concerns, otherwise I'll push
once tier1 testing comes back green. Thanks!

/Claes

On 2020-04-05 19:48, Claes Redestad wrote:
> Hi Christoph,
> 
> looks good and trivial. I'll sponsor.
> 
> /Claes
> 
> On 2020-04-05 10:57, Christoph Dreis wrote:
>> Hi,
>>
>> I just noticed a small optimization opportunity in 
>> URLStreamHandler.parseURL for inputs like the following:
>>
>> ????new URL(new URL("file:"), "file:./path/to/some/local.properties");
>>
>> In those cases there is no authority involved, which makes it possible 
>> to rewrite URLStreamHandler:L269-270:
>> ???? String separator = (authority != null) ? "/" : "";
>> ???? path = separator + spec.substring(start, limit);
>>
>> into the following to avoid unnecessary string concatenations with an 
>> empty string:
>>
>> ????? path = spec.substring(start, limit);
>> ????? path = (authority != null) ? "/" + path : path;
>>
>> I've written a small benchmark with two URLStreamHandler variants (one 
>> with the old parseURL and one with the new):
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class MyBenchmark {
>>
>> ???? @State(Scope.Benchmark)
>> ???? public static class ThreadState {
>>
>> ???????? private URL context;
>> ???????? private URLStreamHandler newHandler = new NewURLStreamHandler();
>> ???????? private URLStreamHandler oldHandler = new OldURLStreamHandler();
>> ???????? private String spec = 
>> "file:./path/to/some/application.properties";
>>
>> ???????? public ThreadState() {
>> ???????????? try {
>> ???????????????? context = new URL("file:");
>> ???????????? } catch (MalformedURLException ignored) {
>>
>> ???????????? }
>> ???????? }
>> ???? }
>>
>> ???? @Benchmark
>> ???? public URL testNew(ThreadState threadState) throws 
>> MalformedURLException {
>> ???????? return new URL(threadState.context, threadState.spec, 
>> threadState.newHandler);
>> ???? }
>>
>> ???? @Benchmark
>> ???? public URL testOld(ThreadState threadState) throws 
>> MalformedURLException {
>> ???????? return new URL(threadState.context, threadState.spec, 
>> threadState.oldHandler);
>> ???? }
>>
>> }
>>
>> The benchmark above yields the following results on my local machine:
>>
>> Benchmark???????????????????????????????????????????? Mode? Cnt     
>> Score??? Error?? Units
>> MyBenchmark.testNew?????????????????????????????????? avgt?? 10   
>> 112,655 ?? 3,494?? ns/op
>> MyBenchmark.testNew:?gc.alloc.rate??????????????????? avgt?? 10  
>> 1299,558 ? 41,238? MB/sec
>> MyBenchmark.testNew:?gc.alloc.rate.norm?????????????? avgt?? 10   
>> 192,015 ?? 0,003??? B/op
>> MyBenchmark.testNew:?gc.count???????????????????????? avgt?? 10    
>> 98,000?????????? counts
>> MyBenchmark.testNew:?gc.time????????????????????????? avgt?? 10   
>> 105,000?????????????? ms
>> MyBenchmark.testOld?????????????????????????????????? avgt?? 10   
>> 128,592 ?? 1,183?? ns/op
>> MyBenchmark.testOld:?gc.alloc.rate??????????????????? avgt?? 10  
>> 1612,743 ? 15,792? MB/sec
>> MyBenchmark.testOld:?gc.alloc.rate.norm?????????????? avgt?? 10   
>> 272,019 ?? 0,001??? B/op
>> MyBenchmark.testOld:?gc.count???????????????????????? avgt?? 10   
>> 110,000?????????? counts
>> MyBenchmark.testOld:?gc.time????????????????????????? avgt?? 10   
>> 121,000?????????????? ms
>>
>>
>> In case you think this is worthwhile I would need someone to sponsor 
>> the attached patch for me.
>> I would highly appreciate that.
>>
>> Cheers,
>> Christoph
>>
>>
>> ===== PATCH =====
>> diff --git 
>> a/src/java.base/share/classes/java/net/URLStreamHandler.java 
>> b/src/java.base/share/classes/java/net/URLStreamHandler.java
>> --- a/src/java.base/share/classes/java/net/URLStreamHandler.java
>> +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java
>> @@ -266,8 +266,8 @@
>> ?????????????????????????? spec.substring(start, limit);
>>
>> ????????????? } else {
>> -??????????????? String separator = (authority != null) ? "/" : "";
>> -??????????????? path = separator + spec.substring(start, limit);
>> +??????????????? path = spec.substring(start, limit);
>> +??????????????? path = (authority != null) ? "/" + path : path;
>> ????????????? }
>> ????????? } else if (queryOnly && path != null) {
>> ????????????? int ind = path.lastIndexOf('/');
>>
>>

From chris.hegarty at oracle.com  Mon Apr  6 11:22:03 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 6 Apr 2020 12:22:03 +0100
Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for
 some cases (Was: Re: [NEW BUG] Small optimization in
 URLStreamHandler.parseURL)
In-Reply-To: <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com>
References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de>
 <d4cbdcd7-25e7-7693-3d4b-cc8313646366@oracle.com>
 <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com>
Message-ID: <BC066339-EEBD-49C4-A2B6-7D0281A93699@oracle.com>


> On 6 Apr 2020, at 11:29, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> (including  net-dev at .. since this is in java.net)
> 
> I intend to sponsor this trivial patch provided by Christoph:
> 
> diff -r 65b345254ca3 src/java.base/share/classes/java/net/URLStreamHandler.java
> --- a/src/java.base/share/classes/java/net/URLStreamHandler.java	Thu Apr 02 05:44:04 2020 +0000
> +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java	Mon Apr 06 12:27:09 2020 +0200
> @@ -266,8 +266,8 @@
>                          spec.substring(start, limit);
> 
>             } else {
> -                String separator = (authority != null) ? "/" : "";
> -                path = separator + spec.substring(start, limit);
> +                path = spec.substring(start, limit);
> +                path = (authority != null) ? "/" + path : path;
>             }
>         } else if (queryOnly && path != null) {
>             int ind = path.lastIndexOf('/');
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8242186
> 
> Let me know if there are any concerns, otherwise I'll push
> once tier1 testing comes back green. Thanks!

Thanks all for this nice micro-optimization. The changes look good to me.

-Chris.


> /Claes
> 
> On 2020-04-05 19:48, Claes Redestad wrote:
>> Hi Christoph,
>> looks good and trivial. I'll sponsor.
>> /Claes
>> On 2020-04-05 10:57, Christoph Dreis wrote:
>>> Hi,
>>> 
>>> I just noticed a small optimization opportunity in URLStreamHandler.parseURL for inputs like the following:
>>> 
>>>     new URL(new URL("file:"), "file:./path/to/some/local.properties");
>>> 
>>> In those cases there is no authority involved, which makes it possible to rewrite URLStreamHandler:L269-270:
>>>      String separator = (authority != null) ? "/" : "";
>>>      path = separator + spec.substring(start, limit);
>>> 
>>> into the following to avoid unnecessary string concatenations with an empty string:
>>> 
>>>       path = spec.substring(start, limit);
>>>       path = (authority != null) ? "/" + path : path;
>>> 
>>> I've written a small benchmark with two URLStreamHandler variants (one with the old parseURL and one with the new):
>>> 
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> public class MyBenchmark {
>>> 
>>>      @State(Scope.Benchmark)
>>>      public static class ThreadState {
>>> 
>>>          private URL context;
>>>          private URLStreamHandler newHandler = new NewURLStreamHandler();
>>>          private URLStreamHandler oldHandler = new OldURLStreamHandler();
>>>          private String spec = "file:./path/to/some/application.properties";
>>> 
>>>          public ThreadState() {
>>>              try {
>>>                  context = new URL("file:");
>>>              } catch (MalformedURLException ignored) {
>>> 
>>>              }
>>>          }
>>>      }
>>> 
>>>      @Benchmark
>>>      public URL testNew(ThreadState threadState) throws MalformedURLException {
>>>          return new URL(threadState.context, threadState.spec, threadState.newHandler);
>>>      }
>>> 
>>>      @Benchmark
>>>      public URL testOld(ThreadState threadState) throws MalformedURLException {
>>>          return new URL(threadState.context, threadState.spec, threadState.oldHandler);
>>>      }
>>> 
>>> }
>>> 
>>> The benchmark above yields the following results on my local machine:
>>> 
>>> Benchmark                                             Mode  Cnt     Score    Error   Units
>>> MyBenchmark.testNew                                   avgt   10   112,655 ?  3,494   ns/op
>>> MyBenchmark.testNew:?gc.alloc.rate                    avgt   10  1299,558 ? 41,238  MB/sec
>>> MyBenchmark.testNew:?gc.alloc.rate.norm               avgt   10   192,015 ?  0,003    B/op
>>> MyBenchmark.testNew:?gc.count                         avgt   10    98,000           counts
>>> MyBenchmark.testNew:?gc.time                          avgt   10   105,000               ms
>>> MyBenchmark.testOld                                   avgt   10   128,592 ?  1,183   ns/op
>>> MyBenchmark.testOld:?gc.alloc.rate                    avgt   10  1612,743 ? 15,792  MB/sec
>>> MyBenchmark.testOld:?gc.alloc.rate.norm               avgt   10   272,019 ?  0,001    B/op
>>> MyBenchmark.testOld:?gc.count                         avgt   10   110,000           counts
>>> MyBenchmark.testOld:?gc.time                          avgt   10   121,000               ms
>>> 
>>> 
>>> In case you think this is worthwhile I would need someone to sponsor the attached patch for me.
>>> I would highly appreciate that.
>>> 
>>> Cheers,
>>> Christoph
>>> 
>>> 
>>> ===== PATCH =====
>>> diff --git a/src/java.base/share/classes/java/net/URLStreamHandler.java b/src/java.base/share/classes/java/net/URLStreamHandler.java
>>> --- a/src/java.base/share/classes/java/net/URLStreamHandler.java
>>> +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java
>>> @@ -266,8 +266,8 @@
>>>                            spec.substring(start, limit);
>>> 
>>>               } else {
>>> -                String separator = (authority != null) ? "/" : "";
>>> -                path = separator + spec.substring(start, limit);
>>> +                path = spec.substring(start, limit);
>>> +                path = (authority != null) ? "/" + path : path;
>>>               }
>>>           } else if (queryOnly && path != null) {
>>>               int ind = path.lastIndexOf('/');
>>> 
>>> 


From claes.redestad at oracle.com  Mon Apr  6 11:26:49 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 6 Apr 2020 13:26:49 +0200
Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for
 some cases (Was: Re: [NEW BUG] Small optimization in
 URLStreamHandler.parseURL)
In-Reply-To: <BC066339-EEBD-49C4-A2B6-7D0281A93699@oracle.com>
References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de>
 <d4cbdcd7-25e7-7693-3d4b-cc8313646366@oracle.com>
 <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com>
 <BC066339-EEBD-49C4-A2B6-7D0281A93699@oracle.com>
Message-ID: <554bffd1-f023-6f79-3550-e8694fd3f9fd@oracle.com>



On 2020-04-06 13:22, Chris Hegarty wrote:
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8242186
>>
>> Let me know if there are any concerns, otherwise I'll push
>> once tier1 testing comes back green. Thanks!
> Thanks all for this nice micro-optimization. The changes look good to me.
> 
> -Chris.
> 

Thanks, Chris!

/Claes

From rahul.r.yadav at oracle.com  Wed Apr  8 09:13:44 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Wed, 08 Apr 2020 10:13:44 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
Message-ID: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>

Updated patch after considering the impact of returning default parameters on the http client.
TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
    
    Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
    Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
    
    Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
    
    -- Rahul

?On 27/03/2020, 16:23, "net-dev on behalf of Xuelei Fan" <net-dev-bounces at openjdk.java.net on behalf of xuelei.fan at oracle.com> wrote:

    On 3/27/2020 5:52 AM, Chris Hegarty wrote:
    > Xuelei,
    > 
    > Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
    > 
    > Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
    > 
    See the jdk.tls.client.protocols line in table 'Table 8-3 System 
    Properties and Customized Items" in JSSE Reference Guides:
    
    "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
    
    For your quick reference, I copied the note here:
    
    ---------------
    Customized Item:
    Default handshaking protocols for TLS/DTLS clients.
    
    Notes:
    To enable specific SunJSSE protocols on the client, specify them in a 
    comma-separated list within quotation marks; all other supported 
    protocols are not enabled on the client
    For example,
    
         If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default 
    protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while 
    SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
    
         If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting 
    on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
    ---------------
    
    
    > It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
    It is correct that the property impact the default SSLContext only.  The 
    default SSLContext instance could get from:
         SSLContext.getInstance("Default");
         SSLContext.getInstance("TLS");
         SSLContext.getInstance("DTLS");
    
    
    > and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
    Yes.
    
    Xuelei
    
    > -Chris.
    > 
    >> On 26 Mar 2020, at 16:58, Xuelei Fan <xuelei.fan at oracle.com> wrote:
    >>
    >> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead;  Otherwise, use TLSv1.3 and TLSv1.2.
    >>
    >> There may be a couple of issues:
    >> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
    >> For example:
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
    >>
    >> 2. TLSv1.2 may be not supported in the SSLContext.
    >> For example:
    >>    SSLContext context = SSLContext.getInstance("DTLS");
    >>    HttpClient.newBuilder().sslContext(context)...
    >>
    >> 3. The application may not want to use TLS 1.2.
    >> For example:
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
    >>
    >> The System property may be shared by code other than httpclient.  So the setting may not consider the impact on httpclient.
    >>
    >> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack.
    >>
    >> Xuelei
    >>
    >> On 3/26/2020 9:28 AM, Sean Mullan wrote:
    >>> Cross-posting to security-dev as this involves TLS/SSL configuration.
    >>> --Sean
    >>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
    >>>> Hello,
    >>>>
    >>>> Request to have my fix reviewed for issues:
    >>>>
    >>>>       JDK-8239595 : ssl context version is not respected
    >>>>       JDK-8239594 : jdk.tls.client.protocols is not respected
    >>>>
    >>>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
    >>>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(),
    >>>> as the latter does not respect the context parameters set by the user.
    >>>>
    >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
    >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
    >>>>
    >>>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
    >>>>
    >>>> -- Rahul
    > 
    



From chris.hegarty at oracle.com  Wed Apr  8 10:00:08 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Apr 2020 11:00:08 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
Message-ID: <62C88803-0F74-46D3-ADE0-84A69B3B0CC7@oracle.com>



> On 8 Apr 2020, at 10:13, Rahul <rahul.r.yadav at oracle.com> wrote:
> 
> Updated patch after considering the impact of returning default parameters on the http client.
> TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
> 
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
> 
>    Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/

Thanks for persevering with this. The changes and test look good to me.

-Chris.

From pavel.rappo at oracle.com  Wed Apr  8 11:50:33 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 12:50:33 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
Message-ID: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>

Vipin, here you go:

    https://bugs.openjdk.java.net/browse/JDK-8242366
    http://cr.openjdk.java.net/~prappo/8242366/webrev.00/

I took the liberty of additionally fixing a couple of parameters' names,
a typo, and `@exception` tags for checked exceptions that were neither thrown
nor imported.

The bulk of the change is in Security. Some changes are in Networking. The
appropriate mailing lists are in CC for this email. We should wait for their
feedback.

Changes in core area look good to me and I'd be surprised if there are any
problems with the remaining portion of the changeset.

-Pavel

> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
> Yes I have signed OCA.
>> 
>> -Pavel
>> 
>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>> [2] changeset:   58344:65f30e209890
>> user:        clanger
>> date:        Wed Mar 11 13:50:13 2020 +0100
>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>> description:
>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>> Reviewed-by: clanger, vtewari
>> Contributed-by: vipinsharma85 at gmail.com
>> 
> Yes this is my first contribution.
> 
> Patch text:
> 
> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -202,7 +202,7 @@
>     /**
>      * Sets the padding mechanism of this cipher.
>      *
> -     * @param padding the padding mechanism
> +     * @param paddingScheme the padding mechanism
>      *
>      * @exception NoSuchPaddingException if the requested padding mechanism
>      * does not exist
> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -313,10 +313,10 @@
>      * current Cipher.engineInit(...) implementation,
>      * IllegalStateException will always be thrown upon invocation.
>      *
> -     * @param in the input buffer
> -     * @param inOffset the offset in <code>in</code> where the input
> +     * @param input the input buffer
> +     * @param inputOffset the offset in <code>in</code> where the input
>      * starts
> -     * @param inLen the input length.
> +     * @param inputLen the input length.
>      *
>      * @return n/a.
>      *
> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -130,7 +130,6 @@
>      *
>      * @param plain the buffer with the input data to be encrypted
>      * @param plainOffset the offset in <code>plain</code>
> -     * @param plainLen the length of the input data
>      * @param cipher the buffer for the result
>      * @param cipherOffset the offset in <code>cipher</code>
>      */
> @@ -154,7 +153,6 @@
>      *
>      * @param cipher the buffer with the input data to be decrypted
>      * @param cipherOffset the offset in <code>cipherOffset</code>
> -     * @param cipherLen the length of the input data
>      * @param plain the buffer for the result
>      * @param plainOffset the offset in <code>plain</code>
>      */
> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -552,7 +552,6 @@
>      *
>      * @param plain the buffer with the input data to be encrypted
>      * @param plainOffset the offset in <code>plain</code>
> -     * @param plainLen the length of the input data
>      * @param cipher the buffer for the result
>      * @param cipherOffset the offset in <code>cipher</code>
>      *
> @@ -579,7 +578,6 @@
>      *
>      * @param cipher the buffer with the input data to be decrypted
>      * @param cipherOffset the offset in <code>cipherOffset</code>
> -     * @param cipherLen the length of the input data
>      * @param plain the buffer for the result
>      * @param plainOffset the offset in <code>plain</code>
>      *
> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -262,8 +262,6 @@
>      * @param algorithm the algorithm name
>      * @param key the key
>      * @param iv the iv
> -     * @param tagLenBytes the length of tag in bytes
> -     *
>      * @exception InvalidKeyException if the given key is inappropriate for
>      * initializing this cipher
>      */
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -225,7 +225,7 @@
>      *
>      * @param key the key
>      *
> -     * @param keySpec the requested format in which the key material shall be
> +     * @param keySpecCl the requested format in which the key material shall be
>      * returned
>      *
>      * @return the underlying key specification (key material) in the
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
> @@ -92,7 +92,7 @@
>      * Sets the padding mechanism of this cipher. This algorithm only uses
>      * PKCS #5 padding.
>      *
> -     * @param padding the padding mechanism
> +     * @param paddingScheme the padding mechanism
>      *
>      * @exception NoSuchPaddingException if the requested padding mechanism
>      * is invalid
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -75,7 +75,7 @@
>      *
>      * @param key the key
>      *
> -     * @param keySpec the requested format in which the key material shall be
> +     * @param keySpecCl the requested format in which the key material shall be
>      * returned
>      *
>      * @return the underlying key specification (key material) in the
> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -49,7 +49,7 @@
>      * interface.
>      *
>      * @param in the input buffer with the data to pad
> -     * @param the offset in <code>in</code> where the padding bytes
> +     * @param off the offset in <code>in</code> where the padding bytes
>      *  are appended
>      * @param len the number of padding bytes to add
>      *
> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
> @@ -1077,7 +1077,7 @@
>      * Start a new Process using an explicit array of redirects.
>      * See {@link #start} for details of starting each Process.
>      *
> -     * @param redirect array of redirects for stdin, stdout, stderr
> +     * @param redirects array of redirects for stdin, stdout, stderr
>      * @return the new Process
>      * @throws IOException if an I/O error occurs
>      */
> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
> @@ -731,7 +731,7 @@
>      * Constructs an empty GregorianCalendar.
>      *
>      * @param zone    the given time zone
> -     * @param aLocale the given locale
> +     * @param locale the given locale
>      * @param flag    the flag requesting an empty instance
>      */
>     GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -316,7 +316,7 @@
>      * If the address already has a scope-id or if the address is not local, ipv6
>      * or link local, then the original address is returned.
>      *
> -     * @param addr
> +     * @param address
>      * @exception SocketException if the given ipv6 link local address is found
>      *            on more than one local interface
>      * @return
> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -208,7 +208,7 @@
>      * Use New to get new HttpsClient. This constructor is meant to be
>      * used only by New method. New properly checks for URL spoofing.
>      *
> -     * @param URL https URL with which a connection must be established
> +     * @param url https URL with which a connection must be established
>      */
>     private HttpsClient(SSLSocketFactory sf, URL url)
>     throws IOException
> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
> @@ -321,7 +321,7 @@
>         /**
>          * Loads the provider with the specified class name.
>          *
> -         * @param name the name of the provider
> +         * @param pn the name of the provider
>          * @return the Provider, or null if it cannot be found or loaded
>          * @throws ProviderException all other exceptions are ignored
>          */
> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -72,7 +72,7 @@
>      * Constructor that initializes the input parameters.
>      *
>      * @param anchor the anchor selected to validate the target certificate
> -     * @param testDate the time for which the validity of the certificate
> +     * @param date the time for which the validity of the certificate
>      *        should be determined
>      * @param sigProvider the name of the signature provider
>      * @param sigOnly true if only signature checking is to be done;
> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -69,7 +69,7 @@
>     /**
>      * Initialize the builder with the input parameters.
>      *
> -     * @param params the parameter set used to build a certification path
> +     * @param buildParams the parameter set used to build a certification path
>      */
>     Builder(BuilderParams buildParams) {
>         this.buildParams = buildParams;
> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -111,7 +111,7 @@
>      * @param ruleFile       the name of the rule data file
>      * @param ruleData       the rule data loaded from the rule data file
>      * @param dictionaryFile the name of the dictionary file
> -     * @param dictionartData the dictionary data loaded from the dictionary file
> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>      * @throws MissingResourceException if rule data or dictionary initialization failed
>      */
>     public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
> 
> 
>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi David,
>>> 
>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>> Please suggest if there is any way I can create my user id to upload this patch.
>>> 
>>> This is ~300 line patch file. 
>>> 
>>> Regards,
>>> Vipin
>>> 
>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> Hi Vipin,
>>>> 
>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>> Hi,
>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>> code and Javadoc, need a sponsor for this patch.
>>>>> Webrev is available at
>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>> 
>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>> Regards,
>>>>> Vipin
>>> 
>> 
> Thanks,
> Vipin


From david.holmes at oracle.com  Wed Apr  8 12:56:06 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Apr 2020 22:56:06 +1000
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>

Hi Pavel,

Not a review ...

On 8/04/2020 9:50 pm, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.

While you are in there is it worth changing @exception to @throws? (I 
didn't look to see how big that change would be.)

Cheers,
David

> The bulk of the change is in Security. Some changes are in Networking. The
> appropriate mailing lists are in CC for this email. We should wait for their
> feedback.
> 
> Changes in core area look good to me and I'd be surprised if there are any
> problems with the remaining portion of the changeset.
> 
> -Pavel
> 
>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>
>> Hi Pavel,
>>
>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>
>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>> Yes I have signed OCA.
>>>
>>> -Pavel
>>>
>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>> [2] changeset:   58344:65f30e209890
>>> user:        clanger
>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>> description:
>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>> Reviewed-by: clanger, vtewari
>>> Contributed-by: vipinsharma85 at gmail.com
>>>
>> Yes this is my first contribution.
>>
>> Patch text:
>>
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -202,7 +202,7 @@
>>      /**
>>       * Sets the padding mechanism of this cipher.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * does not exist
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -313,10 +313,10 @@
>>       * current Cipher.engineInit(...) implementation,
>>       * IllegalStateException will always be thrown upon invocation.
>>       *
>> -     * @param in the input buffer
>> -     * @param inOffset the offset in <code>in</code> where the input
>> +     * @param input the input buffer
>> +     * @param inputOffset the offset in <code>in</code> where the input
>>       * starts
>> -     * @param inLen the input length.
>> +     * @param inputLen the input length.
>>       *
>>       * @return n/a.
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -130,7 +130,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       */
>> @@ -154,7 +153,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -552,7 +552,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       *
>> @@ -579,7 +578,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -262,8 +262,6 @@
>>       * @param algorithm the algorithm name
>>       * @param key the key
>>       * @param iv the iv
>> -     * @param tagLenBytes the length of tag in bytes
>> -     *
>>       * @exception InvalidKeyException if the given key is inappropriate for
>>       * initializing this cipher
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -225,7 +225,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>> @@ -92,7 +92,7 @@
>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>       * PKCS #5 padding.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * is invalid
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -75,7 +75,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -49,7 +49,7 @@
>>       * interface.
>>       *
>>       * @param in the input buffer with the data to pad
>> -     * @param the offset in <code>in</code> where the padding bytes
>> +     * @param off the offset in <code>in</code> where the padding bytes
>>       *  are appended
>>       * @param len the number of padding bytes to add
>>       *
>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>> @@ -1077,7 +1077,7 @@
>>       * Start a new Process using an explicit array of redirects.
>>       * See {@link #start} for details of starting each Process.
>>       *
>> -     * @param redirect array of redirects for stdin, stdout, stderr
>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>       * @return the new Process
>>       * @throws IOException if an I/O error occurs
>>       */
>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>> @@ -731,7 +731,7 @@
>>       * Constructs an empty GregorianCalendar.
>>       *
>>       * @param zone    the given time zone
>> -     * @param aLocale the given locale
>> +     * @param locale the given locale
>>       * @param flag    the flag requesting an empty instance
>>       */
>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -316,7 +316,7 @@
>>       * If the address already has a scope-id or if the address is not local, ipv6
>>       * or link local, then the original address is returned.
>>       *
>> -     * @param addr
>> +     * @param address
>>       * @exception SocketException if the given ipv6 link local address is found
>>       *            on more than one local interface
>>       * @return
>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -208,7 +208,7 @@
>>       * Use New to get new HttpsClient. This constructor is meant to be
>>       * used only by New method. New properly checks for URL spoofing.
>>       *
>> -     * @param URL https URL with which a connection must be established
>> +     * @param url https URL with which a connection must be established
>>       */
>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>      throws IOException
>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>> @@ -321,7 +321,7 @@
>>          /**
>>           * Loads the provider with the specified class name.
>>           *
>> -         * @param name the name of the provider
>> +         * @param pn the name of the provider
>>           * @return the Provider, or null if it cannot be found or loaded
>>           * @throws ProviderException all other exceptions are ignored
>>           */
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -72,7 +72,7 @@
>>       * Constructor that initializes the input parameters.
>>       *
>>       * @param anchor the anchor selected to validate the target certificate
>> -     * @param testDate the time for which the validity of the certificate
>> +     * @param date the time for which the validity of the certificate
>>       *        should be determined
>>       * @param sigProvider the name of the signature provider
>>       * @param sigOnly true if only signature checking is to be done;
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -69,7 +69,7 @@
>>      /**
>>       * Initialize the builder with the input parameters.
>>       *
>> -     * @param params the parameter set used to build a certification path
>> +     * @param buildParams the parameter set used to build a certification path
>>       */
>>      Builder(BuilderParams buildParams) {
>>          this.buildParams = buildParams;
>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -111,7 +111,7 @@
>>       * @param ruleFile       the name of the rule data file
>>       * @param ruleData       the rule data loaded from the rule data file
>>       * @param dictionaryFile the name of the dictionary file
>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>       */
>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>
>>
>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>
>>>> This is ~300 line patch file.
>>>>
>>>> Regards,
>>>> Vipin
>>>>
>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Vipin,
>>>>>
>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>> Hi,
>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>> Webrev is available at
>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>
>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>
>>>
>> Thanks,
>> Vipin
> 

From daniel.fuchs at oracle.com  Wed Apr  8 13:07:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 14:07:56 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
Message-ID: <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>

Hi Pavel,

On 08/04/2020 13:56, David Holmes wrote:
> and `@exception` tags for checked exceptions that were neither thrown
> nor imported

Hopefully that's only on internal classes.
It might be prudent to separate this out in a different
changeset. It's not always obvious where an exception
is thrown.

best regards,

-- daniel

From sean.mullan at oracle.com  Wed Apr  8 13:10:28 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 09:10:28 -0400
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <d8fd78aa-3250-5a71-cc8c-6723f5cd30ba@oracle.com>

The security changes look fine to me.

--Sean

On 4/8/20 7:50 AM, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.
> 
> The bulk of the change is in Security. Some changes are in Networking. The
> appropriate mailing lists are in CC for this email. We should wait for their
> feedback.
> 
> Changes in core area look good to me and I'd be surprised if there are any
> problems with the remaining portion of the changeset.
> 
> -Pavel
> 
>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>
>> Hi Pavel,
>>
>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>
>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>> Yes I have signed OCA.
>>>
>>> -Pavel
>>>
>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>> [2] changeset:   58344:65f30e209890
>>> user:        clanger
>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>> description:
>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>> Reviewed-by: clanger, vtewari
>>> Contributed-by: vipinsharma85 at gmail.com
>>>
>> Yes this is my first contribution.
>>
>> Patch text:
>>
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -202,7 +202,7 @@
>>      /**
>>       * Sets the padding mechanism of this cipher.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * does not exist
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -313,10 +313,10 @@
>>       * current Cipher.engineInit(...) implementation,
>>       * IllegalStateException will always be thrown upon invocation.
>>       *
>> -     * @param in the input buffer
>> -     * @param inOffset the offset in <code>in</code> where the input
>> +     * @param input the input buffer
>> +     * @param inputOffset the offset in <code>in</code> where the input
>>       * starts
>> -     * @param inLen the input length.
>> +     * @param inputLen the input length.
>>       *
>>       * @return n/a.
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -130,7 +130,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       */
>> @@ -154,7 +153,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -552,7 +552,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       *
>> @@ -579,7 +578,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -262,8 +262,6 @@
>>       * @param algorithm the algorithm name
>>       * @param key the key
>>       * @param iv the iv
>> -     * @param tagLenBytes the length of tag in bytes
>> -     *
>>       * @exception InvalidKeyException if the given key is inappropriate for
>>       * initializing this cipher
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -225,7 +225,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>> @@ -92,7 +92,7 @@
>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>       * PKCS #5 padding.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * is invalid
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -75,7 +75,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -49,7 +49,7 @@
>>       * interface.
>>       *
>>       * @param in the input buffer with the data to pad
>> -     * @param the offset in <code>in</code> where the padding bytes
>> +     * @param off the offset in <code>in</code> where the padding bytes
>>       *  are appended
>>       * @param len the number of padding bytes to add
>>       *
>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>> @@ -1077,7 +1077,7 @@
>>       * Start a new Process using an explicit array of redirects.
>>       * See {@link #start} for details of starting each Process.
>>       *
>> -     * @param redirect array of redirects for stdin, stdout, stderr
>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>       * @return the new Process
>>       * @throws IOException if an I/O error occurs
>>       */
>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>> @@ -731,7 +731,7 @@
>>       * Constructs an empty GregorianCalendar.
>>       *
>>       * @param zone    the given time zone
>> -     * @param aLocale the given locale
>> +     * @param locale the given locale
>>       * @param flag    the flag requesting an empty instance
>>       */
>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -316,7 +316,7 @@
>>       * If the address already has a scope-id or if the address is not local, ipv6
>>       * or link local, then the original address is returned.
>>       *
>> -     * @param addr
>> +     * @param address
>>       * @exception SocketException if the given ipv6 link local address is found
>>       *            on more than one local interface
>>       * @return
>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -208,7 +208,7 @@
>>       * Use New to get new HttpsClient. This constructor is meant to be
>>       * used only by New method. New properly checks for URL spoofing.
>>       *
>> -     * @param URL https URL with which a connection must be established
>> +     * @param url https URL with which a connection must be established
>>       */
>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>      throws IOException
>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>> @@ -321,7 +321,7 @@
>>          /**
>>           * Loads the provider with the specified class name.
>>           *
>> -         * @param name the name of the provider
>> +         * @param pn the name of the provider
>>           * @return the Provider, or null if it cannot be found or loaded
>>           * @throws ProviderException all other exceptions are ignored
>>           */
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -72,7 +72,7 @@
>>       * Constructor that initializes the input parameters.
>>       *
>>       * @param anchor the anchor selected to validate the target certificate
>> -     * @param testDate the time for which the validity of the certificate
>> +     * @param date the time for which the validity of the certificate
>>       *        should be determined
>>       * @param sigProvider the name of the signature provider
>>       * @param sigOnly true if only signature checking is to be done;
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -69,7 +69,7 @@
>>      /**
>>       * Initialize the builder with the input parameters.
>>       *
>> -     * @param params the parameter set used to build a certification path
>> +     * @param buildParams the parameter set used to build a certification path
>>       */
>>      Builder(BuilderParams buildParams) {
>>          this.buildParams = buildParams;
>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -111,7 +111,7 @@
>>       * @param ruleFile       the name of the rule data file
>>       * @param ruleData       the rule data loaded from the rule data file
>>       * @param dictionaryFile the name of the dictionary file
>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>       */
>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>
>>
>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>
>>>> This is ~300 line patch file.
>>>>
>>>> Regards,
>>>> Vipin
>>>>
>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Vipin,
>>>>>
>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>> Hi,
>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>> Webrev is available at
>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>
>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>
>>>
>> Thanks,
>> Vipin
> 

From Alan.Bateman at oracle.com  Wed Apr  8 13:14:51 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 Apr 2020 14:14:51 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
Message-ID: <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>

On 08/04/2020 14:07, Daniel Fuchs wrote:
> Hi Pavel,
>
> On 08/04/2020 13:56, David Holmes wrote:
>> and `@exception` tags for checked exceptions that were neither thrown
>> nor imported
>
> Hopefully that's only on internal classes.
 From a quick scan, the changes are to internal classes and a few 
non-public elements of public API classes. So I don't think anything 
should impact the javadoc. I'm guessing this patch is motivated by 
something creating that is running the javadoc tool with different 
options to what the "docs" target uses.

-Alan

From pavel.rappo at oracle.com  Wed Apr  8 13:23:40 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 14:23:40 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
Message-ID: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>

Hey David,

Where exactly? In the files affected by this changeset? If so, then we will
introduce inconsistency. Otherwise it's a huge change. From what I can see there
are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security}
and some 7,300 in src.

Personally, out of all tag renovations, changing `@exception` to `@throws`
probably gives the least bang for the buck. If nothing else, it gives you 3
extra characters on the same line to fill with something more useful.
I would be more inclined to change `<code>...</code>` to `{@code ...}`, but
given how error-prone that can be, I still wouldn't do it in this changeset.

-Pavel

> On 8 Apr 2020, at 13:56, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Pavel,
> 
> Not a review ...
> 
> On 8/04/2020 9:50 pm, Pavel Rappo wrote:
>> Vipin, here you go:
>>     https://bugs.openjdk.java.net/browse/JDK-8242366
>>     http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
>> I took the liberty of additionally fixing a couple of parameters' names,
>> a typo, and `@exception` tags for checked exceptions that were neither thrown
>> nor imported.
> 
> While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.)
> 
> Cheers,
> David
> 
>> The bulk of the change is in Security. Some changes are in Networking. The
>> appropriate mailing lists are in CC for this email. We should wait for their
>> feedback.
>> Changes in core area look good to me and I'd be surprised if there are any
>> problems with the remaining portion of the changeset.
>> -Pavel
>>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>>> Yes I have signed OCA.
>>>> 
>>>> -Pavel
>>>> 
>>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>>> [2] changeset:   58344:65f30e209890
>>>> user:        clanger
>>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>>> description:
>>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>>> Reviewed-by: clanger, vtewari
>>>> Contributed-by: vipinsharma85 at gmail.com
>>>> 
>>> Yes this is my first contribution.
>>> 
>>> Patch text:
>>> 
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -202,7 +202,7 @@
>>>     /**
>>>      * Sets the padding mechanism of this cipher.
>>>      *
>>> -     * @param padding the padding mechanism
>>> +     * @param paddingScheme the padding mechanism
>>>      *
>>>      * @exception NoSuchPaddingException if the requested padding mechanism
>>>      * does not exist
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -313,10 +313,10 @@
>>>      * current Cipher.engineInit(...) implementation,
>>>      * IllegalStateException will always be thrown upon invocation.
>>>      *
>>> -     * @param in the input buffer
>>> -     * @param inOffset the offset in <code>in</code> where the input
>>> +     * @param input the input buffer
>>> +     * @param inputOffset the offset in <code>in</code> where the input
>>>      * starts
>>> -     * @param inLen the input length.
>>> +     * @param inputLen the input length.
>>>      *
>>>      * @return n/a.
>>>      *
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -130,7 +130,6 @@
>>>      *
>>>      * @param plain the buffer with the input data to be encrypted
>>>      * @param plainOffset the offset in <code>plain</code>
>>> -     * @param plainLen the length of the input data
>>>      * @param cipher the buffer for the result
>>>      * @param cipherOffset the offset in <code>cipher</code>
>>>      */
>>> @@ -154,7 +153,6 @@
>>>      *
>>>      * @param cipher the buffer with the input data to be decrypted
>>>      * @param cipherOffset the offset in <code>cipherOffset</code>
>>> -     * @param cipherLen the length of the input data
>>>      * @param plain the buffer for the result
>>>      * @param plainOffset the offset in <code>plain</code>
>>>      */
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -552,7 +552,6 @@
>>>      *
>>>      * @param plain the buffer with the input data to be encrypted
>>>      * @param plainOffset the offset in <code>plain</code>
>>> -     * @param plainLen the length of the input data
>>>      * @param cipher the buffer for the result
>>>      * @param cipherOffset the offset in <code>cipher</code>
>>>      *
>>> @@ -579,7 +578,6 @@
>>>      *
>>>      * @param cipher the buffer with the input data to be decrypted
>>>      * @param cipherOffset the offset in <code>cipherOffset</code>
>>> -     * @param cipherLen the length of the input data
>>>      * @param plain the buffer for the result
>>>      * @param plainOffset the offset in <code>plain</code>
>>>      *
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -262,8 +262,6 @@
>>>      * @param algorithm the algorithm name
>>>      * @param key the key
>>>      * @param iv the iv
>>> -     * @param tagLenBytes the length of tag in bytes
>>> -     *
>>>      * @exception InvalidKeyException if the given key is inappropriate for
>>>      * initializing this cipher
>>>      */
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -225,7 +225,7 @@
>>>      *
>>>      * @param key the key
>>>      *
>>> -     * @param keySpec the requested format in which the key material shall be
>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>      * returned
>>>      *
>>>      * @return the underlying key specification (key material) in the
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>>> @@ -92,7 +92,7 @@
>>>      * Sets the padding mechanism of this cipher. This algorithm only uses
>>>      * PKCS #5 padding.
>>>      *
>>> -     * @param padding the padding mechanism
>>> +     * @param paddingScheme the padding mechanism
>>>      *
>>>      * @exception NoSuchPaddingException if the requested padding mechanism
>>>      * is invalid
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -75,7 +75,7 @@
>>>      *
>>>      * @param key the key
>>>      *
>>> -     * @param keySpec the requested format in which the key material shall be
>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>      * returned
>>>      *
>>>      * @return the underlying key specification (key material) in the
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -49,7 +49,7 @@
>>>      * interface.
>>>      *
>>>      * @param in the input buffer with the data to pad
>>> -     * @param the offset in <code>in</code> where the padding bytes
>>> +     * @param off the offset in <code>in</code> where the padding bytes
>>>      *  are appended
>>>      * @param len the number of padding bytes to add
>>>      *
>>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>>> @@ -1077,7 +1077,7 @@
>>>      * Start a new Process using an explicit array of redirects.
>>>      * See {@link #start} for details of starting each Process.
>>>      *
>>> -     * @param redirect array of redirects for stdin, stdout, stderr
>>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>>      * @return the new Process
>>>      * @throws IOException if an I/O error occurs
>>>      */
>>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>>> @@ -731,7 +731,7 @@
>>>      * Constructs an empty GregorianCalendar.
>>>      *
>>>      * @param zone    the given time zone
>>> -     * @param aLocale the given locale
>>> +     * @param locale the given locale
>>>      * @param flag    the flag requesting an empty instance
>>>      */
>>>     GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -316,7 +316,7 @@
>>>      * If the address already has a scope-id or if the address is not local, ipv6
>>>      * or link local, then the original address is returned.
>>>      *
>>> -     * @param addr
>>> +     * @param address
>>>      * @exception SocketException if the given ipv6 link local address is found
>>>      *            on more than one local interface
>>>      * @return
>>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -208,7 +208,7 @@
>>>      * Use New to get new HttpsClient. This constructor is meant to be
>>>      * used only by New method. New properly checks for URL spoofing.
>>>      *
>>> -     * @param URL https URL with which a connection must be established
>>> +     * @param url https URL with which a connection must be established
>>>      */
>>>     private HttpsClient(SSLSocketFactory sf, URL url)
>>>     throws IOException
>>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>>> @@ -321,7 +321,7 @@
>>>         /**
>>>          * Loads the provider with the specified class name.
>>>          *
>>> -         * @param name the name of the provider
>>> +         * @param pn the name of the provider
>>>          * @return the Provider, or null if it cannot be found or loaded
>>>          * @throws ProviderException all other exceptions are ignored
>>>          */
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -72,7 +72,7 @@
>>>      * Constructor that initializes the input parameters.
>>>      *
>>>      * @param anchor the anchor selected to validate the target certificate
>>> -     * @param testDate the time for which the validity of the certificate
>>> +     * @param date the time for which the validity of the certificate
>>>      *        should be determined
>>>      * @param sigProvider the name of the signature provider
>>>      * @param sigOnly true if only signature checking is to be done;
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -69,7 +69,7 @@
>>>     /**
>>>      * Initialize the builder with the input parameters.
>>>      *
>>> -     * @param params the parameter set used to build a certification path
>>> +     * @param buildParams the parameter set used to build a certification path
>>>      */
>>>     Builder(BuilderParams buildParams) {
>>>         this.buildParams = buildParams;
>>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -111,7 +111,7 @@
>>>      * @param ruleFile       the name of the rule data file
>>>      * @param ruleData       the rule data loaded from the rule data file
>>>      * @param dictionaryFile the name of the dictionary file
>>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>>      * @throws MissingResourceException if rule data or dictionary initialization failed
>>>      */
>>>     public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>> 
>>> 
>>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>> 
>>>>> This is ~300 line patch file.
>>>>> 
>>>>> Regards,
>>>>> Vipin
>>>>> 
>>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Vipin,
>>>>>> 
>>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>>> Hi,
>>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>>> Webrev is available at
>>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>> 
>>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>>> Regards,
>>>>>>> Vipin
>>>>> 
>>>> 
>>> Thanks,
>>> Vipin


From pavel.rappo at oracle.com  Wed Apr  8 13:27:28 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 14:27:28 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
Message-ID: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>

Why assume something that sophisticated where it can be adequately explained by
a simpler thing? :) I bet it was an IDE inspection.

-Pavel

> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/04/2020 14:07, Daniel Fuchs wrote:
>> Hi Pavel,
>> 
>> On 08/04/2020 13:56, David Holmes wrote:
>>> and `@exception` tags for checked exceptions that were neither thrown
>>> nor imported
>> 
>> Hopefully that's only on internal classes.
> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
> 
> -Alan


From daniel.fuchs at oracle.com  Wed Apr  8 14:37:14 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 15:37:14 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <3189b9da-c9e7-dae5-6869-b130783d7884@oracle.com>

On 08/04/2020 12:50, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/

Hi Pavel,

That looks good to me.
WRT to the @exception changes I'll leave that responsibility
to Sean ;-)

best regards,

-- daniel


> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.


From daniel.fuchs at oracle.com  Wed Apr  8 15:00:37 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 16:00:37 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
Message-ID: <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>

Good work Rahul!

I am not sure whether that deserves a CSR (probably not) but we may
want to create some release note to explain that the HttpClient is no
longer overriding the default protocols selected by the SSLContext.

So HTTP 1.1 over TLSv1.1 might now get negotiated where previously
an handshake failure would have occurred. It might be worth mentioning
in a release note.

best regards,

-- daniel

On 08/04/2020 10:13, Rahul wrote:
> Updated patch after considering the impact of returning default parameters on the http client.
> TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
>      
>      Issue:https://bugs.openjdk.java.net/browse/JDK-8239595
>      Issue:https://bugs.openjdk.java.net/browse/JDK-8239594
>      
>      Webrev:http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
>      
>      -- Rahul


From vipinsharma85 at gmail.com  Wed Apr  8 16:35:34 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Wed, 8 Apr 2020 22:05:34 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
Message-ID: <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>



> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Why assume something that sophisticated where it can be adequately explained by
> a simpler thing? :) I bet it was an IDE inspection.
> 
> -Pavel

Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?

> 
>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>> Hi Pavel,
>>> 
>>> On 08/04/2020 13:56, David Holmes wrote:
>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>> nor imported
>>> 
>>> Hopefully that's only on internal classes.
>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>> 
>> -Alan
> 

Regards,
Vipin

From pavel.rappo at oracle.com  Wed Apr  8 21:15:51 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 22:15:51 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
Message-ID: <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>

If your new patch addresses a similar type of problem, please send it in reply to this email,
so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.

> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> 
> 
>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> Why assume something that sophisticated where it can be adequately explained by
>> a simpler thing? :) I bet it was an IDE inspection.
>> 
>> -Pavel
> 
> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
> 
>> 
>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>> Hi Pavel,
>>>> 
>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>> nor imported
>>>> 
>>>> Hopefully that's only on internal classes.
>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>> 
>>> -Alan
>> 
> 
> Regards,
> Vipin


From david.holmes at oracle.com  Thu Apr  9 00:16:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Apr 2020 10:16:45 +1000
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>
Message-ID: <6111470b-2fc5-2dc0-2b67-3e93ccc03f41@oracle.com>

Hi Pavel,

On 8/04/2020 11:23 pm, Pavel Rappo wrote:
> Hey David,
> 
> Where exactly? In the files affected by this changeset? If so, then we will
> introduce inconsistency. Otherwise it's a huge change. From what I can see there
> are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security}
> and some 7,300 in src.

Okay as I said I didn't examine in detail to see the size of the change 
- and its obviously too big.

> Personally, out of all tag renovations, changing `@exception` to `@throws`
> probably gives the least bang for the buck. If nothing else, it gives you 3
> extra characters on the same line to fill with something more useful.

There was an effort to do this conversion a while back, at least while 
touching affected files. It's not a big deal to me.

Cheers,
David

> I would be more inclined to change `<code>...</code>` to `{@code ...}`, but
> given how error-prone that can be, I still wouldn't do it in this changeset.
> 
> -Pavel
> 
>> On 8 Apr 2020, at 13:56, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> Not a review ...
>>
>> On 8/04/2020 9:50 pm, Pavel Rappo wrote:
>>> Vipin, here you go:
>>>      https://bugs.openjdk.java.net/browse/JDK-8242366
>>>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
>>> I took the liberty of additionally fixing a couple of parameters' names,
>>> a typo, and `@exception` tags for checked exceptions that were neither thrown
>>> nor imported.
>>
>> While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.)
>>
>> Cheers,
>> David
>>
>>> The bulk of the change is in Security. Some changes are in Networking. The
>>> appropriate mailing lists are in CC for this email. We should wait for their
>>> feedback.
>>> Changes in core area look good to me and I'd be surprised if there are any
>>> problems with the remaining portion of the changeset.
>>> -Pavel
>>>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>
>>>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>>>> Yes I have signed OCA.
>>>>>
>>>>> -Pavel
>>>>>
>>>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>>>> [2] changeset:   58344:65f30e209890
>>>>> user:        clanger
>>>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>>>> description:
>>>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>>>> Reviewed-by: clanger, vtewari
>>>>> Contributed-by: vipinsharma85 at gmail.com
>>>>>
>>>> Yes this is my first contribution.
>>>>
>>>> Patch text:
>>>>
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -202,7 +202,7 @@
>>>>      /**
>>>>       * Sets the padding mechanism of this cipher.
>>>>       *
>>>> -     * @param padding the padding mechanism
>>>> +     * @param paddingScheme the padding mechanism
>>>>       *
>>>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>>>       * does not exist
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -313,10 +313,10 @@
>>>>       * current Cipher.engineInit(...) implementation,
>>>>       * IllegalStateException will always be thrown upon invocation.
>>>>       *
>>>> -     * @param in the input buffer
>>>> -     * @param inOffset the offset in <code>in</code> where the input
>>>> +     * @param input the input buffer
>>>> +     * @param inputOffset the offset in <code>in</code> where the input
>>>>       * starts
>>>> -     * @param inLen the input length.
>>>> +     * @param inputLen the input length.
>>>>       *
>>>>       * @return n/a.
>>>>       *
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -130,7 +130,6 @@
>>>>       *
>>>>       * @param plain the buffer with the input data to be encrypted
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>> -     * @param plainLen the length of the input data
>>>>       * @param cipher the buffer for the result
>>>>       * @param cipherOffset the offset in <code>cipher</code>
>>>>       */
>>>> @@ -154,7 +153,6 @@
>>>>       *
>>>>       * @param cipher the buffer with the input data to be decrypted
>>>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>>>> -     * @param cipherLen the length of the input data
>>>>       * @param plain the buffer for the result
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>>       */
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -552,7 +552,6 @@
>>>>       *
>>>>       * @param plain the buffer with the input data to be encrypted
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>> -     * @param plainLen the length of the input data
>>>>       * @param cipher the buffer for the result
>>>>       * @param cipherOffset the offset in <code>cipher</code>
>>>>       *
>>>> @@ -579,7 +578,6 @@
>>>>       *
>>>>       * @param cipher the buffer with the input data to be decrypted
>>>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>>>> -     * @param cipherLen the length of the input data
>>>>       * @param plain the buffer for the result
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>>       *
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -262,8 +262,6 @@
>>>>       * @param algorithm the algorithm name
>>>>       * @param key the key
>>>>       * @param iv the iv
>>>> -     * @param tagLenBytes the length of tag in bytes
>>>> -     *
>>>>       * @exception InvalidKeyException if the given key is inappropriate for
>>>>       * initializing this cipher
>>>>       */
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -225,7 +225,7 @@
>>>>       *
>>>>       * @param key the key
>>>>       *
>>>> -     * @param keySpec the requested format in which the key material shall be
>>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>>       * returned
>>>>       *
>>>>       * @return the underlying key specification (key material) in the
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>>>> @@ -92,7 +92,7 @@
>>>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>>>       * PKCS #5 padding.
>>>>       *
>>>> -     * @param padding the padding mechanism
>>>> +     * @param paddingScheme the padding mechanism
>>>>       *
>>>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>>>       * is invalid
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -75,7 +75,7 @@
>>>>       *
>>>>       * @param key the key
>>>>       *
>>>> -     * @param keySpec the requested format in which the key material shall be
>>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>>       * returned
>>>>       *
>>>>       * @return the underlying key specification (key material) in the
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -49,7 +49,7 @@
>>>>       * interface.
>>>>       *
>>>>       * @param in the input buffer with the data to pad
>>>> -     * @param the offset in <code>in</code> where the padding bytes
>>>> +     * @param off the offset in <code>in</code> where the padding bytes
>>>>       *  are appended
>>>>       * @param len the number of padding bytes to add
>>>>       *
>>>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>>>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>>>> @@ -1077,7 +1077,7 @@
>>>>       * Start a new Process using an explicit array of redirects.
>>>>       * See {@link #start} for details of starting each Process.
>>>>       *
>>>> -     * @param redirect array of redirects for stdin, stdout, stderr
>>>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>>>       * @return the new Process
>>>>       * @throws IOException if an I/O error occurs
>>>>       */
>>>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>>>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>>>> @@ -731,7 +731,7 @@
>>>>       * Constructs an empty GregorianCalendar.
>>>>       *
>>>>       * @param zone    the given time zone
>>>> -     * @param aLocale the given locale
>>>> +     * @param locale the given locale
>>>>       * @param flag    the flag requesting an empty instance
>>>>       */
>>>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>>>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>>>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -316,7 +316,7 @@
>>>>       * If the address already has a scope-id or if the address is not local, ipv6
>>>>       * or link local, then the original address is returned.
>>>>       *
>>>> -     * @param addr
>>>> +     * @param address
>>>>       * @exception SocketException if the given ipv6 link local address is found
>>>>       *            on more than one local interface
>>>>       * @return
>>>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>>>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -208,7 +208,7 @@
>>>>       * Use New to get new HttpsClient. This constructor is meant to be
>>>>       * used only by New method. New properly checks for URL spoofing.
>>>>       *
>>>> -     * @param URL https URL with which a connection must be established
>>>> +     * @param url https URL with which a connection must be established
>>>>       */
>>>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>>>      throws IOException
>>>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>>>> @@ -321,7 +321,7 @@
>>>>          /**
>>>>           * Loads the provider with the specified class name.
>>>>           *
>>>> -         * @param name the name of the provider
>>>> +         * @param pn the name of the provider
>>>>           * @return the Provider, or null if it cannot be found or loaded
>>>>           * @throws ProviderException all other exceptions are ignored
>>>>           */
>>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -72,7 +72,7 @@
>>>>       * Constructor that initializes the input parameters.
>>>>       *
>>>>       * @param anchor the anchor selected to validate the target certificate
>>>> -     * @param testDate the time for which the validity of the certificate
>>>> +     * @param date the time for which the validity of the certificate
>>>>       *        should be determined
>>>>       * @param sigProvider the name of the signature provider
>>>>       * @param sigOnly true if only signature checking is to be done;
>>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -69,7 +69,7 @@
>>>>      /**
>>>>       * Initialize the builder with the input parameters.
>>>>       *
>>>> -     * @param params the parameter set used to build a certification path
>>>> +     * @param buildParams the parameter set used to build a certification path
>>>>       */
>>>>      Builder(BuilderParams buildParams) {
>>>>          this.buildParams = buildParams;
>>>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>>>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -111,7 +111,7 @@
>>>>       * @param ruleFile       the name of the rule data file
>>>>       * @param ruleData       the rule data loaded from the rule data file
>>>>       * @param dictionaryFile the name of the dictionary file
>>>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>>>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>>>       */
>>>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>>>
>>>>
>>>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>>>
>>>>>> This is ~300 line patch file.
>>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>>>
>>>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Vipin,
>>>>>>>
>>>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>>>> Hi,
>>>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>>>> Webrev is available at
>>>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>>>
>>>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Vipin
>>>>>>
>>>>>
>>>> Thanks,
>>>> Vipin
> 

From patrick.concannon at oracle.com  Thu Apr  9 11:26:41 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 9 Apr 2020 12:26:41 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
Message-ID: <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>

Hi,

Alan - I've gone through your comments and refactored the code 
accordingly. I spoke with Daniel about the SendBufCheck test, and he 
wants to keep this in the JEP as it allows to compare the behavior of 
all the different implementations in one place.

Chris - Thanks for opening issue JDK-8241988 
<https://bugs.openjdk.java.net/browse/JDK-8241988> and looking after it. 
I've incorporated the other changes you requested into the new webrev 
below.

I've also updated several tests and included an additional test to 
increase the test coverage for both the old and new implementations of 
DatagramSocket.


webrev: http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.03/


Kind regards,

Patrick


On 01/04/2020 12:03, Chris Hegarty wrote:
>
>> On 31 Mar 2020, at 18:46, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> On 31/03/2020 18:27, Chris Hegarty wrote:
>>> :
>>> - In DatagramSocket::createDelegate, "enable broadcast if possible? 
>>> - Possibly due to refactoring, but I cannot reconcile this with the 
>>> old implementation.
>> DatagramSocket is specified to make a best attempt to enable this 
>> option so I think it's in the right place. At a clean-up, the attempt 
>> in PDSI.datagramSocketCreate could be removed.
>
> Ok, that explains why it was difficult to reconcile in the webrev.
>
> I now see that ?best-effort? is not implemented on unix platforms, but 
> rather fail-fast ( an exception is thrown if the option cannot be set 
> ). Let?s just remove this now superfluous native code as it is confusing.
>
>>> :
>>>
>>> - The set of socket options is now per datagram/multicast socket 
>>> instance, rather than on the class of the socket. I don?t think that 
>>> this is an issue, just an observation and a confirmation that it is 
>>> deliberate.
>> The set of socket options supported by a custom DSI will likely be 
>> different to the default impl so it needs to be an instance field. I 
>> suspect this is a long standing bug.
>
> Since this issue is orthogonal to the JEP, I filed the following issue 
> to track it:
> https://bugs.openjdk.java.net/browse/JDK-8241988
>
> -Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200409/5f23f81d/attachment.htm>

From rahul.r.yadav at oracle.com  Thu Apr  9 13:13:14 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Thu, 09 Apr 2020 14:13:14 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
 <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
Message-ID: <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>

Thanks for the review Daniel.
 I have created a release note.

    RN : https://bugs.openjdk.java.net/browse/JDK-8242387

--Rahul

?On 08/04/2020, 16:00, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:

    Good work Rahul!
    
    I am not sure whether that deserves a CSR (probably not) but we may
    want to create some release note to explain that the HttpClient is no
    longer overriding the default protocols selected by the SSLContext.
    
    So HTTP 1.1 over TLSv1.1 might now get negotiated where previously
    an handshake failure would have occurred. It might be worth mentioning
    in a release note.
    
    best regards,
    
    -- daniel
    
    On 08/04/2020 10:13, Rahul wrote:
    > Updated patch after considering the impact of returning default parameters on the http client.
    > TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
    >      
    >      Issue:https://bugs.openjdk.java.net/browse/JDK-8239595
    >      Issue:https://bugs.openjdk.java.net/browse/JDK-8239594
    >      
    >      Webrev:http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
    >      
    >      -- Rahul
    
    



From daniel.fuchs at oracle.com  Thu Apr  9 16:16:40 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Apr 2020 17:16:40 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
 <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
 <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>
Message-ID: <ea179f0b-47b7-f35a-273d-34406e2e251f@oracle.com>

Thanks Rahul. I believe you can mark it as Delivered now.

On 09/04/2020 14:13, Rahul wrote:
> Thanks for the review Daniel.
>   I have created a release note.
> 
>      RN :https://bugs.openjdk.java.net/browse/JDK-8242387


From patrick.concannon at oracle.com  Fri Apr 10 10:16:16 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 10 Apr 2020 11:16:16 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what
 happens if address or port are not set'
Message-ID: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>

Hi,

Could someone please review my webrev and CSR for JDK-8237890 
'DatagramPacket::getSocketAddress doesn't specify what happens if 
address or port are not set' ?

DatagramPacket::getSocketAddress is misleading in that it can throw an 
IllegalArgumentException even though it doesn't take any arguments. This 
can occur if the port of a DatagramPacket is not set before a call to 
getSocketAddress is made.

In the recent fixJDK-8236940 
<https://bugs.openjdk.java.net/browse/JDK-8236940>, additional checks 
were addedto ensure DatagramPacket cannot besent to port 0. Following on 
from this update,the current fix changes the default port of a 
DatagramPacket from -1 to 0. An IllegalArgumentException will therefore 
no longer be thrown when getSocketAddress with no port set. Instead, an 
InetSocketAddress representing any local address with port 0 is returned.


bug: https://bugs.openjdk.java.net/browse/JDK-8237890
csr: https://bugs.openjdk.java.net/browse/JDK-8242483
webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.00/



Kind regards,

Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200410/bcf12ec0/attachment.htm>

From Alan.Bateman at oracle.com  Fri Apr 10 12:28:44 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 10 Apr 2020 13:28:44 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
Message-ID: <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>



On 10/04/2020 11:16, Patrick Concannon wrote:
>
> Hi,
>
> Could someone please review my webrev and CSR for JDK-8237890 
> 'DatagramPacket::getSocketAddress doesn't specify what happens if 
> address or port are not set' ?
>
> DatagramPacket::getSocketAddress is misleading in that it can throw an 
> IllegalArgumentException even though it doesn't take any arguments. 
> This can occur if the port of a DatagramPacket is not set before a 
> call to getSocketAddress is made.
>
> In the recent fixJDK-8236940 
> <https://bugs.openjdk.java.net/browse/JDK-8236940>, additional checks 
> were addedto ensure DatagramPacket cannot besent to port 0. Following 
> on from this update,the current fix changes the default port of a 
> DatagramPacket from -1 to 0. An IllegalArgumentException will 
> therefore no longer be thrown when getSocketAddress with no port set. 
> Instead, an InetSocketAddress representing any local address with port 
> 0 is returned.
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8237890
> csr: https://bugs.openjdk.java.net/browse/JDK-8242483
> webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.00/
>
The default value for address and port are null and 0 (resp.) so you 
could just remove L93-94.

In the getSocketAddress() spec it might be better to say "Returns" 
rather than "Gets" so that its consistent with the getAddress and 
getPort methods.

Can you look at DatagramSocketAdaptor L202 where the comment is "throws 
IAE if port not set". I assume that comment should be removed.

Do we need to re-visit or withdraw the release note JDK-8237530 as IAE 
is there is no longer a "port out of range" condition?

-Alan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200410/d0939fcd/attachment.htm>

From macanaoire at hotmail.com  Fri Apr 10 21:53:44 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Fri, 10 Apr 2020 21:53:44 +0000
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
Message-ID: <DBBPR09MB30141E2BE0E34BA4B777287ADFDE0@DBBPR09MB3014.eurprd09.prod.outlook.com>


Hi Patrick,
    if I understand the change correctly, you wish to eliminate the IllegalArgumentException and return an InetSocketAddress
based on the current set values for address and port. Because you have changed the default value of the port to 0, the getSocketAddress
will now return a SocketAddress with a wildcard address (assuming that address has not yet been set) and an ephemeral port, rather than the Exception caused by the port == -1.  Calling new InetSocketAddress(null, 0) will mean a wildcard address and an ephemeral port.
Port 0 is reserved for system selection of ephemeral port.  Thus, I think this change is now introducing some dubious semantics ?
Additionally if you were to call getSocketAddress multiple times you would get different non equal SocketAdress objects i.e. each one would have a different ephemeral port.

A possible approach is that an invocation of getSocketAddress should return null if the address or the port is not set, OR alternatively throw an IllegalStateException with either "port not set" or "address not set", as the DatagramPacket is in an unusable state for sending and the remote address is not set?

If we look at DatagramSocket::send() method , I suspect that there is another side effect to your change the check


                if (packetPort < 0 || packetPort > 0xFFFF)<https://hg.openjdk.java.net/jdk/jdk/rev/67e7f7e8284a#l1.22>
                    throw new IllegalArgumentException("port out of range:" + packetPort);

will allow a DatagramPacket with port == 0  to continue its porcessing. But sending to port 0 is not allowed afaik
so should this be:
      if (packetPort <= 0 || packetPort > 0xFFFF)
          throw new IllegalArgumentException("port out of range: " + packetPort);

regards
Mark


________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Patrick Concannon <patrick.concannon at oracle.com>
Sent: Friday 10 April 2020 10:16
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'


Hi,

Could someone please review my webrev and CSR for JDK-8237890 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set' ?

DatagramPacket::getSocketAddress is misleading in that it can throw an IllegalArgumentException even though it doesn't take any arguments. This can occur if the port of a DatagramPacket is not set before a call to getSocketAddress is made.

In the recent fix JDK-8236940<https://bugs.openjdk.java.net/browse/JDK-8236940>, additional checks were added to ensure DatagramPacket cannot be sent to port 0. Following on from this update, the current fix changes the default port of a DatagramPacket from -1 to 0. An IllegalArgumentException will therefore no longer be thrown when getSocketAddress with no port set. Instead, an InetSocketAddress representing any local address with port 0 is returned.

bug: https://bugs.openjdk.java.net/browse/JDK-8237890
csr: https://bugs.openjdk.java.net/browse/JDK-8242483
webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.00/



Kind regards,

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200410/9d7d08c7/attachment.htm>

From Alan.Bateman at oracle.com  Sat Apr 11 07:54:08 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 11 Apr 2020 08:54:08 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <DBBPR09MB30141E2BE0E34BA4B777287ADFDE0@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <DBBPR09MB30141E2BE0E34BA4B777287ADFDE0@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <6550edb0-97a8-b0be-b787-9ad7a575e7fa@oracle.com>

On 10/04/2020 22:53, mark sheppard wrote:
>
> Hi Patrick,
> ? ? if I understand the change correctly, you wish to eliminate the 
> IllegalArgumentException and return an InetSocketAddress
> based on the current set values for address and port.
Yes, it is surprising to have it throw an undocumented IAE as there are 
no arguments. It is compounded by a long standing undocumented behavior 
to initialize the port to -1. Navigating through historical mistakes is 
always tricky. Patrick, Daniel, and I discussed several options around 
this and I think Patrick's proposal is the best of a bad hand in that it 
minimizes the compatibility impact and consistency issues that rise when 
changing old APIs. Changing getSocketAddress() to return null would be a 
hazard. IllegalStateException should have been looked at in 1.4 but 
awkward/too-late to change it now. One other thing is that this change 
connects to possible future changes to DatagramSocket and 
DatagramChannel to allow sending (and maybe connect) to the wildcard 
address. Socket and SocketChannel have always converted attempts to 
connect to the wildcard address to an attempt to connect to the host or 
loopback address. This makes it easy for newbies and tests to connect to 
a listener's socket address without needing to special case the wildcard 
address. An equivalent for Datagram is something that I think Daniel and 
Patrick are thinking about.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200411/5d6f9995/attachment-0001.htm>

From Alan.Bateman at oracle.com  Sun Apr 12 15:51:50 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 12 Apr 2020 16:51:50 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
 <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
Message-ID: <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>

On 09/04/2020 12:26, Patrick Concannon wrote:
>
> Hi,
>
> Alan - I've gone through your comments and refactored the code 
> accordingly.
>
Just a few minor comments on the implementation changes.

DatagramSocket.java
- this version of the webrev has a block comment "A global switch ..." 
that looks like it was added in the wrong place. I assume it can be 
removed or a subset of the text moved into the command for createDelegate
- toSocketException can be private
- the comment on the delegate field could be shortened by dropping 
"`delegate` can be". That is, it would be a clearer for readers to just 
say "any instance ..."
- Another minor nit but the comment on the delegate() method could 
confuse readers. I think you can drop it or just say that it can be 
overridden to return a MulticastSocket.
- The? new // comments added to the asserts at L133-136 aren't useful, I 
suggest just drop them as the asserts are clear as they are.

DatagramSocketAdaptor
- this version has re-formatted existing code in several places. Can you 
undo these changes (I can't tell if they were deliberate or the IDE did 
it). The only changes should be to be super call and the addition of the 
DatagramSockets helper class.

MulticastSocket and NetMulticastSocket look good.

> I spoke with Daniel about the SendBufCheck test, and he wants to keep 
> this in the JEP as it allows to compare the behavior of all the 
> different implementations in one place.
>
I don't think SetGetSendBufferSize should be in the webrev. It has @bug 
8239355 so it's for a different issue.

I also don't think SendBufCheck should be in the webrev (btw: it also 
has @bug 8239355). The underlying issue is that PDSI doesn't allow 
sending IPv6 datagrams on macOS of size 65508-65527 (inclusive) bytes 
without changing the default value of SO_SNDBUF. It's not an interesting 
issue of course but I don't think the tests for the JEP should be adding 
a test to make sure that the old implementation has this bug. Can't the 
PDSI issue be fixed with a different issue? Alternatively adding a test 
that checks that IPv6 datagrams of at least size 65507 can be sent on 
configurations that have IPv6 enabled.

A minor nit for the other test updates is that some of them are changing 
existing tests to run, by default, in /othervm mode. I can't tell if 
that is deliberate or not but we usually try to minimize the use of 
/othervm where possible.

-Alan.






From weijun.wang at oracle.com  Mon Apr 13 08:53:12 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 13 Apr 2020 16:53:12 +0800
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID: <BD44C2EF-3417-4863-9A77-00D6A4F8B42A@oracle.com>

The additional patch looks fine to me.

Thanks,
Max

> On Apr 12, 2020, at 3:23 AM, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>> 
> This is additional patch:
> 
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
> 
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the <code>X509Certificate</code> to be checked
> +     * @param cert the <code>X509Certificate</code> to be checked
>      * @param prevKey the <code>PublicKey</code> that failed
>      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
> 
> 
>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>> 
>>>> -Pavel
>>> 
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>> 
>>>> 
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>> 
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>> 
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>> 
>>>>> -Alan
>>>> 
>>> 
>>> Regards,
>>> Vipin
>> 
> Regards,
> Vipin


From daniel.fuchs at oracle.com  Tue Apr 14 09:20:32 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2020 10:20:32 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
 <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
 <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
Message-ID: <c2eec1a3-ca52-ea3a-0e43-b950d523dd00@oracle.com>

Hi Alan,

On 12/04/2020 16:51, Alan Bateman wrote:
> I don't think SetGetSendBufferSize should be in the webrev. It has @bug 
> 8239355 so it's for a different issue.

Patrick will confirm but IIRC this test was added because coverage
testing reported that DS::setSendBufferSize was never called (presumably
existing tests might have been calling setOption instead).
@bug 8239355 is probably a copy/paste error and can be removed.

> I also don't think SendBufCheck should be in the webrev (btw: it also 
> has @bug 8239355). The underlying issue is that PDSI doesn't allow 
> sending IPv6 datagrams on macOS of size 65508-65527 (inclusive) bytes 
> without changing the default value of SO_SNDBUF. It's not an interesting 
> issue of course but I don't think the tests for the JEP should be adding 
> a test to make sure that the old implementation has this bug.

That's where I disagree because it's a slight difference in behavior
between the old implementation and the new - so I believe it's worth
having a test for it (even if does test the presence of a bug in the
old impl). I like this test because it does show how
every implementation behaves in one single place without having
to forage in every other test hierarchy to figure what their
behaviors are. The branch is the only place where you could have
such a test (since the new impl is only available here).

> Can't the 
> PDSI issue be fixed with a different issue? Alternatively adding a test 
> that checks that IPv6 datagrams of at least size 65507 can be sent on 
> configurations that have IPv6 enabled.

Sure - but is it even worth fixing?

best regards

-- daniel

From Alan.Bateman at oracle.com  Tue Apr 14 09:34:18 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Apr 2020 10:34:18 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <c2eec1a3-ca52-ea3a-0e43-b950d523dd00@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
 <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
 <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
 <c2eec1a3-ca52-ea3a-0e43-b950d523dd00@oracle.com>
Message-ID: <b44cccd4-cbfc-15bd-cf60-f3f2d0695bb6@oracle.com>



On 14/04/2020 10:20, Daniel Fuchs wrote:
>
> That's where I disagree because it's a slight difference in behavior
> between the old implementation and the new - so I believe it's worth
> having a test for it (even if does test the presence of a bug in the
> old impl). I like this test because it does show how
> every implementation behaves in one single place without having
> to forage in every other test hierarchy to figure what their
> behaviors are. The branch is the only place where you could have
> such a test (since the new impl is only available here).
Can you create a bug to fix PDSI? It should be a trivial change to 
datagramSocketCreate. That would be the issue to add a test to make sure 
that the initial value of SO_SNDBUF is >= 65537 and avoid creating 
technical debt by adding a test that checks the wrong initial size.

-Alan


From michael.x.mcmahon at oracle.com  Tue Apr 14 14:00:46 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 14 Apr 2020 15:00:46 +0100
Subject: 8241995: Clarify InetSocketAddress::toString specification
In-Reply-To: <DBBPR09MB30146892C7C9FE7A53AEB80BDFC70@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <29F15FC0-AB25-433C-B232-1D73EEA78CCD@oracle.com>
 <DBBPR09MB30146892C7C9FE7A53AEB80BDFC70@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <0995ccd3-c42c-98e0-e74d-c027d23c908c@oracle.com>


On 03/04/2020 21:39, mark sheppard 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 representation.
>
As above but,


"rather than parsing the toString string representation"


maybe instead


"rather than parsing the String returned from toString"


My 2c

Michael


> or
>
> It is advised to use {@link#getHostString()} to obtain a hostname 
> string, or
> in the absence of a hostname, a string form of the address. Do not rely on
> parsing the toString() return value to obtain a hostname string.
>
> regards
> Mark
>
>
>
>
> ------------------------------------------------------------------------
> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of Chris 
> Hegarty <chris.hegarty at oracle.com>
> *Sent:* Friday 3 April 2020 17:26
> *To:* OpenJDK Network Dev list <net-dev at openjdk.java.net>
> *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 "<unresolved>" is displayed. It was also suggested that a link
> to getHostString could be added.
>
> Below is an initial suggestion. It does not change the spec, just adds
> some examples and guidance. I'm relatively happy with the examples, but
> less so with the final advise paragraph. Suggestions welcome.
>
>
> -? /**
> -?? * Constructs a string representation of this InetSocketAddress.
> -?? * This String is constructed by calling toString() on the InetAddress
> -?? * and concatenating the port number (with a colon). If the address
> -?? * is an IPv6 address, the IPv6 literal is enclosed in square brackets.
> -?? * If the address is {@linkplain #isUnresolved() unresolved},
> -?? * {@code <unresolved>} is displayed in place of the address literal.
> -?? *
> -?? * @return? a string representation of this object.
> -?? */
> -? public String toString() { ... }
> ---
> +? /**
> +?? * Constructs a string representation of this InetSocketAddress.
> +?? * This String is constructed by calling {@link InetAddress#toString()}
> +?? * on the InetAddress and concatenating the port number (with a colon).
> +?? *
> +?? * <p> If the address is an IPv6 address, the IPv6 literal is 
> enclosed in
> +?? * square brackets, for example: {@code 
> "localhost/[0:0:0:0:0:0:0:1]:80"}.
> +?? * If the address is {@linkplain #isUnresolved() unresolved},
> +?? * {@code <unresolved>} is displayed in place of the address 
> literal, for
> +?? * example {@code "foo/<unresolved>:80"}.
> +?? *
> +?? * <p> To retrieve a string representation of the hostname, or the 
> string
> +?? * form of the address if it doesn't have a hostname, use {@link
> +?? * #getHostString()}, rather than parsing the string representation.
> +?? *
> +?? * @return? a string representation of this object.
> +?? */
> +? public String toString() { ... }
>
> -Chris
>
> [1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013747.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200414/dd662c46/attachment.htm>

From daniel.fuchs at oracle.com  Tue Apr 14 14:24:00 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2020 15:24:00 +0100
Subject: 8241995: Clarify InetSocketAddress::toString specification
In-Reply-To: <0995ccd3-c42c-98e0-e74d-c027d23c908c@oracle.com>
References: <29F15FC0-AB25-433C-B232-1D73EEA78CCD@oracle.com>
 <DBBPR09MB30146892C7C9FE7A53AEB80BDFC70@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <0995ccd3-c42c-98e0-e74d-c027d23c908c@oracle.com>
Message-ID: <8fdffe51-0d11-31d7-4b49-bd3b171759df@oracle.com>

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 representation.
>>
> As above but,
> 
> "rather than parsing the toString string representation"
> 
> maybe instead
> 
> "rather than parsing the String returned from toString"

I like Michael's suggestion. Maybe lower case "the String" ;-)

best regards,

-- daniel



From daniel.fuchs at oracle.com  Tue Apr 14 15:37:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2020 16:37:56 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count when
 receives 204 response
Message-ID: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>

Hi,

Please find below a fix for:

8238270: java.net HTTP/2 client does not decrease stream count
          when receives 204 response
https://bugs.openjdk.java.net/browse/JDK-8238270

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html

For convenience reason, the Http2Connection handles header's frame
END_STREAM flag by generating a fake dummy and empty data frame
with the END_STREAM flag set.

The empty data frame is later handled by the code that reads the
body - so there is no difference between the case where the
END_STREAM flag is carried by the last header frame, and the
case where it is carried by the (possibly empty and first) data
frame.

This usually work as expected, except in the case of 204, because
in that case, no body is expected, and the exchange will not
register a body subscriber, resulting in that that data frame
never being processed, and leaking the stream...

The fix ensures that any pending data frame will still be processed
after 204 has been received - thus triggering the logic that
eventually closes the stream.

A few notes:

I am not sure the changes to HeaderFrame are 100% correct:
Should that be an error if END_STREAM was set before END_HEADER?
Or does END_STREAM implies END_HEADER?

Changes to the HTTP/2 test server might also not have been needed.
But they do ensure that END_STREAM will always be carried by the
header frame in case of 204 response.

The test will fail without the fix because the TRACKER finds several
HTTP/2 streams still open in @AfterClass and throws an exception
at that point.

best regards,

-- daniel

From pavel.rappo at oracle.com  Wed Apr 15 11:06:46 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 12:06:46 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID: <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>

Vipin,

I saw that Max had already reviewed that incremental patch. That's good.

I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
(International Components for Unicode) package. Once this has been cleared by
experts in that area, we are good to go.

Here's the cumulative webrev:

    http://cr.openjdk.java.net/~prappo/8242366/webrev.01/

-Pavel

> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>> 
> This is additional patch:
> 
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
> 
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the <code>X509Certificate</code> to be checked
> +     * @param cert the <code>X509Certificate</code> to be checked
>      * @param prevKey the <code>PublicKey</code> that failed
>      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
> 
> 
>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>> 
>>>> -Pavel
>>> 
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>> 
>>>> 
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>> 
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>> 
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>> 
>>>>> -Alan
>>>> 
>>> 
>>> Regards,
>>> Vipin
>> 
> Regards,
> Vipin
> 


From patrick.concannon at oracle.com  Wed Apr 15 15:40:39 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 15 Apr 2020 16:40:39 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
Message-ID: <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>

Hi Alan,

Thanks for your feedback. I've updated the fix with your comments and 
you can find them in the new webrev below.

WRT the release note JDK-8237530 
<https://bugs.openjdk.java.net/browse/JDK-8237530>, that's a good point. 
I will look into removing it.

webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/

Kind regards,

Patrick

On 10/04/2020 13:28, Alan Bateman wrote:
>
>
> On 10/04/2020 11:16, Patrick Concannon wrote:
>>
>> Hi,
>>
>> Could someone please review my webrev and CSR for JDK-8237890 
>> 'DatagramPacket::getSocketAddress doesn't specify what happens if 
>> address or port are not set' ?
>>
>> DatagramPacket::getSocketAddress is misleading in that it can throw 
>> an IllegalArgumentException even though it doesn't take any 
>> arguments. This can occur if the port of a DatagramPacket is not set 
>> before a call to getSocketAddress is made.
>>
>> In the recent fixJDK-8236940 
>> <https://bugs.openjdk.java.net/browse/JDK-8236940>, additional checks 
>> were addedto ensure DatagramPacket cannot besent to port 0. Following 
>> on from this update,the current fix changes the default port of a 
>> DatagramPacket from -1 to 0. An IllegalArgumentException will 
>> therefore no longer be thrown when getSocketAddress with no port set. 
>> Instead, an InetSocketAddress representing any local address with 
>> port 0 is returned.
>>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8237890
>> csr: https://bugs.openjdk.java.net/browse/JDK-8242483
>> webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.00/
>>
> The default value for address and port are null and 0 (resp.) so you 
> could just remove L93-94.
>
> In the getSocketAddress() spec it might be better to say "Returns" 
> rather than "Gets" so that its consistent with the getAddress and 
> getPort methods.
>
> Can you look at DatagramSocketAdaptor L202 where the comment is 
> "throws IAE if port not set". I assume that comment should be removed.
>
> Do we need to re-visit or withdraw the release note JDK-8237530 as IAE 
> is there is no longer a "port out of range" condition?
>
> -Alan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200415/91ada07d/attachment.htm>

From chris.hegarty at oracle.com  Wed Apr 15 15:54:38 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Apr 2020 16:54:38 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
Message-ID: <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>



> On 15 Apr 2020, at 16:40, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> ...
> 
> webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/
> 
I added myself as reviewer on the CSR.

The changes mainly look good. Can you please add, or amend an existing, test for the newly specified default address and port values.

-Chris.


From chris.hegarty at oracle.com  Wed Apr 15 16:40:02 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Apr 2020 17:40:02 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
Message-ID: <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>

Daniel,

> On 14 Apr 2020, at 16:37, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8238270: java.net HTTP/2 client does not decrease stream count
>         when receives 204 response
> https://bugs.openjdk.java.net/browse/JDK-8238270
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html
> 
> For convenience reason, the Http2Connection handles header's frame
> END_STREAM flag by generating a fake dummy and empty data frame
> with the END_STREAM flag set.

Which seems reasonable.

> The empty data frame is later handled by the code that reads the
> body - so there is no difference between the case where the
> END_STREAM flag is carried by the last header frame, and the
> case where it is carried by the (possibly empty and first) data
> frame.

Again, seems like a reasonable implementation.

> This usually work as expected, except in the case of 204, because
> in that case, no body is expected, and the exchange will not
> register a body subscriber, resulting in that that data frame
> never being processed, and leaking the stream?

Ah, good find. This explains the issue.

> The fix ensures that any pending data frame will still be processed
> after 204 has been received - thus triggering the logic that
> eventually closes the stream.

I suppose that a 204 response MUST have an END_STREAM 
in its final HEADERS / CONTINUATION frame, right?

> A few notes:
> 
> I am not sure the changes to HeaderFrame are 100% correct:
> Should that be an error if END_STREAM was set before END_HEADER?
> Or does END_STREAM implies END_HEADER?

It is allowable for a HEADERS frame to carry an END_STREAM,
but not an END_HEADERS. If this happens, then CONTINUATION
frames must follow, the last of which will carry END_HEADERS.
That probably explains why the END_STREAM handling is done
the way that it is.

> Changes to the HTTP/2 test server might also not have been needed.
> But they do ensure that END_STREAM will always be carried by the
> header frame in case of 204 response.

We may want to test with CONTINUATION frames too.

I remember adding BadHeadersTest, which can produce
CONTINUATION frames. Not sure if that could be used as
a template here or not.

> The test will fail without the fix because the TRACKER finds several
> HTTP/2 streams still open in @AfterClass and throws an exception
> at that point.

The new test is good, but has an unnecessary reference to
AbstractThrowingSubscribers.TestExecutor.

-Chris.


From pavel.rappo at oracle.com  Wed Apr 15 16:52:47 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 17:52:47 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
 <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
Message-ID: <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>

Vipin,

After a private exchange with Naoto Sato, who is fluent in that area, I decided
to leave out all the changes to the jdk.internal.icu package from the changeset.

The reason is quite simple. A significant portion of code in jdk.internal.icu
comes from an upstream project, ICU4J. Making OpenJDK-local changes to it makes
it harder to merge when updating from upstream. 

Before I created that latter webrev I found that there were OpenJDK-local
changes to that package. Still, the argument holds and we should not aggravate
already existing difficulties.

-Pavel

P.S. If you care about those changes, you may want to ask ICU4J [^1] folk to
incorporate them. If they agree, one day those changes may show up in the OpenJDK.

----------
[^1]: https://github.com/unicode-org/icu/tree/master/icu4j

> On 15 Apr 2020, at 12:06, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Vipin,
> 
> I saw that Max had already reviewed that incremental patch. That's good.
> 
> I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
> (International Components for Unicode) package. Once this has been cleared by
> experts in that area, we are good to go.
> 
> Here's the cumulative webrev:
> 
>    http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
> 
> -Pavel
> 
>> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>> 
>> Hi Pavel,
>> 
>>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> 
>>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>> 
>> This is additional patch:
>> 
>> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
>> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
>> @@ -142,7 +142,7 @@
>>       /**
>>        * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>>        * data the index array offset of the indexes for that lead surrogate.
>> -        * @param property data value for a surrogate from the trie, including
>> +        * @param value data value for a surrogate from the trie, including
>>        *        the folding offset
>>        * @return data offset or 0 if there is no data for the lead surrogate
>>        */
>> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -39,7 +39,7 @@
>> 
>>    /**
>>     * Calls FilterInputStream's constructor.
>> -     * @param an InputStream
>> +     * @param is an InputStream
>>     */
>>    PlainTextInputStream(InputStream is) {
>>        super(is);
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -881,7 +881,7 @@
>>     * only CRLs signed with a different key (but the same issuer
>>     * name) as the certificate being checked.
>>     *
>> -     * @param currCert the <code>X509Certificate</code> to be checked
>> +     * @param cert the <code>X509Certificate</code> to be checked
>>     * @param prevKey the <code>PublicKey</code> that failed
>>     * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>>     * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -166,7 +166,7 @@
>>    /**
>>     * Creates a URICertStore.
>>     *
>> -     * @param parameters specifying the URI
>> +     * @param params parameters specifying the URI
>>     */
>>    URICertStore(CertStoreParameters params)
>>        throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
>> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
>> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -483,7 +483,7 @@
>>         * and its corresponding CertId.
>>         *
>>         * @param subjectCert the certificate to be checked for revocation
>> -         * @param cid the CertId for {@code subjectCert}
>> +         * @param certId the CertId for {@code subjectCert}
>>         */
>>        StatusInfo(X509Certificate subjectCert, CertId certId) {
>>            cert = subjectCert;
>> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
>> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -193,7 +193,7 @@
>>    /**
>>     * Constructs an object to store the response to a timestamp request.
>>     *
>> -     * @param status A buffer containing the ASN.1 BER encoded response.
>> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>>     * @throws IOException The exception is thrown if a problem is encountered
>>     *         parsing the timestamp response.
>>     */
>> 
>> 
>>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>> 
>>>>> Why assume something that sophisticated where it can be adequately explained by
>>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>> 
>>>>> -Pavel
>>>> 
>>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>> 
>>>>> 
>>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>> 
>>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>>> Hi Pavel,
>>>>>>> 
>>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>>> nor imported
>>>>>>> 
>>>>>>> Hopefully that's only on internal classes.
>>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>> 
>>>>>> -Alan
>>>>> 
>>>> 
>>>> Regards,
>>>> Vipin
>>> 
>> Regards,
>> Vipin
>> 
> 


From daniel.fuchs at oracle.com  Wed Apr 15 17:17:01 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 Apr 2020 18:17:01 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
Message-ID: <4d453024-a50b-ba38-0d97-9aaae47f6498@oracle.com>

Hi Chris,

On 15/04/2020 17:40, Chris Hegarty wrote:
> It is allowable for a HEADERS frame to carry an END_STREAM,
> but not an END_HEADERS. If this happens, then CONTINUATION
> frames must follow, the last of which will carry END_HEADERS.
> That probably explains why the END_STREAM handling is done
> the way that it is.

That does not make sense. If there is END_STREAM there cannot
be any continuation frames since the stream will be closed.

cheers,

-- daniel

From daniel.fuchs at oracle.com  Wed Apr 15 17:18:49 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 Apr 2020 18:18:49 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
Message-ID: <7e75d75a-f37e-36b0-f13e-c63460d89b80@oracle.com>

On 15/04/2020 17:40, Chris Hegarty wrote:
> The new test is good, but has an unnecessary reference to
> AbstractThrowingSubscribers.TestExecutor.

Good catch.

I'll send a new webrev after I have received further feedback.
(or in a couple of days if none are forthcoming :-) )

-- daniel

From chris.hegarty at oracle.com  Wed Apr 15 18:46:15 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Apr 2020 19:46:15 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <4d453024-a50b-ba38-0d97-9aaae47f6498@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
 <4d453024-a50b-ba38-0d97-9aaae47f6498@oracle.com>
Message-ID: <81DDB9D2-8AD7-4274-87D9-D67CF48EC6B9@oracle.com>


> On 15 Apr 2020, at 18:17, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 15/04/2020 17:40, Chris Hegarty wrote:
>> It is allowable for a HEADERS frame to carry an END_STREAM,
>> but not an END_HEADERS. If this happens, then CONTINUATION
>> frames must follow, the last of which will carry END_HEADERS.
>> That probably explains why the END_STREAM handling is done
>> the way that it is.
> 
> That does not make sense. If there is END_STREAM there cannot
> be any continuation frames since the stream will be closed.

From section 6.2 - HEADERS: 

   END_STREAM (0x1):  When set, bit 0 indicates that the header block
      (Section 4.3 <https://tools.ietf.org/html/rfc7540#section-4.3>) is the last that the endpoint will send for the
      identified stream.

      A HEADERS frame carries the END_STREAM flag that signals the end
      of a stream.  However, a HEADERS frame with the END_STREAM flag
      set can be followed by CONTINUATION frames on the same stream.
      Logically, the CONTINUATION frames are part of the HEADERS frame.

-Chris.

[1] https://tools.ietf.org/html/rfc7540#section-6.2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200415/1f2f38d0/attachment.htm>

From vipinsharma85 at gmail.com  Sat Apr 11 19:23:57 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Sun, 12 Apr 2020 00:53:57 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
Message-ID: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>

Hi Pavel,

> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> If your new patch addresses a similar type of problem, please send it in reply to this email,
> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
> 
This is additional patch:

--- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
+++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
@@ -142,7 +142,7 @@
        /**
         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
         * data the index array offset of the indexes for that lead surrogate.
-        * @param property data value for a surrogate from the trie, including
+        * @param value data value for a surrogate from the trie, including
         *        the folding offset
         * @return data offset or 0 if there is no data for the lead surrogate
         */
--- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
+++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -39,7 +39,7 @@
 
     /**
      * Calls FilterInputStream's constructor.
-     * @param an InputStream
+     * @param is an InputStream
      */
     PlainTextInputStream(InputStream is) {
         super(is);
--- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -881,7 +881,7 @@
      * only CRLs signed with a different key (but the same issuer
      * name) as the certificate being checked.
      *
-     * @param currCert the <code>X509Certificate</code> to be checked
+     * @param cert the <code>X509Certificate</code> to be checked
      * @param prevKey the <code>PublicKey</code> that failed
      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
--- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -166,7 +166,7 @@
     /**
      * Creates a URICertStore.
      *
-     * @param parameters specifying the URI
+     * @param params parameters specifying the URI
      */
     URICertStore(CertStoreParameters params)
         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
--- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
+++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -483,7 +483,7 @@
          * and its corresponding CertId.
          *
          * @param subjectCert the certificate to be checked for revocation
-         * @param cid the CertId for {@code subjectCert}
+         * @param certId the CertId for {@code subjectCert}
          */
         StatusInfo(X509Certificate subjectCert, CertId certId) {
             cert = subjectCert;
--- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
+++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -193,7 +193,7 @@
     /**
      * Constructs an object to store the response to a timestamp request.
      *
-     * @param status A buffer containing the ASN.1 BER encoded response.
+     * @param tsReply A buffer containing the ASN.1 BER encoded response.
      * @throws IOException The exception is thrown if a problem is encountered
      *         parsing the timestamp response.
      */


>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>> 
>> 
>> 
>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> 
>>> Why assume something that sophisticated where it can be adequately explained by
>>> a simpler thing? :) I bet it was an IDE inspection.
>>> 
>>> -Pavel
>> 
>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>> 
>>> 
>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> 
>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>> Hi Pavel,
>>>>> 
>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>> nor imported
>>>>> 
>>>>> Hopefully that's only on internal classes.
>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>> 
>>>> -Alan
>>> 
>> 
>> Regards,
>> Vipin
> 
Regards,
Vipin


From vipinsharma85 at gmail.com  Wed Apr 15 18:23:10 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Wed, 15 Apr 2020 23:53:10 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
 <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
 <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>
Message-ID: <7E379657-3069-4A46-ACBD-C1AB19AE259D@gmail.com>

Thanks Pavel, I will keep this in mind for future patches.

> On Apr 15, 2020, at 10:22 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Vipin,
> 
> After a private exchange with Naoto Sato, who is fluent in that area, I decided
> to leave out all the changes to the jdk.internal.icu package from the changeset.
> 
> The reason is quite simple. A significant portion of code in jdk.internal.icu
> comes from an upstream project, ICU4J. Making OpenJDK-local changes to it makes
> it harder to merge when updating from upstream. 
> 
> Before I created that latter webrev I found that there were OpenJDK-local
> changes to that package. Still, the argument holds and we should not aggravate
> already existing difficulties.
> 
> -Pavel
> 
> P.S. If you care about those changes, you may want to ask ICU4J [^1] folk to
> incorporate them. If they agree, one day those changes may show up in the OpenJDK.
> 
> ----------
> [^1]: https://github.com/unicode-org/icu/tree/master/icu4j
> 
>> On 15 Apr 2020, at 12:06, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> Vipin,
>> 
>> I saw that Max had already reviewed that incremental patch. That's good.
>> 
>> I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
>> (International Components for Unicode) package. Once this has been cleared by
>> experts in that area, we are good to go.
>> 
>> Here's the cumulative webrev:
>> 
>>   http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
>> 
>> -Pavel
>> 
>>> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>>>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>>> 
>>> This is additional patch:
>>> 
>>> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
>>> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
>>> @@ -142,7 +142,7 @@
>>>      /**
>>>       * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>>>       * data the index array offset of the indexes for that lead surrogate.
>>> -        * @param property data value for a surrogate from the trie, including
>>> +        * @param value data value for a surrogate from the trie, including
>>>       *        the folding offset
>>>       * @return data offset or 0 if there is no data for the lead surrogate
>>>       */
>>> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
>>> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -39,7 +39,7 @@
>>> 
>>>   /**
>>>    * Calls FilterInputStream's constructor.
>>> -     * @param an InputStream
>>> +     * @param is an InputStream
>>>    */
>>>   PlainTextInputStream(InputStream is) {
>>>       super(is);
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -881,7 +881,7 @@
>>>    * only CRLs signed with a different key (but the same issuer
>>>    * name) as the certificate being checked.
>>>    *
>>> -     * @param currCert the <code>X509Certificate</code> to be checked
>>> +     * @param cert the <code>X509Certificate</code> to be checked
>>>    * @param prevKey the <code>PublicKey</code> that failed
>>>    * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>>>    * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -166,7 +166,7 @@
>>>   /**
>>>    * Creates a URICertStore.
>>>    *
>>> -     * @param parameters specifying the URI
>>> +     * @param params parameters specifying the URI
>>>    */
>>>   URICertStore(CertStoreParameters params)
>>>       throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
>>> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
>>> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -483,7 +483,7 @@
>>>        * and its corresponding CertId.
>>>        *
>>>        * @param subjectCert the certificate to be checked for revocation
>>> -         * @param cid the CertId for {@code subjectCert}
>>> +         * @param certId the CertId for {@code subjectCert}
>>>        */
>>>       StatusInfo(X509Certificate subjectCert, CertId certId) {
>>>           cert = subjectCert;
>>> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
>>> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -193,7 +193,7 @@
>>>   /**
>>>    * Constructs an object to store the response to a timestamp request.
>>>    *
>>> -     * @param status A buffer containing the ASN.1 BER encoded response.
>>> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>>>    * @throws IOException The exception is thrown if a problem is encountered
>>>    *         parsing the timestamp response.
>>>    */
>>> 
>>> 
>>>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>> 
>>>>>> Why assume something that sophisticated where it can be adequately explained by
>>>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>>> 
>>>>>> -Pavel
>>>>> 
>>>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>>> 
>>>>>> 
>>>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>>> 
>>>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>>>> Hi Pavel,
>>>>>>>> 
>>>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>>>> nor imported
>>>>>>>> 
>>>>>>>> Hopefully that's only on internal classes.
>>>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>>> 
>>>>>>> -Alan
>>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Vipin
>>>> 
>>> Regards,
>>> Vipin
>>> 
>> 
> 


From daniel.fuchs at oracle.com  Wed Apr 15 19:17:03 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 Apr 2020 20:17:03 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <81DDB9D2-8AD7-4274-87D9-D67CF48EC6B9@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
 <4d453024-a50b-ba38-0d97-9aaae47f6498@oracle.com>
 <81DDB9D2-8AD7-4274-87D9-D67CF48EC6B9@oracle.com>
Message-ID: <3007725d-16a0-5141-244f-685c5c33f321@oracle.com>

Argh!

On 15/04/2020 19:46, Chris Hegarty wrote:
>  From section 6.2 -?HEADERS:
> 
>     END_STREAM (0x1):  When set, bit 0 indicates that the header block
>        (Section 4.3  <https://tools.ietf.org/html/rfc7540#section-4.3>) is the last that the endpoint will send for the
>        identified stream.
> 
>        A HEADERS frame carries the END_STREAM flag that signals the end
>        of a stream.  However, a HEADERS frame with the END_STREAM flag
>        set can be followed by CONTINUATION frames on the same stream.
>        Logically, the CONTINUATION frames are part of the HEADERS frame.
> 

Thanks Chris - I stand corrected.
I should know better than assume things.
My changes to HeaderFrame.java are wrong then. The rest of the fix
should be good. Thanks for catching that! So END_STREAM doesn't
signal the immediate end of the stream...

best regards,

-- daniel

From patrick.concannon at oracle.com  Wed Apr 15 19:22:02 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 15 Apr 2020 20:22:02 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
 <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
 <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
Message-ID: <68715f5b-638b-6965-2682-8f489e6cfdd9@oracle.com>

Hi Alan,

Thanks for your further comments.

I've refactored DatagramSocket as you suggested, and returned 
DatagramSocketAdaptor to the correct formatting. I also removed the 
incorrect @bug tag from SetGetSendBufferSize and /othervm from the other 
test updates.I've included these changes in the updated webrev below.

WRT the PDSI issue, I've created a bug to track this and have assigned 
it to myself. You can view the issue here: 
https://bugs.openjdk.java.net/browse/JDK-8242885


webrev: http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.04/


Kind regards,

Patrick


On 12/04/2020 16:51, Alan Bateman wrote:
> On 09/04/2020 12:26, Patrick Concannon wrote:
>>
>> Hi,
>>
>> Alan - I've gone through your comments and refactored the code 
>> accordingly.
>>
> Just a few minor comments on the implementation changes.
>
> DatagramSocket.java
> - this version of the webrev has a block comment "A global switch ..." 
> that looks like it was added in the wrong place. I assume it can be 
> removed or a subset of the text moved into the command for createDelegate
> - toSocketException can be private
> - the comment on the delegate field could be shortened by dropping 
> "`delegate` can be". That is, it would be a clearer for readers to 
> just say "any instance ..."
> - Another minor nit but the comment on the delegate() method could 
> confuse readers. I think you can drop it or just say that it can be 
> overridden to return a MulticastSocket.
> - The? new // comments added to the asserts at L133-136 aren't useful, 
> I suggest just drop them as the asserts are clear as they are.
>
> DatagramSocketAdaptor
> - this version has re-formatted existing code in several places. Can 
> you undo these changes (I can't tell if they were deliberate or the 
> IDE did it). The only changes should be to be super call and the 
> addition of the DatagramSockets helper class.
>
> MulticastSocket and NetMulticastSocket look good.
>
>> I spoke with Daniel about the SendBufCheck test, and he wants to keep 
>> this in the JEP as it allows to compare the behavior of all the 
>> different implementations in one place.
>>
> I don't think SetGetSendBufferSize should be in the webrev. It has 
> @bug 8239355 so it's for a different issue.
>
> I also don't think SendBufCheck should be in the webrev (btw: it also 
> has @bug 8239355). The underlying issue is that PDSI doesn't allow 
> sending IPv6 datagrams on macOS of size 65508-65527 (inclusive) bytes 
> without changing the default value of SO_SNDBUF. It's not an 
> interesting issue of course but I don't think the tests for the JEP 
> should be adding a test to make sure that the old implementation has 
> this bug. Can't the PDSI issue be fixed with a different issue? 
> Alternatively adding a test that checks that IPv6 datagrams of at 
> least size 65507 can be sent on configurations that have IPv6 enabled.
>
> A minor nit for the other test updates is that some of them are 
> changing existing tests to run, by default, in /othervm mode. I can't 
> tell if that is deliberate or not but we usually try to minimize the 
> use of /othervm where possible.
>
> -Alan.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200415/28c0d2e7/attachment.htm>

From Alan.Bateman at oracle.com  Thu Apr 16 08:09:37 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Apr 2020 09:09:37 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
Message-ID: <e9c886f2-303d-0317-2d80-9d07fa439569@oracle.com>



On 15/04/2020 16:40, Patrick Concannon wrote:
>
> Hi Alan,
>
> Thanks for your feedback. I've updated the fix with your comments and 
> you can find them in the new webrev below.
>
> WRT the release note JDK-8237530 
> <https://bugs.openjdk.java.net/browse/JDK-8237530>, that's a good 
> point. I will look into removing it.
>
> webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/
>
Thanks for the update. Looks good and I've reviewed the CSR too.

Chris is right that we should have tests to check the initial port (and 
address) when using the constructors that don't specify them.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200416/aa01a97f/attachment.htm>

From patrick.concannon at oracle.com  Thu Apr 16 13:39:12 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 16 Apr 2020 14:39:12 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
 <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>
Message-ID: <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>

Hi Chris,

Thanks for that.

I've added the new testcases as requested, and you can find them in the 
new webrev below.

http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/


Kind regards,

Patrick

On 15/04/2020 16:54, Chris Hegarty wrote:
>
>> On 15 Apr 2020, at 16:40, Patrick Concannon <patrick.concannon at oracle.com> wrote:
>>
>> ...
>>
>> webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/
>>
> I added myself as reviewer on the CSR.
>
> The changes mainly look good. Can you please add, or amend an existing, test for the newly specified default address and port values.
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200416/289291ef/attachment.htm>

From daniel.fuchs at oracle.com  Thu Apr 16 13:47:30 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Apr 2020 14:47:30 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
 <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>
 <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
Message-ID: <4fecfd38-012e-4a7c-0780-8f0872c141d4@oracle.com>

Thanks Patrick.

Looks good me.

best regards,

-- daniel

On 16/04/2020 14:39, Patrick Concannon wrote:
> Hi Chris,
> 
> Thanks for that.
> 
> I've added the new testcases as requested, and you can find them in the 
> new webrev below.
> 
> http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/
> 
> 
> Kind regards,
> 
> Patrick
> 
> On 15/04/2020 16:54, Chris Hegarty wrote:
>>> On 15 Apr 2020, at 16:40, Patrick Concannon<patrick.concannon at oracle.com>  wrote:
>>>
>>> ...
>>>
>>> webrev:http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/
>>>
>> I added myself as reviewer on the CSR.
>>
>> The changes mainly look good. Can you please add, or amend an existing, test for the newly specified default address and port values.
>>
>> -Chris.
>>


From chris.hegarty at oracle.com  Thu Apr 16 14:55:50 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 Apr 2020 15:55:50 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
 <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>
 <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
Message-ID: <EBAA5C32-47BF-4ECE-82CB-08B35C45DB28@oracle.com>



> On 16 Apr 2020, at 14:39, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> ...
> 
> http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/

LGTM.

-Chris.


From daniel.fuchs at oracle.com  Thu Apr 16 18:10:01 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Apr 2020 19:10:01 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
Message-ID: <8b5a8a44-5d6c-1661-85d0-75625cc4b16e@oracle.com>

Hi Chris,

>> The fix ensures that any pending data frame will still be processed
>> after 204 has been received - thus triggering the logic that
>> eventually closes the stream.
> 
> I suppose that a 204 response MUST have an END_STREAM
> in its final HEADERS / CONTINUATION frame, right?

I have rescanned the RFC. I could not find a definitive answer to
that question. AFAIU it's expected that the HEADERS frame will
carry the END_STREAM - but there is some sibylline text that let
me think that having an empty DATA frame carrying the END_STREAM
would be OK too:

<<< A response
    that is defined to have no payload, as described in [RFC7230],
    Section 3.3.2, can have a non-zero content-length header field, even
    though no content is included in DATA frames. >>>

> It is allowable for a HEADERS frame to carry an END_STREAM,
> but not an END_HEADERS. If this happens, then CONTINUATION
> frames must follow, the last of which will carry END_HEADERS.
> That probably explains why the END_STREAM handling is done
> the way that it is.

Yes. And the CONTINUATION frame is not supposed to carry the
END_STREAM - so we can see END_STREAM before END_HEADERS.
Therefore I have removed my changes to HeaderFrame.java.
Code inspection shows that we might not deal with that situation
properly - so I have logged https://bugs.openjdk.java.net/browse/JDK-8242999
to follow up on this.

> The new test is good, but has an unnecessary reference to
> AbstractThrowingSubscribers.TestExecutor.
>> https://bugs.openjdk.java.net/browse/JDK-8238270

Done.

New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.01/

best regards, and thanks for the valuable feedback!

-- daniel

>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html


From macanaoire at hotmail.com  Thu Apr 16 23:50:20 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Thu, 16 Apr 2020 23:50:20 +0000
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
 <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>,
 <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
Message-ID: <DBBPR09MB301410A61F2D7EEF554CFCEBDFD80@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Patrick et al.
   a trivial point and a javadoc question

trivial item in SendCheck test, there's a comment referring to pkt3 & 4 and invalid port -1.
This is no longer the case -- afaik it's now "can't send port 0 " in a SocketException ?

I note that there are some java doc changes and wonder is there an opportunity to make some further
amendments:

for getSocketAddress and setSocketAddress methods

the wording "of the remote host"  doesn't quite fit,
and could be replaced with   "of the application or service "

in general remote host could be replaced with host, as localhost provides  a valid IP address !!

references to machine could be replaced with host for consistency, also ?

regards
Mark

________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Patrick Concannon <patrick.concannon at oracle.com>
Sent: Thursday 16 April 2020 13:39
To: Chris Hegarty <chris.hegarty at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'


Hi Chris,


Thanks for that.

I've added the new test cases as requested, and you can find them in the new webrev below.

http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/


Kind regards,

Patrick

On 15/04/2020 16:54, Chris Hegarty wrote:

On 15 Apr 2020, at 16:40, Patrick Concannon <patrick.concannon at oracle.com><mailto:patrick.concannon at oracle.com> wrote:

...

webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/



I added myself as reviewer on the CSR.

The changes mainly look good. Can you please add, or amend an existing, test for the newly specified default address and port values.

-Chris.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200416/c604d050/attachment-0001.htm>

From Alan.Bateman at oracle.com  Fri Apr 17 07:39:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Apr 2020 08:39:46 +0100
Subject: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify
 what happens if address or port are not set'
In-Reply-To: <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
References: <5ae6f896-bcb2-f3ad-7140-4212d1118458@oracle.com>
 <f360f2cf-9aaa-0c3a-1401-6564bf2dc0fb@oracle.com>
 <013c562f-9172-ae02-59f1-5bf3c06c550e@oracle.com>
 <23626B0B-4920-4DB9-9D81-B98B3B4DECAC@oracle.com>
 <aa10f100-b0ae-82a1-f086-f21fb33d39ee@oracle.com>
Message-ID: <27783e68-d05b-6cd1-7f2e-13e994e185d5@oracle.com>



On 16/04/2020 14:39, Patrick Concannon wrote:
>
> I've added the new testcases as requested, and you can find them in 
> the new webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/
>
>
Looks good. A minor nit is that testGetters should probably be 
testGetDefaults. I could imagine adding further tests in the future (no 
need for a new webrev if you take up this suggestion).

I see Marks' comment about other javadoc. I agree that the 
DatagramPacket javadoc could do some cleanup as there is inconsistent 
wording used (some of it dates back to early JDK releases). Something 
for another issue and probably low priority. The javadoc in your patch 
is good.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200417/232c7380/attachment.htm>

From Alan.Bateman at oracle.com  Fri Apr 17 09:35:36 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Apr 2020 10:35:36 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <68715f5b-638b-6965-2682-8f489e6cfdd9@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
 <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>
 <EA4CE90D-CC44-4C12-8B90-725EB62E4963@oracle.com>
 <c6aad4c1-7247-0214-3234-0090148502ad@oracle.com>
 <94f42773-7fdb-a033-88a5-66b139914d4a@oracle.com>
 <68715f5b-638b-6965-2682-8f489e6cfdd9@oracle.com>
Message-ID: <b27af96d-ea27-d377-3b9e-53634110f930@oracle.com>

On 15/04/2020 20:22, Patrick Concannon wrote:
> :
>
> WRT the PDSI issue, I've created a bug to track this and have assigned 
> it to myself. You can view the issue here: 
> https://bugs.openjdk.java.net/browse/JDK-8242885
>
>
Thanks. That should be trivial to fix and should allow SendBufCheck to 
be updated to avoid testing that the older implementation has the wrong 
limit. The JEP hasn't been proposed to target yet so I think there is 
time to get this sorted out in advance.

Is SetGetSendBufferSize.java about extending test coverage? If so then I 
think the range of input needs to be expanded a bit, e.g. attempting to 
set to 0 should throw IAE, it should at least be possible to set it to 
64. I'm curious why the test checks getSoTimeout after the socket has 
been closed. Do you know if the test coverage for the receive buffer 
size is sufficient?

-Alan

From vladimir.a.ivanov at intel.com  Fri Apr 17 23:13:29 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Fri, 17 Apr 2020 23:13:29 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK 
Message-ID: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>

Hello everyone,
I would like to add support for the Application Device Queue (ADQ) technology to the JDK.

The JBS entry and webrev were created for this improvement:
JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
Webrev: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/

Please let us know your feedback and comments for this enhancement.

  Thanks, Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200417/edb3ac9e/attachment.htm>

From Alan.Bateman at oracle.com  Sat Apr 18 15:40:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 18 Apr 2020 16:40:10 +0100
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <564ad7a7-1693-c28b-2b7f-ce3d8ee69ed8@oracle.com>

On 18/04/2020 00:13, Ivanov, Vladimir A wrote:
> Hello everyone,
> I would like to add support for the Application Device Queue (ADQ) technology to the JDK.
>
> The JBS entry and webrev were created for this improvement:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> Webrev: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/
>
> Please let us know your feedback and comments for this enhancement.
>

Just to put more context on this. Vladimir brought this to nio-dev in 
March with some background and initial proposed it as a standard socket 
option [1]. A socket option that allows an application to split incoming 
flows based on their receive queue is very Linux specific so we 
suggested it should be in the JDK-specific ExtendedSocketOptions API 
with the other non-standard socket options.

net-dev is the right mailing list to progress this and get a sponsor 
(maybe Sandhya Viswanathan will do it?). We can probably drop 
core-libs-dev from the this one.

Just a few comments on the current webrev:

The API docs in the webrev is a good start but will need to be fleshed 
out as it uses several terms such as "device queue", "last frame", "Rx 
queue" without any definition. One important point that we will need to 
be covered is that it's a read-only socket option so the docs will need 
to specify the exception that will be thrown when trying to set it. From 
a quick look at the implementation then it appears to fall through to 
InternalError so that might need to be fixed. It will also be important 
to document the socket types and where in their lifecycle (listening, 
connected) that the socket option can be used.

Will SO_INCOMING_NAPI_ID be defined in a header file? It probably needs 
#ifndef to avoid the hardcoded value when building on distributions that 
define it. A passing comment is that native methods static methods so 
"unused" is a jclass.

Tests. Read-only socket options might trip up on existing tests in the 
jdk_net or jdk_nio test groups that enumerate all socket options and 
exercise get and set on each one. The proposed test will probably go 
several iterations to get to something that is maintainable. It will 
also need to be extended to exercise SocketChannel, ServerSocketChannel 
and more.

-Alan

[1] https://mail.openjdk.java.net/pipermail/nio-dev/2020-March/007109.html

From chris.hegarty at oracle.com  Mon Apr 20 08:39:56 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 Apr 2020 09:39:56 +0100
Subject: 8238270: java.net HTTP/2 client does not decrease stream count
 when receives 204 response
In-Reply-To: <8b5a8a44-5d6c-1661-85d0-75625cc4b16e@oracle.com>
References: <d28a1459-e9a5-c79e-b10e-4dd14c9262e9@oracle.com>
 <AFA11C7E-F911-4AE7-B113-FAF3581B297B@oracle.com>
 <8b5a8a44-5d6c-1661-85d0-75625cc4b16e@oracle.com>
Message-ID: <EC41C921-C95F-48EA-949F-E879C6F5E0D8@oracle.com>



> On 16 Apr 2020, at 19:10, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> ... so I have logged https://bugs.openjdk.java.net/browse/JDK-8242999
> to follow up on this.
> ...
> 
> New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.01/
> 

This fixes the issue at-hand and is a a good incremental improvement.
Reviewed.

Clearly there is further work that can be done here to; test, verify,
and possibly fix the various permutations that can arise. This work can
be done through the follow-up issue you have logged.

-Chris.

From sandhya.viswanathan at intel.com  Tue Apr 21 00:28:12 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 21 Apr 2020 00:28:12 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <564ad7a7-1693-c28b-2b7f-ce3d8ee69ed8@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <564ad7a7-1693-c28b-2b7f-ce3d8ee69ed8@oracle.com>
Message-ID: <BYAPR11MB354332F5144B299735674AD9EFD50@BYAPR11MB3543.namprd11.prod.outlook.com>

Hi Alan,

Yes, I will sponsor this. Thanks a lot for your feedback on Vladimir's patch.

Best Regards,
Sandhya


-----Original Message-----
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf Of Alan Bateman
Sent: Saturday, April 18, 2020 8:40 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; net-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

On 18/04/2020 00:13, Ivanov, Vladimir A wrote:
> Hello everyone,
> I would like to add support for the Application Device Queue (ADQ) technology to the JDK.
>
> The JBS entry and webrev were created for this improvement:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> Webrev: 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.00/
>
> Please let us know your feedback and comments for this enhancement.
>

Just to put more context on this. Vladimir brought this to nio-dev in March with some background and initial proposed it as a standard socket option [1]. A socket option that allows an application to split incoming flows based on their receive queue is very Linux specific so we suggested it should be in the JDK-specific ExtendedSocketOptions API with the other non-standard socket options.

net-dev is the right mailing list to progress this and get a sponsor (maybe Sandhya Viswanathan will do it?). We can probably drop core-libs-dev from the this one.

Just a few comments on the current webrev:

The API docs in the webrev is a good start but will need to be fleshed out as it uses several terms such as "device queue", "last frame", "Rx queue" without any definition. One important point that we will need to be covered is that it's a read-only socket option so the docs will need to specify the exception that will be thrown when trying to set it. From a quick look at the implementation then it appears to fall through to InternalError so that might need to be fixed. It will also be important to document the socket types and where in their lifecycle (listening,
connected) that the socket option can be used.

Will SO_INCOMING_NAPI_ID be defined in a header file? It probably needs #ifndef to avoid the hardcoded value when building on distributions that define it. A passing comment is that native methods static methods so "unused" is a jclass.

Tests. Read-only socket options might trip up on existing tests in the jdk_net or jdk_nio test groups that enumerate all socket options and exercise get and set on each one. The proposed test will probably go several iterations to get to something that is maintainable. It will also need to be extended to exercise SocketChannel, ServerSocketChannel and more.

-Alan

[1] https://mail.openjdk.java.net/pipermail/nio-dev/2020-March/007109.html

From chris.hegarty at oracle.com  Tue Apr 21 14:28:31 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 21 Apr 2020 15:28:31 +0100
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>

Vladimir,

> On 18 Apr 2020, at 00:13, Ivanov, Vladimir A <vladimir.a.ivanov at intel.com> wrote:
> 
> Hello everyone,
> I would like to add support for the Application Device Queue (ADQ) technology to the JDK.
> 
> The JBS entry and webrev were created for this improvement:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> Webrev: 

Here is an incomplete set of specific comments relating to the webrev.

1) I get a compilation error on my Linux Ubuntu 18.04 ( admittedly my gcc version may be more recent/strict than that of the one you built with ):

  $ gcc --version
  gcc (Ubuntu 8.3.0-6ubuntu1~18.10) 8.3.0
  Copyright (C) 2018 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  Compilation error:

  /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c: In function 'Java_jdk_net_LinuxSocketOptions_IncomingNapiIdSupported0':
  /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c:231:72: error: passing argument 5 of 'getsockopt' makes pointer from integer without a cast [-Werror=int-conversion]
  231 |     rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, sizeof (one));
      |                                                                        ^~~~~~~~~~~~
      |                                                                        |
      |                                                                        long unsigned int
  In file included from /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c:25:
/var/tmp/jib-chhegar/install/jpg/infra/builddeps/devkit-linux_x64/gcc9.2.0-OL6.4+1.0/devkit-linux_x64-gcc9.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/sys/socket.h:192:32: note: expected 'socklen_t * restrict' {aka 'unsigned int * restrict'} but argument is of type 'long unsigned int'
  192 |          socklen_t *__restrict __optlen) __THROW;
      |          ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
  cc1: all warnings being treated as errors

  Simple fix:

  diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  @@ -224,11 +224,12 @@
  (  JNIEnv *env, jobject unused) {
       int one = 1;
       int rv, s;
  +    socklen_t sz = sizeof (one);
       s = socket(PF_INET, SOCK_STREAM, 0);
       if (s < 0) {
           return JNI_FALSE;
       }
  -    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, sizeof (one));
  +    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, &sz);
       if (rv != 0 && errno == ENOPROTOOPT) {
           rv = JNI_FALSE;
       } else {


2) test/jdk/java/net/SocketOption/AfterClose.java fails

  This test iterates over all socket options reported to be supported by a particular socket, and asserts expected behaviour after the socket has been closed. Clearly, this new option results in unexpected after-close behaviour.

  One example failed scenario output:
    test AfterClose.closedBoundDatagramSocket(SO_INCOMING_NAPI_ID, null): failure
    java.lang.NullPointerException
        at AfterClose.closedBoundDatagramSocket(AfterClose.java:248)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
        at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
        at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
        at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
        at org.testng.TestRunner.privateRun(TestRunner.java:773)
        at org.testng.TestRunner.run(TestRunner.java:623)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
        at org.testng.SuiteRunner.run(SuiteRunner.java:259)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
        at org.testng.TestNG.run(TestNG.java:1018)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
        at java.base/java.lang.Thread.run(Thread.java:832)

3) Interestingly, should this option be supported for datagram sockets too ( as the prior test output seems to suggest ).

4) test/jdk/java/nio/channels/etc/PrintSupportedOptions.java fails

  Example output:
  ----------System.err:(18/1162)----------
  java.lang.InternalError: Unexpected option SO_INCOMING_NAPI_ID
        at jdk.net/jdk.net.ExtendedSocketOptions$1.setOption(ExtendedSocketOptions.java:250)
        at java.base/sun.nio.ch.Net.setSocketOption(Net.java:349)
        at java.base/sun.nio.ch.Net.setSocketOption(Net.java:335)
        at java.base/sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:241)
        at java.base/sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:67)
        at PrintSupportedOptions.test(PrintSupportedOptions.java:66)
        at PrintSupportedOptions.main(PrintSupportedOptions.java:49)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
        at java.base/java.lang.Thread.run(Thread.java:832)

5) Optionally define SO_INCOMING_NAPI_ID

  diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  @@ -33,7 +33,10 @@
   #include "jni_util.h"
   #include "jdk_net_LinuxSocketOptions.h"

  -#define SO_INCOMING_NAPI_ID    56
  +#ifndef SO_INCOMING_NAPI_ID
  +#define SO_INCOMING_NAPI_ID    56
  +#endif
  +
   /*
    * Class:     jdk_net_LinuxSocketOptions
    * Method:    setQuickAck


That?s all for now.

-Chris.


From patrick.concannon at oracle.com  Wed Apr 22 19:18:56 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 22 Apr 2020 20:18:56 +0100
Subject: RFR[8243408]: 'Inconsistent Exceptions are thrown by MulticastSocket
 when sending a DatagramPacket to port 0'
Message-ID: <e30bcf5d-14e9-203e-9c55-a66129104aef@oracle.com>

Hi,

Could someone please review my fix for JDK-8243408 'Inconsistent 
Exceptions are thrown by MulticastSocket when sending a DatagramPacket 
to port 0'?

Currently, MulticastSocket.send(DatagramPacket, byte) throws an 
IOException when sending to port 0 on Unix and macOS, but doesn?t throw 
on Windows and Solaris.
This fix adds a check for port == 0 to MulticastSocket's 2-arg send 
method to ensure a consistent exceptionis thrown across platforms, i.e. 
a SocketException. This follows on from a similar change made to the 
DatagramSocket and DatagramChannel's send method. See JDK-8240533 
<https://bugs.openjdk.java.net/browse/JDK-8240533> for more details


bug: https://bugs.openjdk.java.net/browse/JDK-8243408
webrev: http://cr.openjdk.java.net/~pconcannon/8243408/webrevs/webrev.00/


Kind regards,

Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200422/5882db98/attachment.htm>

From daniel.fuchs at oracle.com  Wed Apr 22 19:29:00 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 Apr 2020 20:29:00 +0100
Subject: RFR[8243408]: 'Inconsistent Exceptions are thrown by
 MulticastSocket when sending a DatagramPacket to port 0'
In-Reply-To: <e30bcf5d-14e9-203e-9c55-a66129104aef@oracle.com>
References: <e30bcf5d-14e9-203e-9c55-a66129104aef@oracle.com>
Message-ID: <6d49940f-b93e-abd2-33e0-12e82aa39585@oracle.com>

Thanks Patrick!

LGTM.

best regards,

-- daniel

On 22/04/2020 20:18, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my fix for JDK-8243408 'Inconsistent 
> Exceptions are thrown by MulticastSocket when sending a DatagramPacket 
> to port 0'?
> 
> Currently, MulticastSocket.send(DatagramPacket, byte) throws an 
> IOException when sending to port 0 on Unix and macOS, but doesn?t throw 
> on Windows and Solaris.
> This fix adds a check for port == 0 to MulticastSocket's 2-arg send 
> method to ensure a consistent exceptionis thrown across platforms, i.e. 
> a SocketException. This follows on from a similar change made to the 
> DatagramSocket and DatagramChannel's send method. See JDK-8240533 
> <https://bugs.openjdk.java.net/browse/JDK-8240533> for more details
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8243408
> webrev: http://cr.openjdk.java.net/~pconcannon/8243408/webrevs/webrev.00/
> 
> 
> Kind regards,
> 
> Patrick
> 


From daniel.fuchs at oracle.com  Thu Apr 23 14:39:59 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 Apr 2020 15:39:59 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid
 chunk header byte 32
Message-ID: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>

Hi,

Please find below a fix for:

8243246: HTTP Client sometimes gets java.io.IOException -> Invalid
          chunk header byte 32
https://bugs.openjdk.java.net/browse/JDK-8243246

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8243246/webrev.00/

Some websites add extraneous white space after the chunk size
in a chunked response. The HttpClient HTTP/1.1 chunk body parser
was expecting CRLF to immediately follow the chunk size and
complains about the extraneous space (ASCII code 32).

Though whitespace after chunk size don't seem to be allowed
by the RFC [1] the chunk size could be followed by a
chunk-ext semi-colon separated list of attributes.

After looking at the legacy HTTP ChunkedInputStream implementation
I decided to handle extensions in the same way:
1. Introduce a maximum value for the number of characters
    that can be found in chunk-size + chunk-ext
2. Simply discard anything between the last character in
    chunk-size and the following CR.

The test contains Lorem-Ipsum-ized versions of the responses
that were sent by the problematic websites listed in the
JBS issue (that is - I kept the structure of the response
and just replaced any content by lorem ipsum data).
I also added an additional response with fake extensions
at the end.

Note: this is HTTP/1.1 only since HTTP/2 doesn't have chunked
responses (DATA frames serve the same purpose).

best regards,

-- daniel


[1] https://tools.ietf.org/html/rfc7230#section-4.1

From patrick.concannon at oracle.com  Thu Apr 23 15:46:25 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 23 Apr 2020 16:46:25 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
Message-ID: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>

Hi,

Could someone please review my fix for JDK-8243488 'Add tests for 
set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'?

This fix adds tests for the methods: setSendBufferSize(int), 
getSendBufferSize(), and getReceieveBufferSize() in the DatagramSocket 
class, and is geared towards increasing the overall test coverage for 
this class.

bug: https://bugs.openjdk.java.net/browse/JDK-8243488
webrev: http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.00/


Kind regards,

Patrick


From chris.hegarty at oracle.com  Thu Apr 23 18:36:12 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 Apr 2020 19:36:12 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException ->
 Invalid chunk header byte 32
In-Reply-To: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
References: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
Message-ID: <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>



> On 23 Apr 2020, at 15:39, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid
>         chunk header byte 32
> https://bugs.openjdk.java.net/browse/JDK-8243246
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8243246/webrev.00/

Looks good. 

Wow, that?s a test and then some ;-)

How do you feel about adding a byte-at-a-time final scenario?

static final List<String> REQ5_RESPONSE_BODY = List.of(
        "B", " ", "\r", "\n",
        "L", "o", "r", "e", "m", " ", "i", "p", "s", "u", "m", "\r" ,"\n",
        "0", ";", " ", "\r", "\n",
        "\r", "\n?);

-Chris.



From vladimir.a.ivanov at intel.com  Thu Apr 23 19:11:55 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Thu, 23 Apr 2020 19:11:55 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
Message-ID: <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>

Thanks a lot to Chris and Alan for detailed comments.
The updated version of patch available at http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/

Changes:
1. in native code the common pattern was used for the 'getsockopt' call.
2. condition to define SO_INCOMING_NAPI_ID was added.
3. the DatagarmSocket was added to the ExtOptionTest
4. testing on my side was extended to the subset 'test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'.
Results are same for the patched and non-patched builds on the RHEL7.7 OS.
Tests test/jdk/java/net/SocketOption/AfterClose.java and test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to support
read only properties.
5. description for the NAPI_ID was updated
6. the UnsupportedOperationException was added to the 'setOption' call for the 'SO_INCOMING_NAPI_ID'.

 Thanks, Vladimir

-----Original Message-----
From: Chris Hegarty <chris.hegarty at oracle.com> 
Sent: Tuesday, April 21, 2020 7:29 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

Vladimir,

> On 18 Apr 2020, at 00:13, Ivanov, Vladimir A <vladimir.a.ivanov at intel.com> wrote:
> 
> Hello everyone,
> I would like to add support for the Application Device Queue (ADQ) technology to the JDK.
> 
> The JBS entry and webrev were created for this improvement:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> Webrev: 

Here is an incomplete set of specific comments relating to the webrev.

1) I get a compilation error on my Linux Ubuntu 18.04 ( admittedly my gcc version may be more recent/strict than that of the one you built with ):

  $ gcc --version
  gcc (Ubuntu 8.3.0-6ubuntu1~18.10) 8.3.0
  Copyright (C) 2018 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  Compilation error:

  /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c: In function 'Java_jdk_net_LinuxSocketOptions_IncomingNapiIdSupported0':
  /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c:231:72: error: passing argument 5 of 'getsockopt' makes pointer from integer without a cast [-Werror=int-conversion]
  231 |     rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, sizeof (one));
      |                                                                        ^~~~~~~~~~~~
      |                                                                        |
      |                                                                        long unsigned int
  In file included from /home/chhegar/repos/jdk/adq/jdk/open/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c:25:
/var/tmp/jib-chhegar/install/jpg/infra/builddeps/devkit-linux_x64/gcc9.2.0-OL6.4+1.0/devkit-linux_x64-gcc9.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/sys/socket.h:192:32: note: expected 'socklen_t * restrict' {aka 'unsigned int * restrict'} but argument is of type 'long unsigned int'
  192 |          socklen_t *__restrict __optlen) __THROW;
      |          ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
  cc1: all warnings being treated as errors

  Simple fix:

  diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  @@ -224,11 +224,12 @@
  (  JNIEnv *env, jobject unused) {
       int one = 1;
       int rv, s;
  +    socklen_t sz = sizeof (one);
       s = socket(PF_INET, SOCK_STREAM, 0);
       if (s < 0) {
           return JNI_FALSE;
       }
  -    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, sizeof (one));
  +    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one, &sz);
       if (rv != 0 && errno == ENOPROTOOPT) {
           rv = JNI_FALSE;
       } else {


2) test/jdk/java/net/SocketOption/AfterClose.java fails

  This test iterates over all socket options reported to be supported by a particular socket, and asserts expected behaviour after the socket has been closed. Clearly, this new option results in unexpected after-close behaviour.

  One example failed scenario output:
    test AfterClose.closedBoundDatagramSocket(SO_INCOMING_NAPI_ID, null): failure
    java.lang.NullPointerException
        at AfterClose.closedBoundDatagramSocket(AfterClose.java:248)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
        at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
        at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
        at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
        at org.testng.TestRunner.privateRun(TestRunner.java:773)
        at org.testng.TestRunner.run(TestRunner.java:623)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
        at org.testng.SuiteRunner.run(SuiteRunner.java:259)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
        at org.testng.TestNG.run(TestNG.java:1018)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
        at java.base/java.lang.Thread.run(Thread.java:832)

3) Interestingly, should this option be supported for datagram sockets too ( as the prior test output seems to suggest ).

4) test/jdk/java/nio/channels/etc/PrintSupportedOptions.java fails

  Example output:
  ----------System.err:(18/1162)----------
  java.lang.InternalError: Unexpected option SO_INCOMING_NAPI_ID
        at jdk.net/jdk.net.ExtendedSocketOptions$1.setOption(ExtendedSocketOptions.java:250)
        at java.base/sun.nio.ch.Net.setSocketOption(Net.java:349)
        at java.base/sun.nio.ch.Net.setSocketOption(Net.java:335)
        at java.base/sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:241)
        at java.base/sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:67)
        at PrintSupportedOptions.test(PrintSupportedOptions.java:66)
        at PrintSupportedOptions.main(PrintSupportedOptions.java:49)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
        at java.base/java.lang.Thread.run(Thread.java:832)

5) Optionally define SO_INCOMING_NAPI_ID

  diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
  @@ -33,7 +33,10 @@
   #include "jni_util.h"
   #include "jdk_net_LinuxSocketOptions.h"

  -#define SO_INCOMING_NAPI_ID    56
  +#ifndef SO_INCOMING_NAPI_ID
  +#define SO_INCOMING_NAPI_ID    56
  +#endif
  +
   /*
    * Class:     jdk_net_LinuxSocketOptions
    * Method:    setQuickAck


That?s all for now.

-Chris.


From Alan.Bateman at oracle.com  Fri Apr 24 06:09:03 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Apr 2020 07:09:03 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException ->
 Invalid chunk header byte 32
In-Reply-To: <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
References: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
 <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
Message-ID: <e73ad712-5295-30a4-63c1-3e1554b887b6@oracle.com>

On 23/04/2020 19:36, Chris Hegarty wrote:
> :
>
>
> Wow, that?s a test and then some ;-)
>
It looks like there are >3000 lines of embedded data, is a reason why 
these responses can't be loaded from data files? Some of these could be 
text blocks too of course but they are really long and might be better 
as data files.

-Alan


From Alan.Bateman at oracle.com  Fri Apr 24 07:09:15 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Apr 2020 08:09:15 +0100
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>

On 23/04/2020 20:11, Ivanov, Vladimir A wrote:
> Thanks a lot to Chris and Alan for detailed comments.
> The updated version of patch available at http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/
>
> Changes:
> 1. in native code the common pattern was used for the 'getsockopt' call.
> 2. condition to define SO_INCOMING_NAPI_ID was added.
> 3. the DatagarmSocket was added to the ExtOptionTest
> 4. testing on my side was extended to the subset 'test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'.
> Results are same for the patched and non-patched builds on the RHEL7.7 OS.
> Tests test/jdk/java/net/SocketOption/AfterClose.java and test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to support
> read only properties.
> 5. description for the NAPI_ID was updated
> 6. the UnsupportedOperationException was added to the 'setOption' call for the 'SO_INCOMING_NAPI_ID'.
>
(Dropping core-libs-dev as net-dev is the more appropriate list for this 
area).

Thanks for the update.

The updated javadoc looks better but will need a few iterations. It 
would be good if it could start by explaining what the value of the 
socket option is, e.g. "The value of this socket option is an Integer 
representing the network device queue ...". I think it needs to be 
clearer on the types of sockets that support this option, does it 
support both stream-oriented and datagram-oriented sockets? Does it 
return a value when invoked on a ServerSocketChannel? Instead of 
@throws, the text will need to that attempting to set the socket option 
will cause UOE to be thrown. Once the javadoc is agreed then the CSR can 
be submitted and the code review can continue in parallel.

The implementation changes mostly look okay although 
IncomingNapiIdSupported0 should probably be renamed to start with lower 
case "i". Also someone might need to check that you can create an IPv4 
socket when a system is configured as an IPv6-only system.

Tests. I think the the new tests in ExtOptionTest will need closer 
examination as I can't tell how reliable they are. It might be that it 
needs a completely new test. The update to the NIO PrintSupportedOptions 
test define READ_ONLY_OPTS as Set<String>.

-Alan

From vyommani at gmail.com  Fri Apr 24 08:12:12 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 24 Apr 2020 13:42:12 +0530
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <CAKysZ8w56X1Nxx1qk4FMo9LgweA7=NLgWfS70MZpfo=OtsMqKg@mail.gmail.com>

Hi Vladimir,

In LinuxSocketOptions.c we have lot's of duplicate code, can you please
reuse "socketOptionSupported" & "handleError" as follows, this we remove
lot's of duplicate code.
Thanks,
Vyom

diff -r b6b4506a7827 src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
--- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c Fri Apr 24
15:28:57 2020 +0800
+++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c Fri Apr 24
13:37:36 2020 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -33,6 +33,10 @@
 #include "jni_util.h"
 #include "jdk_net_LinuxSocketOptions.h"

+#ifndef SO_INCOMING_NAPI_ID
+#define SO_INCOMING_NAPI_ID    56
+#endif
+
 /*
  * Class:     jdk_net_LinuxSocketOptions
  * Method:    setQuickAck
@@ -44,15 +48,7 @@
     int rv;
     optval = (on ? 1 : 0);
     rv = setsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &optval, sizeof
(optval));
-    if (rv < 0) {
-        if (errno == ENOPROTOOPT) {
-            JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
-                            "unsupported socket option");
-        } else {
-            JNU_ThrowByNameWithLastError(env, "java/net/SocketException",
-                                        "set option TCP_QUICKACK failed");
-        }
-    }
+    handleError(env, rv, "set option TCP_QUICKACK failed");
 }

 /*
@@ -65,15 +61,7 @@
     int on;
     socklen_t sz = sizeof (on);
     int rv = getsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &on, &sz);
-    if (rv < 0) {
-        if (errno == ENOPROTOOPT) {
-            JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
-                            "unsupported socket option");
-        } else {
-            JNU_ThrowByNameWithLastError(env, "java/net/SocketException",
-                                        "get option TCP_QUICKACK failed");
-        }
-    }
+    handleError(env, rv, "get option TCP_QUICKACK failed");
     return on != 0;
 }

@@ -83,31 +71,18 @@
  * Signature: ()Z
  */
 JNIEXPORT jboolean JNICALL
Java_jdk_net_LinuxSocketOptions_quickAckSupported0
-(JNIEnv *env, jobject unused) {
-    int one = 1;
-    int rv, s;
-    s = socket(PF_INET, SOCK_STREAM, 0);
-    if (s < 0) {
-        return JNI_FALSE;
-    }
-    rv = setsockopt(s, SOL_SOCKET, TCP_QUICKACK, (void *) &one, sizeof
(one));
-    if (rv != 0 && errno == ENOPROTOOPT) {
-        rv = JNI_FALSE;
-    } else {
-        rv = JNI_TRUE;
-    }
-    close(s);
-    return rv;
+(JNIEnv *env, jobject unused) {
+    return socketOptionSupported(SOL_SOCKET, TCP_QUICKACK);
 }

-static jint socketOptionSupported(jint sockopt) {
+static jint socketOptionSupported(jint level, jint optname) {
     jint one = 1;
     jint rv, s;
     s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
     if (s < 0) {
         return 0;
     }
-    rv = setsockopt(s, SOL_TCP, sockopt, (void *) &one, sizeof (one));
+    rv = setsockopt(s, level, optname, (void *) &one, sizeof (one));
     if (rv != 0 && errno == ENOPROTOOPT) {
         rv = 0;
     } else {
@@ -135,8 +110,8 @@
  */
 JNIEXPORT jboolean JNICALL
Java_jdk_net_LinuxSocketOptions_keepAliveOptionsSupported0
 (JNIEnv *env, jobject unused) {
-    return socketOptionSupported(TCP_KEEPIDLE) &&
socketOptionSupported(TCP_KEEPCNT)
-            && socketOptionSupported(TCP_KEEPINTVL);
+    return socketOptionSupported(SOL_TCP, TCP_KEEPIDLE) &&
socketOptionSupported(SOL_TCP, TCP_KEEPCNT)
+            && socketOptionSupported(SOL_TCP, TCP_KEEPINTVL);
 }

 /*
@@ -213,3 +188,27 @@
     handleError(env, rv, "get option TCP_KEEPINTVL failed");
     return optval;
 }
+
+/*
+ * Class:     jdk_net_LinuxSocketOptions
+ * Method:    IncomingNapiIdSupported0
+ * Signature: (I)I;
+ */
+JNIEXPORT jboolean JNICALL
Java_jdk_net_LinuxSocketOptions_IncomingNapiIdSupported0
+(JNIEnv *env, jobject unused) {
+    return socketOptionSupported(SOL_SOCKET, SO_INCOMING_NAPI_ID);
+}
+
+/*
+ * Class:     jdk_net_LinuxSocketOptions
+ * Method:    getIncomingNapiId0
+ * Signature: (I)I;
+ */
+JNIEXPORT jint JNICALL Java_jdk_net_LinuxSocketOptions_getIncomingNapiId0
+(JNIEnv *env, jobject unused, jint fd) {
+    jint optval, rv;
+    socklen_t sz = sizeof (optval);
+    rv = getsockopt(fd, SOL_SOCKET, SO_INCOMING_NAPI_ID, &optval, &sz);
+    handleError(env, rv, "get option SO_INCOMING_NAPI_ID failed");
+    return optval;
+}

On Fri, Apr 24, 2020 at 12:43 AM Ivanov, Vladimir A <
vladimir.a.ivanov at intel.com> wrote:

> Thanks a lot to Chris and Alan for detailed comments.
> The updated version of patch available at
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/
>
> Changes:
> 1. in native code the common pattern was used for the 'getsockopt' call.
> 2. condition to define SO_INCOMING_NAPI_ID was added.
> 3. the DatagarmSocket was added to the ExtOptionTest
> 4. testing on my side was extended to the subset 'test/jdk/java/net
> test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net
> test/jdk/sun/net'.
> Results are same for the patched and non-patched builds on the RHEL7.7 OS.
> Tests test/jdk/java/net/SocketOption/AfterClose.java and
> test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to
> support
> read only properties.
> 5. description for the NAPI_ID was updated
> 6. the UnsupportedOperationException was added to the 'setOption' call for
> the 'SO_INCOMING_NAPI_ID'.
>
>  Thanks, Vladimir
>
> -----Original Message-----
> From: Chris Hegarty <chris.hegarty at oracle.com>
> Sent: Tuesday, April 21, 2020 7:29 AM
> To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; core-libs-dev <
> core-libs-dev at openjdk.java.net>; net >> OpenJDK Network Dev list <
> net-dev at openjdk.java.net>
> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK
>
> Vladimir,
>
> > On 18 Apr 2020, at 00:13, Ivanov, Vladimir A <
> vladimir.a.ivanov at intel.com> wrote:
> >
> > Hello everyone,
> > I would like to add support for the Application Device Queue (ADQ)
> technology to the JDK.
> >
> > The JBS entry and webrev were created for this improvement:
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8243099
> > Webrev:
>
> Here is an incomplete set of specific comments relating to the webrev.
>
> 1) I get a compilation error on my Linux Ubuntu 18.04 ( admittedly my gcc
> version may be more recent/strict than that of the one you built with ):
>
>   $ gcc --version
>   gcc (Ubuntu 8.3.0-6ubuntu1~18.10) 8.3.0
>   Copyright (C) 2018 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
>   Compilation error:
>
>   /home/chhegar/repos/jdk/adq/jdk/open/src/
> jdk.net/linux/native/libextnet/LinuxSocketOptions.c: In function
> 'Java_jdk_net_LinuxSocketOptions_IncomingNapiIdSupported0':
>   /home/chhegar/repos/jdk/adq/jdk/open/src/
> jdk.net/linux/native/libextnet/LinuxSocketOptions.c:231:72: error:
> passing argument 5 of 'getsockopt' makes pointer from integer without a
> cast [-Werror=int-conversion]
>   231 |     rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *)
> &one, sizeof (one));
>       |
>     ^~~~~~~~~~~~
>       |
>     |
>       |
>     long unsigned int
>   In file included from /home/chhegar/repos/jdk/adq/jdk/open/src/
> jdk.net/linux/native/libextnet/LinuxSocketOptions.c:25:
> /var/tmp/jib-chhegar/install/jpg/infra/builddeps/devkit-linux_x64/gcc9.2.0-OL6.4+1.0/devkit-linux_x64-gcc9.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/sys/socket.h:192:32:
> note: expected 'socklen_t * restrict' {aka 'unsigned int * restrict'} but
> argument is of type 'long unsigned int'
>   192 |          socklen_t *__restrict __optlen) __THROW;
>       |          ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>   cc1: all warnings being treated as errors
>
>   Simple fix:
>
>   diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
> b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   @@ -224,11 +224,12 @@
>   (  JNIEnv *env, jobject unused) {
>        int one = 1;
>        int rv, s;
>   +    socklen_t sz = sizeof (one);
>        s = socket(PF_INET, SOCK_STREAM, 0);
>        if (s < 0) {
>            return JNI_FALSE;
>        }
>   -    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one,
> sizeof (one));
>   +    rv = getsockopt(s, SOL_SOCKET, SO_INCOMING_NAPI_ID, (void *) &one,
> &sz);
>        if (rv != 0 && errno == ENOPROTOOPT) {
>            rv = JNI_FALSE;
>        } else {
>
>
> 2) test/jdk/java/net/SocketOption/AfterClose.java fails
>
>   This test iterates over all socket options reported to be supported by a
> particular socket, and asserts expected behaviour after the socket has been
> closed. Clearly, this new option results in unexpected after-close
> behaviour.
>
>   One example failed scenario output:
>     test AfterClose.closedBoundDatagramSocket(SO_INCOMING_NAPI_ID, null):
> failure
>     java.lang.NullPointerException
>         at AfterClose.closedBoundDatagramSocket(AfterClose.java:248)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>         at
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>         at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>         at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>         at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>         at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
>         at
> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>         at org.testng.TestRunner.privateRun(TestRunner.java:773)
>         at org.testng.TestRunner.run(TestRunner.java:623)
>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>         at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>         at org.testng.TestNG.run(TestNG.java:1018)
>         at
> com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>         at
> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>         at java.base/java.lang.Thread.run(Thread.java:832)
>
> 3) Interestingly, should this option be supported for datagram sockets too
> ( as the prior test output seems to suggest ).
>
> 4) test/jdk/java/nio/channels/etc/PrintSupportedOptions.java fails
>
>   Example output:
>   ----------System.err:(18/1162)----------
>   java.lang.InternalError: Unexpected option SO_INCOMING_NAPI_ID
>         at
> jdk.net/jdk.net.ExtendedSocketOptions$1.setOption(ExtendedSocketOptions.java:250)
>         at java.base/sun.nio.ch.Net.setSocketOption(Net.java:349)
>         at java.base/sun.nio.ch.Net.setSocketOption(Net.java:335)
>         at java.base/sun.nio.ch
> .SocketChannelImpl.setOption(SocketChannelImpl.java:241)
>         at java.base/sun.nio.ch
> .SocketChannelImpl.setOption(SocketChannelImpl.java:67)
>         at PrintSupportedOptions.test(PrintSupportedOptions.java:66)
>         at PrintSupportedOptions.main(PrintSupportedOptions.java:49)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>         at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>         at
> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>         at java.base/java.lang.Thread.run(Thread.java:832)
>
> 5) Optionally define SO_INCOMING_NAPI_ID
>
>   diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
> b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c
>   @@ -33,7 +33,10 @@
>    #include "jni_util.h"
>    #include "jdk_net_LinuxSocketOptions.h"
>
>   -#define SO_INCOMING_NAPI_ID    56
>   +#ifndef SO_INCOMING_NAPI_ID
>   +#define SO_INCOMING_NAPI_ID    56
>   +#endif
>   +
>    /*
>     * Class:     jdk_net_LinuxSocketOptions
>     * Method:    setQuickAck
>
>
> That?s all for now.
>
> -Chris.
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200424/694f9a34/attachment-0001.htm>

From chris.hegarty at oracle.com  Fri Apr 24 08:32:43 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 24 Apr 2020 09:32:43 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
Message-ID: <3ADC668E-BF66-49D9-A0EA-2BF2C3D2CC32@oracle.com>


> On 23 Apr 2020, at 16:46, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> Hi,
> 
> Could someone please review my fix for JDK-8243488 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'?
> 
> This fix adds tests for the methods: setSendBufferSize(int), getSendBufferSize(), and getReceieveBufferSize() in the DatagramSocket class, and is geared towards increasing the overall test coverage for this class.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8243488
> webrev: http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.00/
> 
LGTM.

-Chris.

From daniel.fuchs at oracle.com  Fri Apr 24 08:34:27 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 Apr 2020 09:34:27 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException ->
 Invalid chunk header byte 32
In-Reply-To: <e73ad712-5295-30a4-63c1-3e1554b887b6@oracle.com>
References: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
 <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
 <e73ad712-5295-30a4-63c1-3e1554b887b6@oracle.com>
Message-ID: <401cc972-d327-b742-c0b4-0e5659a459c6@oracle.com>

Hi Alan,

On 24/04/2020 07:09, Alan Bateman wrote:
> It looks like there are >3000 lines of embedded data, is a reason why 
> these responses can't be loaded from data files? Some of these could be 
> text blocks too of course but they are really long and might be better 
> as data files.

I originally had them as data files and converted them to List
of strings in the code.
The crucial issue is that this data needs CRLF at the right
places and I don't trust that they might not get changed to plain
LF at some point if kept in files (+ I dislike data file ;-) ).

I'd rather keep them as list of strings in the code.
You might have noticed (or not) that I took some care to
ensure that chunk headers would be on their own single
line which makes it easier to see the structure of the
chunked response.

I could probably remove (or shorten) the bigger ones if
that's an issue - but is that an issue?

best regards,

-- daniel

From Alan.Bateman at oracle.com  Fri Apr 24 08:59:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Apr 2020 09:59:45 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
Message-ID: <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>

On 23/04/2020 16:46, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8243488 'Add tests for 
> set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'?
>
> This fix adds tests for the methods: setSendBufferSize(int), 
> getSendBufferSize(), and getReceieveBufferSize() in the DatagramSocket 
> class, and is geared towards increasing the overall test coverage for 
> this class.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8243488
> webrev: http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.00/
Another potential test for SetGetSendBufferSize is a 
testInitialSendBufferSize to check that the initial value of SO_SNDBUF 
is >= 65507 when Platform.isOSX() is true. That test could be refined 
further when JDK-8242885 is fixed.

-Alan.

From rahul.r.yadav at oracle.com  Fri Apr 24 14:58:56 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Fri, 24 Apr 2020 15:58:56 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
Message-ID: <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>

Hello,

 

  Request to have my fix reviewed for the issue:

  JDK-8242999 :  http/2 client may not handle continuation frames correctly.

   

  The fix updates jdk.internal.net.http.Stream.incoming(Http2Frame frame) to handle

  the scenario where a continuation with `END_HEADERS` may appear after a header

  frame, this was not being handled earlier.

   

         Issue:       https://bugs.openjdk.java.net/browse/JDK-8242999

         Webrev:  http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.00/

 

? --rahul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200424/749bae0a/attachment.htm>

From daniel.fuchs at oracle.com  Fri Apr 24 15:14:01 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 Apr 2020 16:14:01 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException ->
 Invalid chunk header byte 32
In-Reply-To: <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
References: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
 <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
Message-ID: <f50871f5-ca61-8326-8173-16d5f947a73f@oracle.com>

Hi Chris,

On 23/04/2020 19:36, Chris Hegarty wrote:
> How do you feel about adding a byte-at-a-time final scenario?
> 
> static final List<String> REQ5_RESPONSE_BODY = List.of(
>          "B", " ", "\r", "\n",
>          "L", "o", "r", "e", "m", " ", "i", "p", "s", "u", "m", "\r" ,"\n",
>          "0", ";", " ", "\r", "\n",
>          "\r", "\n?);

Good idea!

I also added a delay for that case in the hope it will make it more
likely the byte-at-a-time delivery is preserved on the
client side.

http://cr.openjdk.java.net/~dfuchs/webrev_8243246/webrev.01/

best regards,

-- daniel

From chris.hegarty at oracle.com  Fri Apr 24 15:27:16 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 24 Apr 2020 16:27:16 +0100
Subject: 8243246: HTTP Client sometimes gets java.io.IOException ->
 Invalid chunk header byte 32
In-Reply-To: <f50871f5-ca61-8326-8173-16d5f947a73f@oracle.com>
References: <4f7b07b1-4014-1ab2-511e-8defff6ea726@oracle.com>
 <B5DB8B5A-3F75-41BA-9263-B3DB9B630B83@oracle.com>
 <f50871f5-ca61-8326-8173-16d5f947a73f@oracle.com>
Message-ID: <FE6678EF-D031-45C6-895E-2394047BDA3A@oracle.com>


> On 24 Apr 2020, at 16:14, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 23/04/2020 19:36, Chris Hegarty wrote:
>> How do you feel about adding a byte-at-a-time final scenario?
>> static final List<String> REQ5_RESPONSE_BODY = List.of(
>>         "B", " ", "\r", "\n",
>>         "L", "o", "r", "e", "m", " ", "i", "p", "s", "u", "m", "\r" ,"\n",
>>         "0", ";", " ", "\r", "\n",
>>         "\r", "\n?);
> 
> Good idea!
> 
> I also added a delay for that case in the hope it will make it more
> likely the byte-at-a-time delivery is preserved on the
> client side.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8243246/webrev.01/

You have my Review.

-Chris.


From patrick.concannon at oracle.com  Fri Apr 24 20:00:42 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 24 Apr 2020 21:00:42 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
Message-ID: <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>

Hi Alan,

Yeah, sounds good. I?ve added that test case as requested, and you can 
find it in the updated webrev below.

http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.01/

Kind regards,

Patrick


On 24/04/2020 09:59, Alan Bateman wrote:
> On 23/04/2020 16:46, Patrick Concannon wrote:
>> Hi,
>>
>> Could someone please review my fix for JDK-8243488 'Add tests for 
>> set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'?
>>
>> This fix adds tests for the methods: setSendBufferSize(int), 
>> getSendBufferSize(), and getReceieveBufferSize() in the 
>> DatagramSocket class, and is geared towards increasing the overall 
>> test coverage for this class.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8243488
>> webrev: 
>> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.00/
> Another potential test for SetGetSendBufferSize is a 
> testInitialSendBufferSize to check that the initial value of SO_SNDBUF 
> is >= 65507 when Platform.isOSX() is true. That test could be refined 
> further when JDK-8242885 is fixed.
>
> -Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200424/5df1fdc4/attachment.htm>

From Alan.Bateman at oracle.com  Sat Apr 25 14:53:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 25 Apr 2020 15:53:45 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
Message-ID: <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>



On 24/04/2020 21:00, Patrick Concannon wrote:
>
> Hi Alan,
>
> Yeah, sounds good. I?ve added that test case as requested, and you can 
> find it in the updated webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.01/
>
testInitialSendBufferSize looks good, thanks for adding that.

A minor nit is that the @AfterTest method is in the middle of several 
tests so not easy to check that it cleans up exactly the resources that 
the @BeforeTest method creates. It might be helpful to move it so that 
it is declared after Setup.? No new webrev needed for that of course.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200425/48ec6e84/attachment.htm>

From chris.hegarty at oracle.com  Mon Apr 27 10:29:02 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 Apr 2020 11:29:02 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
Message-ID: <5248CB13-26E1-4D94-83F1-0C5C9076BD12@oracle.com>

Rahul,

> On 24 Apr 2020, at 15:58, Rahul <rahul.r.yadav at oracle.com> wrote:
> 
> Hello,
>  
>   Request to have my fix reviewed for the issue:
>   JDK-8242999 :  http/2 client may not handle continuation frames correctly.
>    
>   The fix updates jdk.internal.net.http.Stream.incoming(Http2Frame frame) to handle
>   the scenario where a continuation with `END_HEADERS` may appear after a header
>   frame, this was not being handled earlier.
>    
>          Issue:       https://bugs.openjdk.java.net/browse/JDK-8242999
>          Webrev:  http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.00/
> 

Looks good.

Can you please update the comment in the test. Suggest:

  * A function that returns a list of 1) a HEADERS frame WITH END_STREAM
  *( AND an empty payload ), and 2) two CONTINUATION frames, THE FIRST
  * is empty and THE SECOND with headers AND END_HEADERS.

-Chris.



From daniel.fuchs at oracle.com  Mon Apr 27 11:42:32 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 Apr 2020 12:42:32 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
Message-ID: <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>

Hi Rahul,

That looks very good!
Thanks for taking that on.

Not related to your fix, but could you update the
code that creates the HttpClient to explicitly require no
proxy? I suggest to update:

  166                 client = 
HttpClient.newBuilder().sslContext(sslContext).build();

to:

                      client = HttpClient.newBuilder()
                          .proxy(HttpClient.Builder.NO_PROXY)
                          .sslContext(sslContext)
                          .build();

Not explicitly requiring NO_PROXY has been a source of
instability on certain environments - as it might pick
up system proxies.

best regards,

-- daniel

On 24/04/2020 15:58, Rahul wrote:
> Hello,
> 
> Request to have my fix reviewed for the issue:
> 
> JDK-8242999 : ?http/2 client may not handle continuation frames correctly.
> 
> The fix updates jdk.internal.net.http.Stream.incoming(Http2Frame frame) 
> to handle
> 
> the scenario where a continuation with `END_HEADERS` may appear after a 
> header
> 
> frame, this was not being handled earlier.
> 
>  ?????????Issue: https://bugs.openjdk.java.net/browse/JDK-8242999
> 
>  ??????? ?Webrev: 
> http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.00/
> 
>  ? --rahul
> 


From rahul.r.yadav at oracle.com  Mon Apr 27 13:04:12 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Mon, 27 Apr 2020 14:04:12 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
 <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>
Message-ID: <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>

Thanks for the review comments.
I have updated the webrev : http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/
 

?On 27/04/2020, 12:42, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:

    Hi Rahul,
    
    That looks very good!
    Thanks for taking that on.
    
    Not related to your fix, but could you update the
    code that creates the HttpClient to explicitly require no
    proxy? I suggest to update:
    
      166                 client = 
    HttpClient.newBuilder().sslContext(sslContext).build();
    
    to:
    
                          client = HttpClient.newBuilder()
                              .proxy(HttpClient.Builder.NO_PROXY)
                              .sslContext(sslContext)
                              .build();
    
    Not explicitly requiring NO_PROXY has been a source of
    instability on certain environments - as it might pick
    up system proxies.
    
    best regards,
    
    -- daniel
    
    On 24/04/2020 15:58, Rahul wrote:
    > Hello,
    > 
    > Request to have my fix reviewed for the issue:
    > 
    > JDK-8242999 :  http/2 client may not handle continuation frames correctly.
    > 
    > The fix updates jdk.internal.net.http.Stream.incoming(Http2Frame frame) 
    > to handle
    > 
    > the scenario where a continuation with `END_HEADERS` may appear after a 
    > header
    > 
    > frame, this was not being handled earlier.
    > 
    >           Issue: https://bugs.openjdk.java.net/browse/JDK-8242999
    > 
    >           Webrev: 
    > http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.00/
    > 
    >    --rahul
    > 
    
    



From daniel.fuchs at oracle.com  Mon Apr 27 13:11:46 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 Apr 2020 14:11:46 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
 <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>
 <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>
Message-ID: <4fa3f38b-74d2-94d2-223c-e55c114fa360@oracle.com>

On 27/04/2020 14:04, Rahul wrote:
> Thanks for the review comments.
> I have updated the webrev : http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/

Thanks Rahul!

LGTM.

-- daniel

From chris.hegarty at oracle.com  Mon Apr 27 16:00:40 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 Apr 2020 17:00:40 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
 <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>
 <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>
Message-ID: <C01E32C8-03A4-43B9-9AA9-6AE9545C8C82@oracle.com>

Rahul,

> On 27 Apr 2020, at 14:04, Rahul <rahul.r.yadav at oracle.com> wrote:
> 
> Thanks for the review comments.
> I have updated the webrev : http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/

Seems you took my suggestion too literally ;-)

I capitalised some of the text to clearly demarcate it as NEW, rather than the exact text.

So that would be:

 * A function that returns a list of 1) a HEADERS frame with END_STREAM
 *( and an empty payload ), and 2) two CONTINUATION frames, the first
 * is empty, and the second contains headers and the END_HEADERS flag.

No need for another webrev.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200427/13f43a3e/attachment.htm>

From rahul.r.yadav at oracle.com  Mon Apr 27 16:04:03 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Mon, 27 Apr 2020 17:04:03 +0100
Subject: RFR 8242999: http/2 client may not handle continuation frames
 correctly
In-Reply-To: <C01E32C8-03A4-43B9-9AA9-6AE9545C8C82@oracle.com>
References: <D5D7E0A4-6AFC-4B3A-BCE8-94EE57BBCF2C@oracle.com>
 <0DDB8262-46B1-4A3B-9B8C-E5A7E245B204@oracle.com>
 <14377736-D2E4-4068-BC8B-60ABEE47B692@oracle.com>
 <0991fd84-4430-1c1f-123f-9bc9c961196b@oracle.com>
 <B0D8270A-B678-4730-A551-E68F04D2AF9C@oracle.com>
 <C01E32C8-03A4-43B9-9AA9-6AE9545C8C82@oracle.com>
Message-ID: <180B8B5B-D127-4EE3-8BB4-1640CABA8E4E@oracle.com>

Hi Chris,

 

 Thank you for letting know, will update.

 

-- rahul

From: Chris Hegarty <chris.hegarty at oracle.com>
Date: Monday 27 April 2020 at 17:00
To: Rahul <rahul.r.yadav at oracle.com>, OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 8242999: http/2 client may not handle continuation frames correctly

 

Rahul,



On 27 Apr 2020, at 14:04, Rahul <rahul.r.yadav at oracle.com> wrote:

 

Thanks for the review comments.
I have updated the webrev : http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/

 

Seems you took my suggestion too literally ;-)

 

I capitalised some of the text to clearly demarcate it as NEW, rather than the exact text.

 

So that would be:


 * A function that returns a list of 1) a HEADERS frame with END_STREAM
 *( and an empty payload ), and 2) two CONTINUATION frames, the first
 * is empty, and the second contains headers and the END_HEADERS flag.



No need for another webrev.




-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200427/370ede57/attachment.htm>

From vladimir.a.ivanov at intel.com  Mon Apr 27 22:04:49 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Mon, 27 Apr 2020 22:04:49 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
Message-ID: <BYAPR11MB30465072B4B94ACC96146963A7AF0@BYAPR11MB3046.namprd11.prod.outlook.com>

Thanks for the comments. The webrev was updated: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.02/

Only the code was changed here. Changes in the documentation will be discussed separately.

Changes:
1. The LinuxSocketOptions.c was updated according to Vyom comment. 
Note, the 'socketOptionSupported' implemented through the "setsockopt" call that always return error for the read only properties.
It was updated to use 'getsockopt'. The tests set 'test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'
have same run results on RHEL7.7 as clean jdk/jdk workspace. Please, notify me if testing should be extended.

2. The 'IncomingNapiIdSupported0' was renamed to the 'incomingNapiIdSupported0.'

3. The test 'PrintSupportedOptions' was updated to use Set<String> for read only options.

4. The test ExtOptionNAPITest.java was added. Now the test 'ExtOptionTest.java' do nothing with napi id.

 Thanks, Vladimir

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Friday, April 24, 2020 12:09 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

On 23/04/2020 20:11, Ivanov, Vladimir A wrote:
> Thanks a lot to Chris and Alan for detailed comments.
> The updated version of patch available at 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/
>
> Changes:
> 1. in native code the common pattern was used for the 'getsockopt' call.
> 2. condition to define SO_INCOMING_NAPI_ID was added.
> 3. the DatagarmSocket was added to the ExtOptionTest 4. testing on my 
> side was extended to the subset 'test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'.
> Results are same for the patched and non-patched builds on the RHEL7.7 OS.
> Tests test/jdk/java/net/SocketOption/AfterClose.java and 
> test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to support read only properties.
> 5. description for the NAPI_ID was updated 6. the 
> UnsupportedOperationException was added to the 'setOption' call for the 'SO_INCOMING_NAPI_ID'.
>
(Dropping core-libs-dev as net-dev is the more appropriate list for this area).

Thanks for the update.

The updated javadoc looks better but will need a few iterations. It would be good if it could start by explaining what the value of the socket option is, e.g. "The value of this socket option is an Integer representing the network device queue ...". I think it needs to be clearer on the types of sockets that support this option, does it support both stream-oriented and datagram-oriented sockets? Does it return a value when invoked on a ServerSocketChannel? Instead of @throws, the text will need to that attempting to set the socket option will cause UOE to be thrown. Once the javadoc is agreed then the CSR can be submitted and the code review can continue in parallel.

The implementation changes mostly look okay although
IncomingNapiIdSupported0 should probably be renamed to start with lower case "i". Also someone might need to check that you can create an IPv4 socket when a system is configured as an IPv6-only system.

Tests. I think the the new tests in ExtOptionTest will need closer examination as I can't tell how reliable they are. It might be that it needs a completely new test. The update to the NIO PrintSupportedOptions test define READ_ONLY_OPTS as Set<String>.

-Alan

From vladimir.a.ivanov at intel.com  Tue Apr 28 00:33:44 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Tue, 28 Apr 2020 00:33:44 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
Message-ID: <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>

The changes for ADq doc update that includes explanation for this technology:
/**
 * ADQ (Application Device Queues) is an open technology to help address network traffic challenges by improving application
* throughput and latency, and, most importantly, by enabling greater predictability in application response times by creating 
* application specific traffic queuing and steering.
*
* Modern Network Interface Card (NIC) devices have multiple queues or channels to transmit and receive Network packets. ADQ 
* lets each software application reserve subset of these device queues, so that all the traffic, and only the traffic, belonging to the
* application is directed to those set of queues avoiding sharing or competing for network resources with other applications in the
* system. 
*
* System Administrator allocates Network resources to an application in a multi-application environment including set of device 
* queues (Number of Tx/RX queue pairs), dedicated for application traffic. In addition, QoS attributes can be applied to these 
* Application Queues such as Network bandwidth limits & Traffic priority. Device then assigns the incoming application connections
* to these set of queues by defined policies such as round robin. ADQ provides hints to applications, by means of a new socket option
* SO_INCOMING_NAPI_ID, to indicate the device queue from the set of assigned queues, to which an incoming socket connection and
* packets for that connection are directed to.
*
* For a multi-threaded application to take advantage of these dedicated queues, application needs ability to query which queue a 
* connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread. 
* Application then may utilize busy polling to receive and transmit the network packets, minimizing system interrupts and context 
* switches to better align overall system resources to applications. This helps in improved predictability, reduce latency and improve 
* throughput for ADQ enabled Application.  
*
* The value of this SO_INCOMING_NAPI_ID socket option is an Integer, uniquely representing the network device queue on which the 
* last packet of the socket connection is received on. This option is available for both stream-oriented and datagram-oriented sockets 
* on both client and server sockets. The value returned for this socket option will be zero until the socket is connected and has received 
* a network packet, at which point it will be a non-zero integer value. This is a read only option. Attempting to set the socket option will 
* cause UOE to be thrown.
*/

 Thanks, Vladimir

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Friday, April 24, 2020 12:09 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

On 23/04/2020 20:11, Ivanov, Vladimir A wrote:
> Thanks a lot to Chris and Alan for detailed comments.
> The updated version of patch available at 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/
>
> Changes:
> 1. in native code the common pattern was used for the 'getsockopt' call.
> 2. condition to define SO_INCOMING_NAPI_ID was added.
> 3. the DatagarmSocket was added to the ExtOptionTest 4. testing on my 
> side was extended to the subset 'test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net'.
> Results are same for the patched and non-patched builds on the RHEL7.7 OS.
> Tests test/jdk/java/net/SocketOption/AfterClose.java and 
> test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated to support read only properties.
> 5. description for the NAPI_ID was updated 6. the 
> UnsupportedOperationException was added to the 'setOption' call for the 'SO_INCOMING_NAPI_ID'.
>
(Dropping core-libs-dev as net-dev is the more appropriate list for this area).

Thanks for the update.

The updated javadoc looks better but will need a few iterations. It would be good if it could start by explaining what the value of the socket option is, e.g. "The value of this socket option is an Integer representing the network device queue ...". I think it needs to be clearer on the types of sockets that support this option, does it support both stream-oriented and datagram-oriented sockets? Does it return a value when invoked on a ServerSocketChannel? Instead of @throws, the text will need to that attempting to set the socket option will cause UOE to be thrown. Once the javadoc is agreed then the CSR can be submitted and the code review can continue in parallel.

The implementation changes mostly look okay although
IncomingNapiIdSupported0 should probably be renamed to start with lower case "i". Also someone might need to check that you can create an IPv4 socket when a system is configured as an IPv6-only system.

Tests. I think the the new tests in ExtOptionTest will need closer examination as I can't tell how reliable they are. It might be that it needs a completely new test. The update to the NIO PrintSupportedOptions test define READ_ONLY_OPTS as Set<String>.

-Alan

From vyommani at gmail.com  Tue Apr 28 02:37:39 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Tue, 28 Apr 2020 08:07:39 +0530
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB30465072B4B94ACC96146963A7AF0@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB30465072B4B94ACC96146963A7AF0@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <CAKysZ8xAFMEOT9gccaBxxzom7Ad65BuikVuuWwR6WPShLuo21w@mail.gmail.com>

Hi Vladimir,

changes looks much better now, i still see that
function(IncomingNapiIdSupported) & variable(IncomingNapiIdOptSupported)
does not follow Java naming convention.

   private static final boolean IncomingNapiIdOptSupported  =+
   platformSocketOptions.IncomingNapiIdSupported();

Thanks,
Vyom

On Tue, Apr 28, 2020 at 3:36 AM Ivanov, Vladimir A <
vladimir.a.ivanov at intel.com> wrote:

> Thanks for the comments. The webrev was updated:
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.02/
>
> Only the code was changed here. Changes in the documentation will be
> discussed separately.
>
> Changes:
> 1. The LinuxSocketOptions.c was updated according to Vyom comment.
> Note, the 'socketOptionSupported' implemented through the "setsockopt"
> call that always return error for the read only properties.
> It was updated to use 'getsockopt'. The tests set 'test/jdk/java/net
> test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net
> test/jdk/sun/net'
> have same run results on RHEL7.7 as clean jdk/jdk workspace. Please,
> notify me if testing should be extended.
>
> 2. The 'IncomingNapiIdSupported0' was renamed to the
> 'incomingNapiIdSupported0.'
>
> 3. The test 'PrintSupportedOptions' was updated to use Set<String> for
> read only options.
>
> 4. The test ExtOptionNAPITest.java was added. Now the test
> 'ExtOptionTest.java' do nothing with napi id.
>
>  Thanks, Vladimir
>
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Friday, April 24, 2020 12:09 AM
> To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev
> list <net-dev at openjdk.java.net>
> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK
>
> On 23/04/2020 20:11, Ivanov, Vladimir A wrote:
> > Thanks a lot to Chris and Alan for detailed comments.
> > The updated version of patch available at
> > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.01/
> >
> > Changes:
> > 1. in native code the common pattern was used for the 'getsockopt' call.
> > 2. condition to define SO_INCOMING_NAPI_ID was added.
> > 3. the DatagarmSocket was added to the ExtOptionTest 4. testing on my
> > side was extended to the subset 'test/jdk/java/net
> test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net
> test/jdk/sun/net'.
> > Results are same for the patched and non-patched builds on the RHEL7.7
> OS.
> > Tests test/jdk/java/net/SocketOption/AfterClose.java and
> > test/jdk/java/nio/channels/etc/PrintSupportedOptions.java were updated
> to support read only properties.
> > 5. description for the NAPI_ID was updated 6. the
> > UnsupportedOperationException was added to the 'setOption' call for the
> 'SO_INCOMING_NAPI_ID'.
> >
> (Dropping core-libs-dev as net-dev is the more appropriate list for this
> area).
>
> Thanks for the update.
>
> The updated javadoc looks better but will need a few iterations. It would
> be good if it could start by explaining what the value of the socket option
> is, e.g. "The value of this socket option is an Integer representing the
> network device queue ...". I think it needs to be clearer on the types of
> sockets that support this option, does it support both stream-oriented and
> datagram-oriented sockets? Does it return a value when invoked on a
> ServerSocketChannel? Instead of @throws, the text will need to that
> attempting to set the socket option will cause UOE to be thrown. Once the
> javadoc is agreed then the CSR can be submitted and the code review can
> continue in parallel.
>
> The implementation changes mostly look okay although
> IncomingNapiIdSupported0 should probably be renamed to start with lower
> case "i". Also someone might need to check that you can create an IPv4
> socket when a system is configured as an IPv6-only system.
>
> Tests. I think the the new tests in ExtOptionTest will need closer
> examination as I can't tell how reliable they are. It might be that it
> needs a completely new test. The update to the NIO PrintSupportedOptions
> test define READ_ONLY_OPTS as Set<String>.
>
> -Alan
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200428/c26fd079/attachment-0001.htm>

From patrick.concannon at oracle.com  Tue Apr 28 09:33:08 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 28 Apr 2020 10:33:08 +0100
Subject: =?UTF-8?Q?RFR=5b8243507=5d=3a_=27DatagramSocket_constructors_don?=
 =?UTF-8?Q?=e2=80=99t_always_specify_what_happens_when_passed_invalid_parame?=
 =?UTF-8?Q?ters=27?=
Message-ID: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>

Hi,

Could someone please review my fix for JDK-8243507 'DatagramSocket 
constructors don?t always specify what happens when passed invalid 
parameters'?

Currently, the DatagramSocket constructor `DatagramSocket(SocketAddress 
bindaddr)` doesn't specify what happens if passed a SocketAddress 
subclass not supported by this socket.
Also, there are two DatagramSocket constructors that accept a port 
number, but neither constructor specifies what happens when passed port 
0, or a port which falls outside of the valid range of port numbers i.e 
between 0 and 65535 inclusive.

This fix updates the spec for each these constructors to inform the user 
of what happens when passed an invalid argument. For the constructors 
that take a port, the spec will now specify that an 
IllegalArgumentException is thrown when passed a port outside of the 
acceptable range, or, if zero is passed, that the system will choose an 
appropriate port for them. For the constructor that takes a 
SocketAddress, an IllegalArgumentException will be thrown if an invalid 
SocketAddress subclass is passed as a parameter.

bug: https://bugs.openjdk.java.net/browse/JDK-8243507
csr: https://bugs.openjdk.java.net/browse/JDK-8243976
webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.00/


Kind regards,

Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200428/f989a2ed/attachment.htm>

From daniel.fuchs at oracle.com  Tue Apr 28 15:32:08 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 28 Apr 2020 16:32:08 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8243507=5d=3a_=27DatagramSocket_constructors_?=
 =?UTF-8?Q?don=e2=80=99t_always_specify_what_happens_when_passed_invalid_par?=
 =?UTF-8?Q?ameters=27?=
In-Reply-To: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>
References: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>
Message-ID: <fab48124-bcfb-cbbc-6482-0075f024e01b@oracle.com>

Hi Patrick,

Looks good to me.
I realize we haven't specified what happens if the `laddr` is null.
Are you planning to fix that in a separate changeset or tag it to
this one?

Maybe we should unify the description of the `port` parameter in
the two constructors:

  327      * @param      port port to use.
  357      * @param port local port to use

Maybe:

           * @param port local port to use in the bind operation.

Nit: It's customary to break line before <p>:

  343      * address.  <p><a id="PortRange"></a>The local port must be 
between 0 and

suggest:

  343      * address.
           * <p><a id="PortRange"></a>The local port must be

best regards,

-- daniel

On 28/04/2020 10:33, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my fix for JDK-8243507 'DatagramSocket 
> constructors don?t always specify what happens when passed invalid 
> parameters'?
> 
> Currently, the DatagramSocket constructor `DatagramSocket(SocketAddress 
> bindaddr)` doesn't specify what happens if passed a SocketAddress 
> subclass not supported by this socket.
> Also, there are two DatagramSocket constructors that accept a port 
> number, but neither constructor specifies what happens when passed port 
> 0, or a port which falls outside of the valid range of port numbers i.e 
> between 0 and 65535 inclusive.
> 
> This fix updates the spec for each these constructors to inform the user 
> of what happens when passed an invalid argument. For the constructors 
> that take a port, the spec will now specify that an 
> IllegalArgumentException is thrown when passed a port outside of the 
> acceptable range, or, if zero is passed, that the system will choose an 
> appropriate port for them. For the constructor that takes a 
> SocketAddress, an IllegalArgumentException will be thrown if an invalid 
> SocketAddress subclass is passed as a parameter.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8243507
> csr: https://bugs.openjdk.java.net/browse/JDK-8243976
> webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.00/
> 
> 
> Kind regards,
> 
> Patrick
> 


From macanaoire at hotmail.com  Wed Apr 29 13:57:56 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 29 Apr 2020 13:57:56 +0000
Subject: =?Windows-1252?Q?Re:_RFR[8243507]:_'DatagramSocket_constructors_don=92t_a?=
 =?Windows-1252?Q?lways_specify_what_happens_when_passed_invalid_parameter?=
 =?Windows-1252?Q?s'?=
In-Reply-To: <fab48124-bcfb-cbbc-6482-0075f024e01b@oracle.com>
References: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>,
 <fab48124-bcfb-cbbc-6482-0075f024e01b@oracle.com>
Message-ID: <DBBPR09MB3014A12A1FD6C7178BDFD651DFAD0@DBBPR09MB3014.eurprd09.prod.outlook.com>


Hi Daniel, Patrick,
    I wonder is there an opportunity here to refine the constructor descriptions a
little, also

The wording associated with wildcard addressing includes

* an IP address chosen by the kernel.

which is not actually correct, and maybe it should be omitted from
the various constructor descriptions.

there is explicit reference to IPv4 INADDR_ANY (0.0.0.0) which may warrant
a rewording to more general wildcard address {@link InetAddress#isAnyLocalAddress}

I think the following wording was proposed offline
changing


* If the IP address is 0.0.0.0, the socket will be bound to the

* {@link InetAddress#isAnyLocalAddress wildcard} address,

* an IP address chosen by the kernel.


to


* If the IP address is a {@link InetAddress#isAnyLocalAddress wildcard} address

* (or is {@code null}), the socket will be bound to the wildcard address.

also changing


The socket will be bound to the

{@link InetAddress#isAnyLocalAddress wildcard} address,

an IP address chosen by the kernel.


to


The socket will be bound to the

{@link InetAddress#isAnyLocalAddress wildcard} address.


best regards
Mark



________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Tuesday 28 April 2020 15:32
To: Patrick Concannon <patrick.concannon at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR[8243507]: 'DatagramSocket constructors don?t always specify what happens when passed invalid parameters'

Hi Patrick,

Looks good to me.
I realize we haven't specified what happens if the `laddr` is null.
Are you planning to fix that in a separate changeset or tag it to
this one?

Maybe we should unify the description of the `port` parameter in
the two constructors:

  327      * @param      port port to use.
  357      * @param port local port to use

Maybe:

           * @param port local port to use in the bind operation.

Nit: It's customary to break line before <p>:

  343      * address.  <p><a id="PortRange"></a>The local port must be
between 0 and

suggest:

  343      * address.
           * <p><a id="PortRange"></a>The local port must be

best regards,

-- daniel

On 28/04/2020 10:33, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8243507 'DatagramSocket
> constructors don?t always specify what happens when passed invalid
> parameters'?
>
> Currently, the DatagramSocket constructor `DatagramSocket(SocketAddress
> bindaddr)` doesn't specify what happens if passed a SocketAddress
> subclass not supported by this socket.
> Also, there are two DatagramSocket constructors that accept a port
> number, but neither constructor specifies what happens when passed port
> 0, or a port which falls outside of the valid range of port numbers i.e
> between 0 and 65535 inclusive.
>
> This fix updates the spec for each these constructors to inform the user
> of what happens when passed an invalid argument. For the constructors
> that take a port, the spec will now specify that an
> IllegalArgumentException is thrown when passed a port outside of the
> acceptable range, or, if zero is passed, that the system will choose an
> appropriate port for them. For the constructor that takes a
> SocketAddress, an IllegalArgumentException will be thrown if an invalid
> SocketAddress subclass is passed as a parameter.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8243507
> csr: https://bugs.openjdk.java.net/browse/JDK-8243976
> webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.00/
>
>
> Kind regards,
>
> Patrick
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200429/cedc75e3/attachment.htm>

From Alan.Bateman at oracle.com  Wed Apr 29 15:53:52 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Apr 2020 16:53:52 +0100
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>

On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> The changes for ADq doc update that includes explanation for this technology:
> /**
>   * ADQ (Application Device Queues) is an open technology to help address network traffic challenges by improving application
> * throughput and latency, and, most importantly, by enabling greater predictability in application response times by creating
> * application specific traffic queuing and steering.
> *
> * Modern Network Interface Card (NIC) devices have multiple queues or channels to transmit and receive Network packets. ADQ
> * lets each software application reserve subset of these device queues, so that all the traffic, and only the traffic, belonging to the
> * application is directed to those set of queues avoiding sharing or competing for network resources with other applications in the
> * system.
> *
> * System Administrator allocates Network resources to an application in a multi-application environment including set of device
> * queues (Number of Tx/RX queue pairs), dedicated for application traffic. In addition, QoS attributes can be applied to these
> * Application Queues such as Network bandwidth limits & Traffic priority. Device then assigns the incoming application connections
> * to these set of queues by defined policies such as round robin. ADQ provides hints to applications, by means of a new socket option
> * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of assigned queues, to which an incoming socket connection and
> * packets for that connection are directed to.
> *
> * For a multi-threaded application to take advantage of these dedicated queues, application needs ability to query which queue a
> * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread.
> * Application then may utilize busy polling to receive and transmit the network packets, minimizing system interrupts and context
> * switches to better align overall system resources to applications. This helps in improved predictability, reduce latency and improve
> * throughput for ADQ enabled Application.
> *
> * The value of this SO_INCOMING_NAPI_ID socket option is an Integer, uniquely representing the network device queue on which the
> * last packet of the socket connection is received on. This option is available for both stream-oriented and datagram-oriented sockets
> * on both client and server sockets. The value returned for this socket option will be zero until the socket is connected and has received
> * a network packet, at which point it will be a non-zero integer value. This is a read only option. Attempting to set the socket option will
> * cause UOE to be thrown.
> *

What would you think about starting with something like"

"Identifies the receive queue that the last incoming packet for the 
socket was received on.

The value of this socket option is an Integer that identifies a receive 
queue that can application can use to split the incoming flows among 
threads based on the receive queue.

The socket option is read-only and any attempt to set the socket option 
will throw UnsupportedOperationException.
The socket option is supported by both stream and datagram oriented 
sockets. The value of the socket option is 0 when the socket is not 
bound or a packet has not been received."

We could add an additional note to explain further how it might work on 
Linux that would use some of the text that you have in your mail.

-Alan.


From ecki at zusammenkunft.net  Wed Apr 29 16:19:23 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 29 Apr 2020 16:19:23 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>,
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
Message-ID: <AM6PR03MB4389C0F24616AE07A7204FA1FFAD0@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

If you query the queue Id from a central dispatcher thread is there any benefit in knowing that ID as the context change already happens. So without being able to bind a thread for accepting to such a queue (which might not be so easy with emulated async NIO) this api feature seems to not be particular useful for a java app? (And with a bound thread you probably don't need to id either as you just go on and process it)?


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Alan Bateman <Alan.Bateman at oracle.com>
Gesendet: Wednesday, April 29, 2020 5:53:52 PM
An: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Betreff: Re: RFR 15 8243099: Adding ADQ support to JDK

On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> The changes for ADq doc update that includes explanation for this technology:
> /**
>   * ADQ (Application Device Queues) is an open technology to help address network traffic challenges by improving application
> * throughput and latency, and, most importantly, by enabling greater predictability in application response times by creating
> * application specific traffic queuing and steering.
> *
> * Modern Network Interface Card (NIC) devices have multiple queues or channels to transmit and receive Network packets. ADQ
> * lets each software application reserve subset of these device queues, so that all the traffic, and only the traffic, belonging to the
> * application is directed to those set of queues avoiding sharing or competing for network resources with other applications in the
> * system.
> *
> * System Administrator allocates Network resources to an application in a multi-application environment including set of device
> * queues (Number of Tx/RX queue pairs), dedicated for application traffic. In addition, QoS attributes can be applied to these
> * Application Queues such as Network bandwidth limits & Traffic priority. Device then assigns the incoming application connections
> * to these set of queues by defined policies such as round robin. ADQ provides hints to applications, by means of a new socket option
> * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of assigned queues, to which an incoming socket connection and
> * packets for that connection are directed to.
> *
> * For a multi-threaded application to take advantage of these dedicated queues, application needs ability to query which queue a
> * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread.
> * Application then may utilize busy polling to receive and transmit the network packets, minimizing system interrupts and context
> * switches to better align overall system resources to applications. This helps in improved predictability, reduce latency and improve
> * throughput for ADQ enabled Application.
> *
> * The value of this SO_INCOMING_NAPI_ID socket option is an Integer, uniquely representing the network device queue on which the
> * last packet of the socket connection is received on. This option is available for both stream-oriented and datagram-oriented sockets
> * on both client and server sockets. The value returned for this socket option will be zero until the socket is connected and has received
> * a network packet, at which point it will be a non-zero integer value. This is a read only option. Attempting to set the socket option will
> * cause UOE to be thrown.
> *

What would you think about starting with something like"

"Identifies the receive queue that the last incoming packet for the
socket was received on.

The value of this socket option is an Integer that identifies a receive
queue that can application can use to split the incoming flows among
threads based on the receive queue.

The socket option is read-only and any attempt to set the socket option
will throw UnsupportedOperationException.
The socket option is supported by both stream and datagram oriented
sockets. The value of the socket option is 0 when the socket is not
bound or a packet has not been received."

We could add an additional note to explain further how it might work on
Linux that would use some of the text that you have in your mail.

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200429/a911c42f/attachment-0001.htm>

From vladimir.a.ivanov at intel.com  Wed Apr 29 18:11:49 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Wed, 29 Apr 2020 18:11:49 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
Message-ID: <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>

Updated version of the webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/

The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.

Changes:
1. comment was updated
2. names were adjusted with convention (IncomingNapiIdOptSupported  => incomingNapiIdOptSupported, IncomingNapiIdSupported => IncomingNapiIdSupported);

 Thanks, Vladimir

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Wednesday, April 29, 2020 8:54 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> The changes for ADq doc update that includes explanation for this technology:
> /**
>   * ADQ (Application Device Queues) is an open technology to help 
> address network traffic challenges by improving application
> * throughput and latency, and, most importantly, by enabling greater 
> predictability in application response times by creating
> * application specific traffic queuing and steering.
> *
> * Modern Network Interface Card (NIC) devices have multiple queues or 
> channels to transmit and receive Network packets. ADQ
> * lets each software application reserve subset of these device 
> queues, so that all the traffic, and only the traffic, belonging to 
> the
> * application is directed to those set of queues avoiding sharing or 
> competing for network resources with other applications in the
> * system.
> *
> * System Administrator allocates Network resources to an application 
> in a multi-application environment including set of device
> * queues (Number of Tx/RX queue pairs), dedicated for application 
> traffic. In addition, QoS attributes can be applied to these
> * Application Queues such as Network bandwidth limits & Traffic 
> priority. Device then assigns the incoming application connections
> * to these set of queues by defined policies such as round robin. ADQ 
> provides hints to applications, by means of a new socket option
> * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of 
> assigned queues, to which an incoming socket connection and
> * packets for that connection are directed to.
> *
> * For a multi-threaded application to take advantage of these 
> dedicated queues, application needs ability to query which queue a
> * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread.
> * Application then may utilize busy polling to receive and transmit 
> the network packets, minimizing system interrupts and context
> * switches to better align overall system resources to applications. 
> This helps in improved predictability, reduce latency and improve
> * throughput for ADQ enabled Application.
> *
> * The value of this SO_INCOMING_NAPI_ID socket option is an Integer, 
> uniquely representing the network device queue on which the
> * last packet of the socket connection is received on. This option is 
> available for both stream-oriented and datagram-oriented sockets
> * on both client and server sockets. The value returned for this 
> socket option will be zero until the socket is connected and has 
> received
> * a network packet, at which point it will be a non-zero integer 
> value. This is a read only option. Attempting to set the socket option 
> will
> * cause UOE to be thrown.
> *

What would you think about starting with something like"

"Identifies the receive queue that the last incoming packet for the socket was received on.

The value of this socket option is an Integer that identifies a receive queue that can application can use to split the incoming flows among threads based on the receive queue.

The socket option is read-only and any attempt to set the socket option will throw UnsupportedOperationException.
The socket option is supported by both stream and datagram oriented sockets. The value of the socket option is 0 when the socket is not bound or a packet has not been received."

We could add an additional note to explain further how it might work on Linux that would use some of the text that you have in your mail.

-Alan.


From vladimir.a.ivanov at intel.com  Wed Apr 29 18:18:38 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Wed, 29 Apr 2020 18:18:38 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <AM6PR03MB4389C0F24616AE07A7204FA1FFAD0@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>,
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
 <AM6PR03MB4389C0F24616AE07A7204FA1FFAD0@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <BYAPR11MB3046F80AB410C11D4F304CE9A7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>

Most applications, for example web servers, kafka, Netty etc, have one master thread and multiple worker threads to service incoming connections. Master thread accept these connections and dispatch to one of the worker threads using some load balancing policies like round/robin,. With this new socket option all connections received on a single device queue will be dispatched to same worker thread in the application. Master thread accept the incoming connection and make a call to this socket option for child socket and assign the child socket to the thread associated with the queue. That way application worker threads can poll for more packets from the queue when it is ready to service the packets from network and the traffic on other queue/threads can be processed independently. Socket option is called on child socket giving the queue ID associated the new connection, not with this central dispatcher socket.

Thanks, Vladimir

From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Bernd Eckenfels
Sent: Wednesday, April 29, 2020 9:19 AM
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK

Hello,

If you query the queue Id from a central dispatcher thread is there any benefit in knowing that ID as the context change already happens. So without being able to bind a thread for accepting to such a queue (which might not be so easy with emulated async NIO) this api feature seems to not be particular useful for a java app? (And with a bound thread you probably don't need to id either as you just go on and process it)?


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-bounces at openjdk.java.net<mailto:net-dev-bounces at openjdk.java.net>> im Auftrag von Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>
Gesendet: Wednesday, April 29, 2020 5:53:52 PM
An: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com<mailto:vladimir.a.ivanov at intel.com>>; OpenJDK Network Dev list <net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>>
Betreff: Re: RFR 15 8243099: Adding ADQ support to JDK

On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> The changes for ADq doc update that includes explanation for this technology:
> /**
>   * ADQ (Application Device Queues) is an open technology to help address network traffic challenges by improving application
> * throughput and latency, and, most importantly, by enabling greater predictability in application response times by creating
> * application specific traffic queuing and steering.
> *
> * Modern Network Interface Card (NIC) devices have multiple queues or channels to transmit and receive Network packets. ADQ
> * lets each software application reserve subset of these device queues, so that all the traffic, and only the traffic, belonging to the
> * application is directed to those set of queues avoiding sharing or competing for network resources with other applications in the
> * system.
> *
> * System Administrator allocates Network resources to an application in a multi-application environment including set of device
> * queues (Number of Tx/RX queue pairs), dedicated for application traffic. In addition, QoS attributes can be applied to these
> * Application Queues such as Network bandwidth limits & Traffic priority. Device then assigns the incoming application connections
> * to these set of queues by defined policies such as round robin. ADQ provides hints to applications, by means of a new socket option
> * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of assigned queues, to which an incoming socket connection and
> * packets for that connection are directed to.
> *
> * For a multi-threaded application to take advantage of these dedicated queues, application needs ability to query which queue a
> * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread.
> * Application then may utilize busy polling to receive and transmit the network packets, minimizing system interrupts and context
> * switches to better align overall system resources to applications. This helps in improved predictability, reduce latency and improve
> * throughput for ADQ enabled Application.
> *
> * The value of this SO_INCOMING_NAPI_ID socket option is an Integer, uniquely representing the network device queue on which the
> * last packet of the socket connection is received on. This option is available for both stream-oriented and datagram-oriented sockets
> * on both client and server sockets. The value returned for this socket option will be zero until the socket is connected and has received
> * a network packet, at which point it will be a non-zero integer value. This is a read only option. Attempting to set the socket option will
> * cause UOE to be thrown.
> *

What would you think about starting with something like"

"Identifies the receive queue that the last incoming packet for the
socket was received on.

The value of this socket option is an Integer that identifies a receive
queue that can application can use to split the incoming flows among
threads based on the receive queue.

The socket option is read-only and any attempt to set the socket option
will throw UnsupportedOperationException.
The socket option is supported by both stream and datagram oriented
sockets. The value of the socket option is 0 when the socket is not
bound or a packet has not been received."

We could add an additional note to explain further how it might work on
Linux that would use some of the text that you have in your mail.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200429/3d79c285/attachment-0001.htm>

From Roger.Riggs at oracle.com  Wed Apr 29 18:22:39 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 Apr 2020 14:22:39 -0400
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
 <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <0fcd519a-49e2-6e4f-4e6c-166e87e33a73@oracle.com>

Hi Ivan,

Minor editorial suggestion in ExtendedSocketOptions.java:177
 ?? ...that +an+ application can use...

$.02, Roger

On 4/29/20 2:11 PM, Ivanov, Vladimir A wrote:
> Updated version of the webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  => incomingNapiIdOptSupported, IncomingNapiIdSupported => IncomingNapiIdSupported);
>
>   Thanks, Vladimir
>
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Wednesday, April 29, 2020 8:54 AM
> To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK
>
> On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
>> The changes for ADq doc update that includes explanation for this technology:
>> /**
>>    * ADQ (Application Device Queues) is an open technology to help
>> address network traffic challenges by improving application
>> * throughput and latency, and, most importantly, by enabling greater
>> predictability in application response times by creating
>> * application specific traffic queuing and steering.
>> *
>> * Modern Network Interface Card (NIC) devices have multiple queues or
>> channels to transmit and receive Network packets. ADQ
>> * lets each software application reserve subset of these device
>> queues, so that all the traffic, and only the traffic, belonging to
>> the
>> * application is directed to those set of queues avoiding sharing or
>> competing for network resources with other applications in the
>> * system.
>> *
>> * System Administrator allocates Network resources to an application
>> in a multi-application environment including set of device
>> * queues (Number of Tx/RX queue pairs), dedicated for application
>> traffic. In addition, QoS attributes can be applied to these
>> * Application Queues such as Network bandwidth limits & Traffic
>> priority. Device then assigns the incoming application connections
>> * to these set of queues by defined policies such as round robin. ADQ
>> provides hints to applications, by means of a new socket option
>> * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of
>> assigned queues, to which an incoming socket connection and
>> * packets for that connection are directed to.
>> *
>> * For a multi-threaded application to take advantage of these
>> dedicated queues, application needs ability to query which queue a
>> * connection is assigned to, so all socket connections from a specific device queue can be serviced by a single application thread.
>> * Application then may utilize busy polling to receive and transmit
>> the network packets, minimizing system interrupts and context
>> * switches to better align overall system resources to applications.
>> This helps in improved predictability, reduce latency and improve
>> * throughput for ADQ enabled Application.
>> *
>> * The value of this SO_INCOMING_NAPI_ID socket option is an Integer,
>> uniquely representing the network device queue on which the
>> * last packet of the socket connection is received on. This option is
>> available for both stream-oriented and datagram-oriented sockets
>> * on both client and server sockets. The value returned for this
>> socket option will be zero until the socket is connected and has
>> received
>> * a network packet, at which point it will be a non-zero integer
>> value. This is a read only option. Attempting to set the socket option
>> will
>> * cause UOE to be thrown.
>> *
> What would you think about starting with something like"
>
> "Identifies the receive queue that the last incoming packet for the socket was received on.
>
> The value of this socket option is an Integer that identifies a receive queue that can application can use to split the incoming flows among threads based on the receive queue.
>
> The socket option is read-only and any attempt to set the socket option will throw UnsupportedOperationException.
> The socket option is supported by both stream and datagram oriented sockets. The value of the socket option is 0 when the socket is not bound or a packet has not been received."
>
> We could add an additional note to explain further how it might work on Linux that would use some of the text that you have in your mail.
>
> -Alan.
>


From patrick.concannon at oracle.com  Wed Apr 29 20:08:29 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 29 Apr 2020 21:08:29 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8243507=5d=3a_=27DatagramSocket_constructors_?=
 =?UTF-8?Q?don=e2=80=99t_always_specify_what_happens_when_passed_invalid_par?=
 =?UTF-8?Q?ameters=27?=
In-Reply-To: <DBBPR09MB3014A12A1FD6C7178BDFD651DFAD0@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>
 <fab48124-bcfb-cbbc-6482-0075f024e01b@oracle.com>
 <DBBPR09MB3014A12A1FD6C7178BDFD651DFAD0@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <34c074e5-b0ee-bb03-988f-d40458ad72ca@oracle.com>

Hi Daniel and Mark,


WRT what happens when `laddr` is null: it has been filed as a separate 
issue, i.e. JDK-8243999 
<https://bugs.openjdk.java.net/browse/JDK-8243999>, and has been 
assigned to me.
Thanks for the wording suggestions, Mark. I will take a closer look once 
this patch is out of the way.

Daniel:Thanks for your suggestions. Well spotted with regards to the 
port. I've incorporated your comments into the patch, and you can find 
them in the new webrev below.


webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.01/


Kind regards,

Patrick


On 29/04/2020 14:57, mark sheppard wrote:
>
> Hi Daniel, Patrick,
> ? ? I wonder is there an opportunity here to refine the constructor 
> descriptions a
> little, also
>
> The wording associated with wildcard addressing includes
> * an IP address chosen by the kernel.
> which is not actually correct, and maybe it should be omitted from
> the various constructor descriptions.
>
> there is explicit reference to IPv4 INADDR_ANY (0.0.0.0) which may warrant
> a rewording to more general wildcard address {@link 
> InetAddress#isAnyLocalAddress}
>
> I think the following wording was proposed offline
> changing
>
> * If the IP address is 0.0.0.0, the socket will be bound to the
>
> * {@link InetAddress#isAnyLocalAddress wildcard} address,
>
> * an IP address chosen by the kernel.
>
>
> to
>
>
> * If the IP address is a {@link InetAddress#isAnyLocalAddress 
> wildcard} address
>
> * (or is {@code null}), the socket will be bound to the wildcard address.
>
>
> also changing
>
> The socket will be bound to the
>
> {@link InetAddress#isAnyLocalAddress wildcard} address,
>
> an IP address chosen by the kernel.
>
>
> to
>
>
> The socket will be bound to the
>
> {@link InetAddress#isAnyLocalAddress wildcard} address.
>
>
>
> best regards
> Mark
>
>
>
> ------------------------------------------------------------------------
> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of Daniel 
> Fuchs <daniel.fuchs at oracle.com>
> *Sent:* Tuesday 28 April 2020 15:32
> *To:* Patrick Concannon <patrick.concannon at oracle.com>; OpenJDK 
> Network Dev list <net-dev at openjdk.java.net>
> *Subject:* Re: RFR[8243507]: 'DatagramSocket constructors don?t always 
> specify what happens when passed invalid parameters'
> Hi Patrick,
>
> Looks good to me.
> I realize we haven't specified what happens if the `laddr` is null.
> Are you planning to fix that in a separate changeset or tag it to
> this one?
>
> Maybe we should unify the description of the `port` parameter in
> the two constructors:
>
> ? 327????? * @param????? port port to use.
> ? 357????? * @param port local port to use
>
> Maybe:
>
> ?????????? * @param port local port to use in the bind operation.
>
> Nit: It's customary to break line before <p>:
>
> ? 343????? * address.? <p><a id="PortRange"></a>The local port must be
> between 0 and
>
> suggest:
>
> ? 343????? * address.
> ?????????? * <p><a id="PortRange"></a>The local port must be
>
> best regards,
>
> -- daniel
>
> On 28/04/2020 10:33, Patrick Concannon wrote:
> > Hi,
> >
> > Could someone please review my fix for JDK-8243507 'DatagramSocket
> > constructors don?t always specify what happens when passed invalid
> > parameters'?
> >
> > Currently, the DatagramSocket constructor `DatagramSocket(SocketAddress
> > bindaddr)` doesn't specify what happens if passed a SocketAddress
> > subclass not supported by this socket.
> > Also, there are two DatagramSocket constructors that accept a port
> > number, but neither constructor specifies what happens when passed port
> > 0, or a port which falls outside of the valid range of port numbers i.e
> > between 0 and 65535 inclusive.
> >
> > This fix updates the spec for each these constructors to inform the 
> user
> > of what happens when passed an invalid argument. For the constructors
> > that take a port, the spec will now specify that an
> > IllegalArgumentException is thrown when passed a port outside of the
> > acceptable range, or, if zero is passed, that the system will choose an
> > appropriate port for them. For the constructor that takes a
> > SocketAddress, an IllegalArgumentException will be thrown if an invalid
> > SocketAddress subclass is passed as a parameter.
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8243507
> > csr: https://bugs.openjdk.java.net/browse/JDK-8243976
> > webrev: 
> http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.00/
> >
> >
> > Kind regards,
> >
> > Patrick
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200429/fdebf685/attachment.htm>

From daniel.fuchs at oracle.com  Wed Apr 29 20:27:51 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Apr 2020 21:27:51 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8243507=5d=3a_=27DatagramSocket_constructors_?=
 =?UTF-8?Q?don=e2=80=99t_always_specify_what_happens_when_passed_invalid_par?=
 =?UTF-8?Q?ameters=27?=
In-Reply-To: <34c074e5-b0ee-bb03-988f-d40458ad72ca@oracle.com>
References: <369eadbf-1a1f-b999-921d-3e0483e66abf@oracle.com>
 <fab48124-bcfb-cbbc-6482-0075f024e01b@oracle.com>
 <DBBPR09MB3014A12A1FD6C7178BDFD651DFAD0@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <34c074e5-b0ee-bb03-988f-d40458ad72ca@oracle.com>
Message-ID: <a6dea017-f74f-9deb-a658-85a80e12b370@oracle.com>

On 29/04/2020 21:08, Patrick Concannon wrote:
> webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.01/

Thanks Patrick. LGTM.

Pedantically, this test might temporarily leak instances
of DatagramSocket when it detects a bug. That is, for
instance - in the case where `new DatagramSocket(-1)`
were buggy and would not throw. But as I'm confident that
should never happen, and as modifying the test to cater
for that would be quite ugly, let's leave it as is.

best regards,

-- daniel


From vyommani at gmail.com  Thu Apr 30 03:09:22 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Thu, 30 Apr 2020 08:39:22 +0530
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
 <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <CAKysZ8y6eGYVLu45qyG00qE-dWosNsXET1U-xUBFCGXjG+fhfA@mail.gmail.com>

Hi Vladimir,

Latest webrev(03) looks ok to me , one minor  bit, method signature(Signature:
(I)I;) is not  correct in incomingNapiIdSupported0.

Thanks,
Vyom

++/*+ * Class:     jdk_net_LinuxSocketOptions+ * Method:
incomingNapiIdSupported0+ * Signature: (I)I;+ */+JNIEXPORT jboolean
JNICALL Java_jdk_net_LinuxSocketOptions_incomingNapiIdSupported0+(JNIEnv
*env, jobject unused) {+    return socketOptionSupported(SOL_SOCKET,
SO_INCOMING_NAPI_ID);+}


On Wed, Apr 29, 2020 at 11:44 PM Ivanov, Vladimir A <
vladimir.a.ivanov at intel.com> wrote:

> Updated version of the webrev available as
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net
> test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net
> test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  =>
> incomingNapiIdOptSupported, IncomingNapiIdSupported =>
> IncomingNapiIdSupported);
>
>  Thanks, Vladimir
>
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Wednesday, April 29, 2020 8:54 AM
> To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev
> list <net-dev at openjdk.java.net>
> Subject: Re: RFR 15 8243099: Adding ADQ support to JDK
>
> On 28/04/2020 01:33, Ivanov, Vladimir A wrote:
> > The changes for ADq doc update that includes explanation for this
> technology:
> > /**
> >   * ADQ (Application Device Queues) is an open technology to help
> > address network traffic challenges by improving application
> > * throughput and latency, and, most importantly, by enabling greater
> > predictability in application response times by creating
> > * application specific traffic queuing and steering.
> > *
> > * Modern Network Interface Card (NIC) devices have multiple queues or
> > channels to transmit and receive Network packets. ADQ
> > * lets each software application reserve subset of these device
> > queues, so that all the traffic, and only the traffic, belonging to
> > the
> > * application is directed to those set of queues avoiding sharing or
> > competing for network resources with other applications in the
> > * system.
> > *
> > * System Administrator allocates Network resources to an application
> > in a multi-application environment including set of device
> > * queues (Number of Tx/RX queue pairs), dedicated for application
> > traffic. In addition, QoS attributes can be applied to these
> > * Application Queues such as Network bandwidth limits & Traffic
> > priority. Device then assigns the incoming application connections
> > * to these set of queues by defined policies such as round robin. ADQ
> > provides hints to applications, by means of a new socket option
> > * SO_INCOMING_NAPI_ID, to indicate the device queue from the set of
> > assigned queues, to which an incoming socket connection and
> > * packets for that connection are directed to.
> > *
> > * For a multi-threaded application to take advantage of these
> > dedicated queues, application needs ability to query which queue a
> > * connection is assigned to, so all socket connections from a specific
> device queue can be serviced by a single application thread.
> > * Application then may utilize busy polling to receive and transmit
> > the network packets, minimizing system interrupts and context
> > * switches to better align overall system resources to applications.
> > This helps in improved predictability, reduce latency and improve
> > * throughput for ADQ enabled Application.
> > *
> > * The value of this SO_INCOMING_NAPI_ID socket option is an Integer,
> > uniquely representing the network device queue on which the
> > * last packet of the socket connection is received on. This option is
> > available for both stream-oriented and datagram-oriented sockets
> > * on both client and server sockets. The value returned for this
> > socket option will be zero until the socket is connected and has
> > received
> > * a network packet, at which point it will be a non-zero integer
> > value. This is a read only option. Attempting to set the socket option
> > will
> > * cause UOE to be thrown.
> > *
>
> What would you think about starting with something like"
>
> "Identifies the receive queue that the last incoming packet for the socket
> was received on.
>
> The value of this socket option is an Integer that identifies a receive
> queue that can application can use to split the incoming flows among
> threads based on the receive queue.
>
> The socket option is read-only and any attempt to set the socket option
> will throw UnsupportedOperationException.
> The socket option is supported by both stream and datagram oriented
> sockets. The value of the socket option is 0 when the socket is not bound
> or a packet has not been received."
>
> We could add an additional note to explain further how it might work on
> Linux that would use some of the text that you have in your mail.
>
> -Alan.
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200430/5677a531/attachment-0001.htm>

From Alan.Bateman at oracle.com  Thu Apr 30 07:36:35 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Apr 2020 08:36:35 +0100
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
 <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
Message-ID: <739f39d8-b594-47c0-81e0-d99a994b4768@oracle.com>



On 29/04/2020 19:11, Ivanov, Vladimir A wrote:
> Updated version of the webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  => incomingNapiIdOptSupported, IncomingNapiIdSupported => IncomingNapiIdSupported);
>
Thanks for the update.

For the javadoc, I wonder if it might be simpler to drop "Incoming Napi 
Id" so that the first line is "Identifies the receive queue ...". That 
avoids needing to use "Napi" in the javadoc as it would need to be 
defined. Your previous mail had some good text that could be massaged 
into an @apiNote to give the reader some idea how this socket option 
might be used. I'm in two minds on that because it is very Linux specific.

Does SO_INCOMING_NAPI_ID return a non-0 value for connections through 
the loopback? Just checking as that will influence the tests that can be 
created.

SO_INCOMING_NAPI_ID is supported by all socket types so I think we will 
need tests to properly exercise it on the network channels defined in 
java.nio.channels.

AfterClose test. The legacy Socket APIs validate parameters after they 
have checked the socket state so I assume most of the changes to this 
test aren't really needed. That is, I assume SocketException is thrown 
always. SocketChannel and friends are different in that they validate 
the parameters/input before checking the channel state.

PrintSupportedOptions. That can be simplified to use 
Set.of("SO_INCOMING_NAPI_ID").

-Alan.

From patrick.concannon at oracle.com  Thu Apr 30 10:40:02 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 30 Apr 2020 11:40:02 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
Message-ID: <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>

Hi,

After some discussion offline, it was decided that a try-with-resources 
was preferred to a @BeforeTest @AfterTest for creating and closing 
sockets. I?ve updated the webrev to reflect this, and the new patch can 
be found below.

http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/

Kind regards,

Patrick


On 25/04/2020 15:53, Alan Bateman wrote:
>
>
> On 24/04/2020 21:00, Patrick Concannon wrote:
>>
>> Hi Alan,
>>
>> Yeah, sounds good. I?ve added that test case as requested, and you 
>> can find it in the updated webrev below.
>>
>> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.01/
>>
> testInitialSendBufferSize looks good, thanks for adding that.
>
> A minor nit is that the @AfterTest method is in the middle of several 
> tests so not easy to check that it cleans up exactly the resources 
> that the @BeforeTest method creates. It might be helpful to move it so 
> that it is declared after Setup.? No new webrev needed for that of course.
>
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200430/b8be3bf9/attachment.htm>

From chris.hegarty at oracle.com  Thu Apr 30 10:41:41 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 30 Apr 2020 11:41:41 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
 <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
Message-ID: <9C374DB6-B32E-47DC-8634-8485AE7B6DB0@oracle.com>



> On 30 Apr 2020, at 11:40, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> Hi,
> 
> After some discussion offline, it was decided that a try-with-resources was preferred to a @BeforeTest @AfterTest for creating and closing sockets. I?ve updated the webrev to reflect this, and the new patch can be found below.
> 
> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/ <http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/>
> 
LGTM.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200430/beec568e/attachment.htm>

From Alan.Bateman at oracle.com  Thu Apr 30 10:48:39 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Apr 2020 11:48:39 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
 <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
Message-ID: <79eb9692-a848-744a-e76f-f6879fc80df7@oracle.com>

On 30/04/2020 11:40, Patrick Concannon wrote:
>
> Hi,
>
> After some discussion offline, it was decided that a 
> try-with-resources was preferred to a @BeforeTest @AfterTest for 
> creating and closing sockets. I?ve updated the webrev to reflect this, 
> and the new patch can be found below.
>
> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/
>
Another approach would be replace DSF with a simple supplier like this:

 ??? @FunctionalInterface
 ??? interface DatagramSocketSupplier {
 ??????? DatagramSocket get() throws IOException;
 ??? }

so that each test is invoked with a newly created DatagramSocket. It 
means the tests don't need to invoke the factory open and change to try 
(socket) { ...} instead.

Both approaches are fine of course and I agree is better than 
@BeforeTest/@AfterTest so that the resource clean is more obvious.

-Alan



From daniel.fuchs at oracle.com  Thu Apr 30 11:15:02 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Apr 2020 12:15:02 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <79eb9692-a848-744a-e76f-f6879fc80df7@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
 <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
 <79eb9692-a848-744a-e76f-f6879fc80df7@oracle.com>
Message-ID: <ca6b5785-bac5-7fc8-87da-03049d69b193@oracle.com>

Hi Alan,

On 30/04/2020 11:48, Alan Bateman wrote:
>>
>> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/
>>
> Another approach would be replace DSF with a simple supplier like this:
> 
>  ??? @FunctionalInterface
>  ??? interface DatagramSocketSupplier {
>  ??????? DatagramSocket get() throws IOException;
>  ??? }
> 

I don't understand your comment. Maybe I'm missing something?
That's exactly what DSF is isn't it?
We just choose to name the method 'open' instead of 'get'.
And the static `DSF of(DSF)` method is simply there to provide
a type witness and avoid a cast (you get a compilation error
otherwise).

In other words - we could possibly replace
   { "..", DSF.of(() -> new DatagramSocket()) }
with
   { "..", (DSF)() -> new DatagramSocket() }
but
   { "..", () -> new DatagramSocket() }
will never compile.

best regards,

-- daniel

From Alan.Bateman at oracle.com  Thu Apr 30 11:24:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Apr 2020 12:24:45 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <ca6b5785-bac5-7fc8-87da-03049d69b193@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
 <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
 <79eb9692-a848-744a-e76f-f6879fc80df7@oracle.com>
 <ca6b5785-bac5-7fc8-87da-03049d69b193@oracle.com>
Message-ID: <6caa5b55-68b7-74bc-bfde-7b5671731e0e@oracle.com>

On 30/04/2020 12:15, Daniel Fuchs wrote:
>
> I don't understand your comment. Maybe I'm missing something?
> That's exactly what DSF is isn't it?
> We just choose to name the method 'open' instead of 'get'.
> And the static `DSF of(DSF)` method is simply there to provide
> a type witness and avoid a cast (you get a compilation error
> otherwise).
It's a naming issue mostly. If DSF is renamed to something like 
DatagramSocketSupplier then it might be a bit clearer. We have something 
similar in PrintSupportedOptions - I was reminded of that with the 
changes for ADQ that are currently under discussion here.

-Alan.

From daniel.fuchs at oracle.com  Thu Apr 30 11:32:15 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Apr 2020 12:32:15 +0100
Subject: RFR[8243488]: 'Add tests for set/get SendBufferSize and
 getReceiveBufferSize in DatagramSocket'
In-Reply-To: <6caa5b55-68b7-74bc-bfde-7b5671731e0e@oracle.com>
References: <56d259b7-7d56-89ea-afbb-84896378151c@oracle.com>
 <c179bfcc-97ef-3f9c-25ff-e9b7687feb82@oracle.com>
 <8ca09b16-747a-5176-b8a4-85e270ee22e5@oracle.com>
 <3469f8d8-36d0-ddaa-dc41-a9e22dbfcbb6@oracle.com>
 <b840d7c6-1730-92fe-176c-237f9794e143@oracle.com>
 <79eb9692-a848-744a-e76f-f6879fc80df7@oracle.com>
 <ca6b5785-bac5-7fc8-87da-03049d69b193@oracle.com>
 <6caa5b55-68b7-74bc-bfde-7b5671731e0e@oracle.com>
Message-ID: <b7d2c357-5120-858e-6d8e-481eb692b84e@oracle.com>

On 30/04/2020 12:24, Alan Bateman wrote:
> It's a naming issue mostly. If DSF is renamed to something like 
> DatagramSocketSupplier then it might be a bit clearer. We have something 
> similar in PrintSupportedOptions - I was reminded of that with the 
> changes for ADQ that are currently under discussion here.

OK - the poor name is mostly an attempt to avoid too long
lines because of the required cast in the data provider.
But maybe we could work around that by moving the of method
in the outer class - something like:

     @FunctionalInterface
     interface DatagramSocketSupplier {
         DatagramSocket open() throws IOException;
     }

     static DatagramSocketSupplier supplier(DatagramSocketSupplier ds) {
         return ds;
     }

     ...
           { "DatagramSocket", supplier(() -> new DatagramSocket()) }


best regards,

-- daniel

From vladimir.a.ivanov at intel.com  Thu Apr 30 17:14:07 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Thu, 30 Apr 2020 17:14:07 +0000
Subject: RFR 15 8243099: Adding ADQ support to JDK
In-Reply-To: <739f39d8-b594-47c0-81e0-d99a994b4768@oracle.com>
References: <BYAPR11MB3046AB8C60D54A030CF4AB91A7D90@BYAPR11MB3046.namprd11.prod.outlook.com>
 <398D8B76-4E22-453F-9894-97333C9A3C94@oracle.com>
 <BYAPR11MB304698B46890B2F2D311B2DEA7D30@BYAPR11MB3046.namprd11.prod.outlook.com>
 <aaffeb41-86ea-6e57-8eb2-5f31bd9a57ca@oracle.com>
 <BYAPR11MB3046942E6A2ABE4860A431C9A7AC0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <a9065023-1ca0-3c88-f4e3-281787ca93b3@oracle.com>
 <BYAPR11MB3046C663499E13DA3C63614EA7AD0@BYAPR11MB3046.namprd11.prod.outlook.com>
 <739f39d8-b594-47c0-81e0-d99a994b4768@oracle.com>
Message-ID: <BYAPR11MB3046BFD16BEB14441EEEEE61A7AA0@BYAPR11MB3046.namprd11.prod.outlook.com>

Thanks for your comments. 
The Javadoc was updated to fix comments and have '@apiNote' section based on previous description.
Tests PrintSupportedOptions and AfterClose updated to have minimal changes.
Updated webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.04

The main issue with testing for the NAPI_ID that it always zero for the loopback. The test ExtOptionNAPITest.java now check only ServerSocket/Socket/DatagramSocket but for regular runs all values for NapiId are zero. 
To have non-zero values I need manual run of the ExtOptionNAPITest on the 2-server configuration with RHEL8 (kernel for the RHEL7.7 does not support this functionality).
I can add test cases for channels but I failed to find correct testing scenario for it. Seems, it have no big value to have a lot of test cases that return zero.

 Thanks, Vladimir

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Thursday, April 30, 2020 12:37 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK



On 29/04/2020 19:11, Ivanov, Vladimir A wrote:
> Updated version of the webrev available as 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  => 
> incomingNapiIdOptSupported, IncomingNapiIdSupported => 
> IncomingNapiIdSupported);
>
Thanks for the update.

For the javadoc, I wonder if it might be simpler to drop "Incoming Napi Id" so that the first line is "Identifies the receive queue ...". That avoids needing to use "Napi" in the javadoc as it would need to be defined. Your previous mail had some good text that could be massaged into an @apiNote to give the reader some idea how this socket option might be used. I'm in two minds on that because it is very Linux specific.

Does SO_INCOMING_NAPI_ID return a non-0 value for connections through the loopback? Just checking as that will influence the tests that can be created.

SO_INCOMING_NAPI_ID is supported by all socket types so I think we will need tests to properly exercise it on the network channels defined in java.nio.channels.

AfterClose test. The legacy Socket APIs validate parameters after they have checked the socket state so I assume most of the changes to this test aren't really needed. That is, I assume SocketException is thrown always. SocketChannel and friends are different in that they validate the parameters/input before checking the channel state.

PrintSupportedOptions. That can be simplified to use Set.of("SO_INCOMING_NAPI_ID").

-Alan.

From vladimir.a.ivanov at intel.com  Thu Apr 30 21:20:30 2020
From: vladimir.a.ivanov at intel.com (Ivanov, Vladimir A)
Date: Thu, 30 Apr 2020 21:20:30 +0000
Subject: RFR 15 8243099: SO_INCOMING_NAPI_ID support
Message-ID: <BYAPR11MB3046A31BE41751F420299676A7AA0@BYAPR11MB3046.namprd11.prod.outlook.com>

One more update at http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/
The @apiNote section was updated a little bit to concentrate on SO_INCOMING_NAPI_ID.

 Thanks, Vladimir

-----Original Message-----
From: Ivanov, Vladimir A 
Sent: Thursday, April 30, 2020 10:14 AM
To: Alan Bateman <Alan.Bateman at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: RE: RFR 15 8243099: Adding ADQ support to JDK

Thanks for your comments. 
The Javadoc was updated to fix comments and have '@apiNote' section based on previous description.
Tests PrintSupportedOptions and AfterClose updated to have minimal changes.
Updated webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.04

The main issue with testing for the NAPI_ID that it always zero for the loopback. The test ExtOptionNAPITest.java now check only ServerSocket/Socket/DatagramSocket but for regular runs all values for NapiId are zero. 
To have non-zero values I need manual run of the ExtOptionNAPITest on the 2-server configuration with RHEL8 (kernel for the RHEL7.7 does not support this functionality).
I can add test cases for channels but I failed to find correct testing scenario for it. Seems, it have no big value to have a lot of test cases that return zero.

 Thanks, Vladimir

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Thursday, April 30, 2020 12:37 AM
To: Ivanov, Vladimir A <vladimir.a.ivanov at intel.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFR 15 8243099: Adding ADQ support to JDK



On 29/04/2020 19:11, Ivanov, Vladimir A wrote:
> Updated version of the webrev available as 
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  => 
> incomingNapiIdOptSupported, IncomingNapiIdSupported => 
> IncomingNapiIdSupported);
>
Thanks for the update.

For the javadoc, I wonder if it might be simpler to drop "Incoming Napi Id" so that the first line is "Identifies the receive queue ...". That avoids needing to use "Napi" in the javadoc as it would need to be defined. Your previous mail had some good text that could be massaged into an @apiNote to give the reader some idea how this socket option might be used. I'm in two minds on that because it is very Linux specific.

Does SO_INCOMING_NAPI_ID return a non-0 value for connections through the loopback? Just checking as that will influence the tests that can be created.

SO_INCOMING_NAPI_ID is supported by all socket types so I think we will need tests to properly exercise it on the network channels defined in java.nio.channels.

AfterClose test. The legacy Socket APIs validate parameters after they have checked the socket state so I assume most of the changes to this test aren't really needed. That is, I assume SocketException is thrown always. SocketChannel and friends are different in that they validate the parameters/input before checking the channel state.

PrintSupportedOptions. That can be simplified to use Set.of("SO_INCOMING_NAPI_ID").

-Alan.