From vyom.tewari at oracle.com  Tue May  2 11:15:27 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 2 May 2017 16:45:27 +0530
Subject: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking
 code
In-Reply-To: <7de74a1d61c548f9ab9daed47d90760e@sap.com>
References: <4cdaa309-d37f-f8b6-e782-512ac5cfb509@oracle.com>
 <CAA-vtUzGcDXtPqvsK0Lev5+ocRtxqGkmkjLprOahme-HOdpeOg@mail.gmail.com>
 <2bfcde0d-4d23-5f22-9e38-c3b96646f7e6@oracle.com>
 <CAA-vtUw5QdCK1P+oGzr7QXib9DWOiiZxcPv4b2r+f285Dh2Nyg@mail.gmail.com>
 <9F43E573-7858-4BCB-99D9-EBCC3B1ACD4F@oracle.com>
 <CAA-vtUwy=E=sXLjXAOyMZFDqurzreQN9r7sB1vHPsjDbqjOVkg@mail.gmail.com>
 <acc9d987-f9c9-c9f0-3077-5d2751e13c3e@oracle.com>
 <7de74a1d61c548f9ab9daed47d90760e@sap.com>
Message-ID: <3af77642-7dea-fdf5-17f0-0cf177ab1fb0@oracle.com>

pushed the 
code(http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7cdde79d6a46).

Vyom


On Friday 28 April 2017 03:26 AM, Langer, Christoph wrote:
>
> Hi Vyom,
>
> I?ve just got a small formatting remark about the order of includes:
>
> Generally I tried to follow the rule 1. Common os headers, 2. Platform 
> os headers,  3. Jvm/jdk headers, 4. JNI headers in my latest 
> refactorings. So, to keep this up, can you move #include ?jvm.h? in 
> the line before #include ?net_util.h? in each file? And pull it before 
> the JNI headers. Like, e.g. in net_util_md.c you should move #include 
> "jvm.h" to line 52.
>
> Thanks & Best regards
>
> Christoph
>
> *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On Behalf Of 
> *Vyom Tewari
> *Sent:* Donnerstag, 27. April 2017 06:16
> *To:* Thomas St?fe <thomas.stuefe at gmail.com>; Chris Hegarty 
> <chris.hegarty at oracle.com>
> *Cc:* net-dev <net-dev at openjdk.java.net>
> *Subject:* Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in 
> Networking code
>
> Hi,
>
> please find the updated 
> webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html 
> <http://cr.openjdk.java.net/%7Evtewari/8165437/webrev0.7/index.html>).
>
> Thanks,
>
> Vyom
>
> On Tuesday 25 April 2017 07:34 PM, Thomas St?fe wrote:
>
>     Hi Chris, Vyom,
>
>     I have preferences as expressed earlier, but no strong emotions. I
>     can live with the fix as it is now.
>
>     Thanks all, and Kind Regards, Thomas
>
>     On Tue, Apr 25, 2017 at 3:31 PM, Chris Hegarty
>     <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
>
>         > On Tue, Apr 18, 2017 at 7:08 AM, Vyom Tewari
>         <vyom.tewari at oracle.com <mailto:vyom.tewari at oracle.com>> wrote:
>         > ...
>         >
>         > Thanks for review, please find the updated
>         webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.6/index.html
>         <http://cr.openjdk.java.net/%7Evtewari/8165437/webrev0.6/index.html>)
>
>         The changes mainly look good to me, just a few comments:
>
>         1) src/java.base/unix/native/libnet/PlainSocketImpl.c
>
>            L235     jlong nanoTimeout = timeout * NET_NSEC_PER_MSEC;
>
>            Can you please move this to the latest block of code that
>         requires it, i.e..
>            just after L327 if (connect_rv != 0) { ?
>
>         2) src/java.base/share/native/libnet/net_util.h
>
>            Should these definitions be moved to
>         src/java.base/unix/native/libnet/net_util_md.h?
>
>
>         Regarding JVM_NanoTime being a JVM_LEAF and/or taking a JNIEnv (
>         both of which are, in todays hotspot VM, effectively ignored
>         ), this is a
>         separate issue. I have raised it off list with others from the
>         VM team,
>         without much interest. I will refrain from filing a JIRA issue
>         to track potential
>         changes in the VM for this. Others are welcome to do so, if
>         they wish. I
>         suggest that we simply continue to pass a valid JNIEnv, since
>         it is not
>         much extra effort to do so. ( this can be refactored later, if
>         the VM interface
>         is ever updated ).
>
>
>         > On 24 Apr 2017, at 12:07, Thomas St?fe
>         <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>         >
>         > ...
>         > That aside, I am not a big fan of the removal of the old
>         NET_Timeout. Before, there were two functions, "NET_Timeout"
>         just taking the timeout value, "NET_Timeout0" taking a timeout
>         and a start value. You removed the first variant and therefore
>         added the many additional JVM_NanoTime() calls at NET_Timeout
>         callsites. This makes the code harder to read and also kind of
>         exposes the internal implementation of NET_Timeout (namely the
>         fact that NET_Timeout uses JVM_NanoTime for time measurement).
>         Could you please let both variants live, optionally with
>         better names?
>
>         I think that it may not be worth added back the simpler
>         variant. It
>         would only be used by PlainDatagramSocketImpl, correct? All other
>         usages would use the variant that accepts the current nano time.
>
>         -Chris.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170502/ed691859/attachment.html>

From mark.sheppard at oracle.com  Tue May  2 13:51:27 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 2 May 2017 14:51:27 +0100
Subject: RFR: JDK-8179512 - Typo in HttpURLConnection documentation
Message-ID: <f4a59ebd-36d6-e6dc-5d15-0b0a876bd80c@oracle.com>

Hi
    please oblige and review the minor change, to javadoc of 
HttpURLConnection, below

which addresses the punctuation correction requested
in
https://bugs.openjdk.java.net/browse/JDK-8179512

regards
Mark

bash-4.1$ hg diff 
src/java.base/share/classes/java/net/HttpURLConnection.java
diff -r e91c7b2a4481 
src/java.base/share/classes/java/net/HttpURLConnection.java
--- a/src/java.base/share/classes/java/net/HttpURLConnection.java Fri 
Apr 28 12:22:53 2017 -0700
+++ b/src/java.base/share/classes/java/net/HttpURLConnection.java Tue 
May 02 14:42:36 2017 +0100
@@ -54,7 +54,7 @@
   * <b>Security permissions</b>
   * <p>
   * If a security manager is installed, and if a method is called which 
results in an
- * attempt to open a connection, the caller must possess either:-
+ * attempt to open a connection, the caller must possess either:
   * <ul><li>a "connect" {@link SocketPermission} to the host/port 
combination of the
   * destination URL or</li>
   * <li>a {@link URLPermission} that permits this request.</li>


From chris.hegarty at oracle.com  Tue May  2 13:53:23 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 2 May 2017 14:53:23 +0100
Subject: RFR: JDK-8179512 - Typo in HttpURLConnection documentation
In-Reply-To: <f4a59ebd-36d6-e6dc-5d15-0b0a876bd80c@oracle.com>
References: <f4a59ebd-36d6-e6dc-5d15-0b0a876bd80c@oracle.com>
Message-ID: <197dc340-03b8-5739-79b6-56ef478f226c@oracle.com>

Mark,

The change looks ok to me.

-Chris.

On 02/05/17 14:51, Mark Sheppard wrote:
> Hi
>    please oblige and review the minor change, to javadoc of
> HttpURLConnection, below
>
> which addresses the punctuation correction requested
> in
> https://bugs.openjdk.java.net/browse/JDK-8179512
>
> regards
> Mark
>
> bash-4.1$ hg diff
> src/java.base/share/classes/java/net/HttpURLConnection.java
> diff -r e91c7b2a4481
> src/java.base/share/classes/java/net/HttpURLConnection.java
> --- a/src/java.base/share/classes/java/net/HttpURLConnection.java Fri
> Apr 28 12:22:53 2017 -0700
> +++ b/src/java.base/share/classes/java/net/HttpURLConnection.java Tue
> May 02 14:42:36 2017 +0100
> @@ -54,7 +54,7 @@
>   * <b>Security permissions</b>
>   * <p>
>   * If a security manager is installed, and if a method is called which
> results in an
> - * attempt to open a connection, the caller must possess either:-
> + * attempt to open a connection, the caller must possess either:
>   * <ul><li>a "connect" {@link SocketPermission} to the host/port
> combination of the
>   * destination URL or</li>
>   * <li>a {@link URLPermission} that permits this request.</li>
>

From mark.sheppard at oracle.com  Tue May  2 15:26:56 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 2 May 2017 16:26:56 +0100
Subject: RFR: JDK-8179512 - Typo in HttpURLConnection documentation
In-Reply-To: <197dc340-03b8-5739-79b6-56ef478f226c@oracle.com>
References: <f4a59ebd-36d6-e6dc-5d15-0b0a876bd80c@oracle.com>
 <197dc340-03b8-5739-79b6-56ef478f226c@oracle.com>
Message-ID: <c87b18f9-f5b6-01dd-eb59-138cee0d2a8b@oracle.com>

thanks Chris

On 02/05/2017 14:53, Chris Hegarty wrote:
> Mark,
>
> The change looks ok to me.
>
> -Chris.
>
> On 02/05/17 14:51, Mark Sheppard wrote:
>> Hi
>>    please oblige and review the minor change, to javadoc of
>> HttpURLConnection, below
>>
>> which addresses the punctuation correction requested
>> in
>> https://bugs.openjdk.java.net/browse/JDK-8179512
>>
>> regards
>> Mark
>>
>> bash-4.1$ hg diff
>> src/java.base/share/classes/java/net/HttpURLConnection.java
>> diff -r e91c7b2a4481
>> src/java.base/share/classes/java/net/HttpURLConnection.java
>> --- a/src/java.base/share/classes/java/net/HttpURLConnection.java Fri
>> Apr 28 12:22:53 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/HttpURLConnection.java Tue
>> May 02 14:42:36 2017 +0100
>> @@ -54,7 +54,7 @@
>>   * <b>Security permissions</b>
>>   * <p>
>>   * If a security manager is installed, and if a method is called which
>> results in an
>> - * attempt to open a connection, the caller must possess either:-
>> + * attempt to open a connection, the caller must possess either:
>>   * <ul><li>a "connect" {@link SocketPermission} to the host/port
>> combination of the
>>   * destination URL or</li>
>>   * <li>a {@link URLPermission} that permits this request.</li>
>>


From david.holmes at oracle.com  Thu May  4 00:59:51 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 May 2017 10:59:51 +1000
Subject: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking
 code
In-Reply-To: <acc9d987-f9c9-c9f0-3077-5d2751e13c3e@oracle.com>
References: <acc9d987-f9c9-c9f0-3077-5d2751e13c3e@oracle.com>
Message-ID: <8f4ef286-f930-da07-fbc4-46851d1744e3@oracle.com>

> please find the updated
> webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html).

This change is broken on 32-bit systems - JVM_Nanotime returns a jlong 
which is always 64-bit, but the code uses long for the nanotimeout 
values, which will be 32-bit on 32-bit systems!

This change appears to be causing massive testing failures due to jtreg 
agentvm failing due to sock connection issues. Most obvious with 32-bit 
linux builds. However we also see a some failures on OSX which is not 
explained by the long vs jlong issue.

David
-----

From vyom.tewari at oracle.com  Thu May  4 04:07:00 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 4 May 2017 09:37:00 +0530
Subject: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking
 code
In-Reply-To: <8f4ef286-f930-da07-fbc4-46851d1744e3@oracle.com>
References: <acc9d987-f9c9-c9f0-3077-5d2751e13c3e@oracle.com>
 <8f4ef286-f930-da07-fbc4-46851d1744e3@oracle.com>
Message-ID: <2df2ed80-ab1e-7b7c-88e2-3a680b21bd30@oracle.com>

Hi David,

I will look into the issue.

Thanks,

Vyom


On Thursday 04 May 2017 06:29 AM, David Holmes wrote:
>> please find the updated
>> webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). 
>>
>
> This change is broken on 32-bit systems - JVM_Nanotime returns a jlong 
> which is always 64-bit, but the code uses long for the nanotimeout 
> values, which will be 32-bit on 32-bit systems!
>
> This change appears to be causing massive testing failures due to 
> jtreg agentvm failing due to sock connection issues. Most obvious with 
> 32-bit linux builds. However we also see a some failures on OSX which 
> is not explained by the long vs jlong issue.
>
> David
> -----


From david.holmes at oracle.com  Thu May  4 04:18:10 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 May 2017 14:18:10 +1000
Subject: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking
 code
In-Reply-To: <2df2ed80-ab1e-7b7c-88e2-3a680b21bd30@oracle.com>
References: <acc9d987-f9c9-c9f0-3077-5d2751e13c3e@oracle.com>
 <8f4ef286-f930-da07-fbc4-46851d1744e3@oracle.com>
 <2df2ed80-ab1e-7b7c-88e2-3a680b21bd30@oracle.com>
Message-ID: <523840cf-8020-0990-2611-8077d55ba76d@oracle.com>

On 4/05/2017 2:07 PM, Vyom Tewari wrote:
> Hi David,
>
> I will look into the issue.

Thanks. I filed:

https://bugs.openjdk.java.net/browse/JDK-8179602

as you probably saw.

David

>
> Thanks,
>
> Vyom
>
>
> On Thursday 04 May 2017 06:29 AM, David Holmes wrote:
>>> please find the updated
>>> webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html).
>>>
>>
>> This change is broken on 32-bit systems - JVM_Nanotime returns a jlong
>> which is always 64-bit, but the code uses long for the nanotimeout
>> values, which will be 32-bit on 32-bit systems!
>>
>> This change appears to be causing massive testing failures due to
>> jtreg agentvm failing due to sock connection issues. Most obvious with
>> 32-bit linux builds. However we also see a some failures on OSX which
>> is not explained by the long vs jlong issue.
>>
>> David
>> -----
>

From vyom.tewari at oracle.com  Thu May  4 08:50:05 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 4 May 2017 14:20:05 +0530
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
Message-ID: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>

Hi All,

Please  review the below change.

Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html

Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602

This issue is because of side effect of "JDK-8165437" where we are using 
"JVM_NanoTime" which returns a 64 bit jlong and return value was getting 
assigned to long type. On 32 bit OS long is 4 byte, which leads to 
integer overflow.

Our internal test JPRT is  still running.

Thanks,

Vyom


From christoph.langer at sap.com  Thu May  4 08:57:15 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 4 May 2017 08:57:15 +0000
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
In-Reply-To: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
References: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
Message-ID: <fd8fa4362ca3408380632744e82ff928@sap.com>

Hi Vyom,

the fix looks good and seems straightforward to resolve the reported issue.

Small item: I spotted an extra space in net_util_md.h, line 75, between "jlong" and "nanoTimeStamp" which could be removed.

Reviewed.

Best regards
Christoph

> -----Original Message-----
> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of
> Vyom Tewari
> Sent: Donnerstag, 4. Mai 2017 10:50
> To: net-dev <net-dev at openjdk.java.net>
> Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
> 
> Hi All,
> 
> Please  review the below change.
> 
> Webrev:
> http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html
> 
> Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602
> 
> This issue is because of side effect of "JDK-8165437" where we are using
> "JVM_NanoTime" which returns a 64 bit jlong and return value was getting
> assigned to long type. On 32 bit OS long is 4 byte, which leads to
> integer overflow.
> 
> Our internal test JPRT is  still running.
> 
> Thanks,
> 
> Vyom


From michael.x.mcmahon at oracle.com  Thu May  4 09:41:03 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 04 May 2017 10:41:03 +0100
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
In-Reply-To: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
References: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
Message-ID: <590AF72F.10401@oracle.com>

Hi Vyom,

I notice this doesn't seem to fix the Mac OS problem.
We may have to file a separate issue for that.

- Michael

On 04/05/2017, 09:50, Vyom Tewari wrote:
> Hi All,
>
> Please  review the below change.
>
> Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html
>
> Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602
>
> This issue is because of side effect of "JDK-8165437" where we are 
> using "JVM_NanoTime" which returns a 64 bit jlong and return value was 
> getting assigned to long type. On 32 bit OS long is 4 byte, which 
> leads to integer overflow.
>
> Our internal test JPRT is  still running.
>
> Thanks,
>
> Vyom
>

From vyom.tewari at oracle.com  Thu May  4 14:33:30 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 4 May 2017 20:03:30 +0530
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
In-Reply-To: <590AF72F.10401@oracle.com>
References: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
 <590AF72F.10401@oracle.com>
Message-ID: <5842c8cb-e8aa-fb18-fb27-8f24f38073bc@oracle.com>

Hi All,

please find the latest 
webrev(http://cr.openjdk.java.net/~vtewari/8179602/webrev0.1/index.html) 
which fixed the Mac OS issued as well.

Michael as we we discussed off line, i incorporated the changes 
suggested by you,

Thanks,

Vyom


On Thursday 04 May 2017 03:11 PM, Michael McMahon wrote:
> Hi Vyom,
>
> I notice this doesn't seem to fix the Mac OS problem.
> We may have to file a separate issue for that.
>
> - Michael
>
> On 04/05/2017, 09:50, Vyom Tewari wrote:
>> Hi All,
>>
>> Please  review the below change.
>>
>> Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html
>>
>> Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602
>>
>> This issue is because of side effect of "JDK-8165437" where we are 
>> using "JVM_NanoTime" which returns a 64 bit jlong and return value 
>> was getting assigned to long type. On 32 bit OS long is 4 byte, which 
>> leads to integer overflow.
>>
>> Our internal test JPRT is  still running.
>>
>> Thanks,
>>
>> Vyom
>>


From michael.x.mcmahon at oracle.com  Thu May  4 16:58:22 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 04 May 2017 17:58:22 +0100
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
In-Reply-To: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
References: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
Message-ID: <590B5DAE.3090706@oracle.com>

Hi Vyom,

As discussed, I think there are still some issues including on 32 bit 
Linux and since we don't
have too many of those machines left to debug with, it's probably best 
to back out the original
change, and go back to the original webrev. We can then review an 
updated version which takes
care of the 32/64 bit issues that were found. Below is a backout webrev, 
with no other changes

http://cr.openjdk.java.net/~michaelm/8179602/webrev.1/

Thanks,
Michael



On 04/05/2017, 09:50, Vyom Tewari wrote:
> Hi All,
>
> Please  review the below change.
>
> Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html
>
> Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602
>
> This issue is because of side effect of "JDK-8165437" where we are 
> using "JVM_NanoTime" which returns a 64 bit jlong and return value was 
> getting assigned to long type. On 32 bit OS long is 4 byte, which 
> leads to integer overflow.
>
> Our internal test JPRT is  still running.
>
> Thanks,
>
> Vyom
>

From chris.hegarty at oracle.com  Thu May  4 17:01:24 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 4 May 2017 18:01:24 +0100
Subject: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux
In-Reply-To: <590B5DAE.3090706@oracle.com>
References: <c7accb18-0c97-5f7b-39c2-1e02c91f766f@oracle.com>
 <590B5DAE.3090706@oracle.com>
Message-ID: <B1AB2CD5-B15C-4AB7-B353-2DC7FAA86965@oracle.com>


> On 4 May 2017, at 17:58, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> Hi Vyom,
> 
> As discussed, I think there are still some issues including on 32 bit Linux and since we don't
> have too many of those machines left to debug with, it's probably best to back out the original
> change, and go back to the original webrev. We can then review an updated version which takes
> care of the 32/64 bit issues that were found. Below is a backout webrev, with no other changes
> 
> http://cr.openjdk.java.net/~michaelm/8179602/webrev.1/

Looks like an accurate anti-delta.  Reviewed.

If you are using 8179602 to track this, then please update the synopsis
to make it clear what this is about.

-Chris.


From mark.sheppard at oracle.com  Thu May  4 20:56:14 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Thu, 4 May 2017 21:56:14 +0100
Subject: RFR: JDK-7155591 - [macosx] regression test
 java/net/MulticastSocket/SetOutgoingIf.java fail
Message-ID: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>

Hi,
     please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/7155591/webrev/

to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-7155591

this identifies that the awdl interface causes issues for the 
SetOutgoingIf multicast socket test, and
the proposed solution is exclude it from test scenarios. As such, the change
adds a check to ignore this network interface during interface selection.

regards
Mark



From brian.burkhalter at oracle.com  Thu May  4 21:13:40 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 May 2017 14:13:40 -0700
Subject: RFR: JDK-7155591 - [macosx] regression test
 java/net/MulticastSocket/SetOutgoingIf.java fail
In-Reply-To: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
References: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
Message-ID: <4117F77F-DA21-4D9C-A34E-5D420793DFC4@oracle.com>

Hi Mark,

Not exactly my area but I did look over similar code that Chris wrote for [1] and your code here looks OK (aside from the more recent copyright year).

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8158270

On May 4, 2017, at 1:56 PM, Mark Sheppard <mark.sheppard at oracle.com> wrote:

> Hi,
>    please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/7155591/webrev/
> 
> to address the issue raised in
> https://bugs.openjdk.java.net/browse/JDK-7155591
> 
> this identifies that the awdl interface causes issues for the SetOutgoingIf multicast socket test, and
> the proposed solution is exclude it from test scenarios. As such, the change
> adds a check to ignore this network interface during interface selection.
> 
> regards
> Mark

From mark.sheppard at oracle.com  Thu May  4 22:38:50 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Thu, 4 May 2017 23:38:50 +0100
Subject: RFR: JDK-7155591 - [macosx] regression test
 java/net/MulticastSocket/SetOutgoingIf.java fail
In-Reply-To: <4117F77F-DA21-4D9C-A34E-5D420793DFC4@oracle.com>
References: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
 <4117F77F-DA21-4D9C-A34E-5D420793DFC4@oracle.com>
Message-ID: <787fb066-c8e9-18ec-2078-dd89729a253d@oracle.com>


Thanks Brian


On 04/05/2017 22:13, Brian Burkhalter wrote:
> Hi Mark,
>
> Not exactly my area but I did look over similar code that Chris wrote for [1] and your code here looks OK (aside from the more recent copyright year).
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8158270
>
> On May 4, 2017, at 1:56 PM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>
>> Hi,
>>     please oblige and review the following change
>> http://cr.openjdk.java.net/~msheppar/7155591/webrev/
>>
>> to address the issue raised in
>> https://bugs.openjdk.java.net/browse/JDK-7155591
>>
>> this identifies that the awdl interface causes issues for the SetOutgoingIf multicast socket test, and
>> the proposed solution is exclude it from test scenarios. As such, the change
>> adds a check to ignore this network interface during interface selection.
>>
>> regards
>> Mark


From chris.hegarty at oracle.com  Fri May  5 07:58:45 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 08:58:45 +0100
Subject: RFR [9] 7155591: test/java/net/MulticastSocket/SetOutgoingIf.java
 fails on macOS
Message-ID: <1B6C56B2-7472-43C2-A9D6-8DABB6DC4C9C@oracle.com>

This is a test-only change.

This is one of the last remaining networking tests that fails when
an Apple Peer-to-Peer interface is available on the host machine.
The changes minimally update the test to use the new test library
Network configuration probe ( centralises and filters platform
specific interfaces ).

http://cr.openjdk.java.net/~chegar/7155591/

-Chris.

From chris.hegarty at oracle.com  Fri May  5 08:29:44 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 09:29:44 +0100
Subject: RFR [9] 7155591: test/java/net/MulticastSocket/SetOutgoingIf.java
 fails on macOS
In-Reply-To: <1B6C56B2-7472-43C2-A9D6-8DABB6DC4C9C@oracle.com>
References: <1B6C56B2-7472-43C2-A9D6-8DABB6DC4C9C@oracle.com>
Message-ID: <31BC9CA8-3CAA-498F-8300-0A63D0F9D24D@oracle.com>

Ignore this. Mark has a review out to resolve this issue.

http://mail.openjdk.java.net/pipermail/net-dev/2017-May/010765.html

-Chris.

> On 5 May 2017, at 08:58, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> This is a test-only change.
> 
> This is one of the last remaining networking tests that fails when
> an Apple Peer-to-Peer interface is available on the host machine.
> The changes minimally update the test to use the new test library
> Network configuration probe ( centralises and filters platform
> specific interfaces ).
> 
> http://cr.openjdk.java.net/~chegar/7155591/
> 
> -Chris.


From chris.hegarty at oracle.com  Fri May  5 08:30:53 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 09:30:53 +0100
Subject: RFR: JDK-7155591 - [macosx] regression test
 java/net/MulticastSocket/SetOutgoingIf.java fail
In-Reply-To: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
References: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
Message-ID: <24605514-7EFB-482C-AC5B-75A5703AB917@oracle.com>


> On 4 May 2017, at 21:56, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi,
>    please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/7155591/webrev/

This is fine Mark. Alternatively, you could use the NetworkConfiguration
probe, but I?m just happy to see this test become more stable.

-Chris.

From michael.x.mcmahon at oracle.com  Fri May  5 09:23:15 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 10:23:15 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
Message-ID: <590C4483.6090908@oracle.com>

Could I get the following changed reviewed please?

It's a fix for the two Solaris Multicast socket tests that fail always.

http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/

Thanks
Michael

From chris.hegarty at oracle.com  Fri May  5 10:02:51 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 11:02:51 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <590C4483.6090908@oracle.com>
References: <590C4483.6090908@oracle.com>
Message-ID: <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>


> On 5 May 2017, at 10:23, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> Could I get the following changed reviewed please?
> 
> It's a fix for the two Solaris Multicast socket tests that fail always.
> 
> http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/

This looks ok to me Michael. Good to have this loooooooooong standing
issue finally addressed. Thank you.

-Chris.

From mark.sheppard at oracle.com  Fri May  5 10:13:51 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 5 May 2017 11:13:51 +0100
Subject: RFR: JDK-7155591 - [macosx] regression test
 java/net/MulticastSocket/SetOutgoingIf.java fail
In-Reply-To: <24605514-7EFB-482C-AC5B-75A5703AB917@oracle.com>
References: <d0eaa558-f35b-0dfb-c145-b9e237722559@oracle.com>
 <24605514-7EFB-482C-AC5B-75A5703AB917@oracle.com>
Message-ID: <204fbda9-80bf-42d1-1231-b930ddc1c8f9@oracle.com>

thanks Chris
wrt NetworkConfiguration, yes I considered using it, but distilled the 
change to
the small change shown

regards
Mark

On 05/05/2017 09:30, Chris Hegarty wrote:
>> On 4 May 2017, at 21:56, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>> Hi,
>>     please oblige and review the following change
>> http://cr.openjdk.java.net/~msheppar/7155591/webrev/
> This is fine Mark. Alternatively, you could use the NetworkConfiguration
> probe, but I?m just happy to see this test become more stable.
>
> -Chris.


From michael.x.mcmahon at oracle.com  Fri May  5 13:26:14 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 14:26:14 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
Message-ID: <590C7D76.2020802@oracle.com>

Actually, I've just realised that the root cause is a more basic problem 
in the
implementation of NetworkInterface.getByInetAddress() where it was not
checking the scopeids and therefore not distinguishing

::0%3 from ::0%4 etc

So, a better fix is actually in the implementation of that method. I'll send
an updated webrev later.

Thanks,
Michael.

On 05/05/2017, 11:02, Chris Hegarty wrote:
>> On 5 May 2017, at 10:23, Michael McMahon<michael.x.mcmahon at oracle.com>  wrote:
>>
>> Could I get the following changed reviewed please?
>>
>> It's a fix for the two Solaris Multicast socket tests that fail always.
>>
>> http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/
> This looks ok to me Michael. Good to have this loooooooooong standing
> issue finally addressed. Thank you.
>
> -Chris.

From mark.sheppard at oracle.com  Fri May  5 13:52:18 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 5 May 2017 14:52:18 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
Message-ID: <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>

If we look at the failure scenario then it seen that
with multiple network interfaces having IPv6 and IPv4 configurations,
where the IPv6 part is not fully configured and is not UP, but is
RUNNING

wrt the change in MulticastSocket, is there not a deeper issue here?
that is,  in the MulticastSocket.getInterface()  method  the invocation

InetAddress ia = (InetAddress) 
getImpl().getOption(SocketOptions.IP_MULTICAST_IF)

doesn't return the same address as that which was set by the
MulticastSocket.setInterface()

in the problematic configurations the IPv6 interface is not UP, but it 
is RUNNING, MULTICAST, and
the address is unspecified. It would be expected that the OS would 
return the address configured in the
previous setsockopt?
At least it would be assumed that the OS syscall would be using the 
state of the interface
as criteria to avoid returning the unspecified IPv6 address in
preference to the UP and RUNNING and selected IPv4 address?
It seems the OS preference is for IPv6 regardless of the state on the 
interface.
Is there an issue to be raised with Solaris OS ?


Additionally, wrt  the try block incorporating the  address search by
iterating  over the network interfaces, the catch clause will return ia
That is, the address retrieved with via the previous getOption invocation.
Should this not return null or even re-throw the Exception?
returning an Address in this case seems questionable.

with respect to the change in MulticastSocket/Test.java
should the address checks be considered as OS agnostic?

a number of multicast socket tests exclude the network interface 
unspecified address
and the loopback address for consideration.

regards
Mark


On 05/05/2017 11:02, Chris Hegarty wrote:
>> On 5 May 2017, at 10:23, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>>
>> Could I get the following changed reviewed please?
>>
>> It's a fix for the two Solaris Multicast socket tests that fail always.
>>
>> http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/
> This looks ok to me Michael. Good to have this loooooooooong standing
> issue finally addressed. Thank you.
>
> -Chris.


From michael.x.mcmahon at oracle.com  Fri May  5 14:20:10 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 15:20:10 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
Message-ID: <590C8A1A.9040705@oracle.com>

Hi Mark,

It's certainly arguable that the OS should return the same address that 
was configured.
But, I think we can work around that limitation regardless.

Since I sent the first webrev, I found a bug in 
NetworkInterface.getByInetAddress()
and after fixing that, the MulticastSocket code does not need to change.
I'll send an updated webrev later.

Thanks
Michael.

On 05/05/2017, 14:52, Mark Sheppard wrote:
> If we look at the failure scenario then it seen that
> with multiple network interfaces having IPv6 and IPv4 configurations,
> where the IPv6 part is not fully configured and is not UP, but is
> RUNNING
>
> wrt the change in MulticastSocket, is there not a deeper issue here?
> that is,  in the MulticastSocket.getInterface()  method  the invocation
>
> InetAddress ia = (InetAddress) 
> getImpl().getOption(SocketOptions.IP_MULTICAST_IF)
>
> doesn't return the same address as that which was set by the
> MulticastSocket.setInterface()
>
> in the problematic configurations the IPv6 interface is not UP, but it 
> is RUNNING, MULTICAST, and
> the address is unspecified. It would be expected that the OS would 
> return the address configured in the
> previous setsockopt?
> At least it would be assumed that the OS syscall would be using the 
> state of the interface
> as criteria to avoid returning the unspecified IPv6 address in
> preference to the UP and RUNNING and selected IPv4 address?
> It seems the OS preference is for IPv6 regardless of the state on the 
> interface.
> Is there an issue to be raised with Solaris OS ?
>
>
> Additionally, wrt  the try block incorporating the  address search by
> iterating  over the network interfaces, the catch clause will return ia
> That is, the address retrieved with via the previous getOption 
> invocation.
> Should this not return null or even re-throw the Exception?
> returning an Address in this case seems questionable.
>
> with respect to the change in MulticastSocket/Test.java
> should the address checks be considered as OS agnostic?
>
> a number of multicast socket tests exclude the network interface 
> unspecified address
> and the loopback address for consideration.
>
> regards
> Mark
>
>
> On 05/05/2017 11:02, Chris Hegarty wrote:
>>> On 5 May 2017, at 10:23, Michael McMahon 
>>> <michael.x.mcmahon at oracle.com> wrote:
>>>
>>> Could I get the following changed reviewed please?
>>>
>>> It's a fix for the two Solaris Multicast socket tests that fail always.
>>>
>>> http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/
>> This looks ok to me Michael. Good to have this loooooooooong standing
>> issue finally addressed. Thank you.
>>
>> -Chris.
>

From michael.x.mcmahon at oracle.com  Fri May  5 15:19:52 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 16:19:52 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <590C8A1A.9040705@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com>
Message-ID: <590C9818.7010001@oracle.com>

Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/

The tests have not changed from previous webrev.

Thanks,
Michael

On 05/05/2017, 15:20, Michael McMahon wrote:
> Hi Mark,
>
> It's certainly arguable that the OS should return the same address 
> that was configured.
> But, I think we can work around that limitation regardless.
>
> Since I sent the first webrev, I found a bug in 
> NetworkInterface.getByInetAddress()
> and after fixing that, the MulticastSocket code does not need to change.
> I'll send an updated webrev later.
>
> Thanks
> Michael.
>
> On 05/05/2017, 14:52, Mark Sheppard wrote:
>> If we look at the failure scenario then it seen that
>> with multiple network interfaces having IPv6 and IPv4 configurations,
>> where the IPv6 part is not fully configured and is not UP, but is
>> RUNNING
>>
>> wrt the change in MulticastSocket, is there not a deeper issue here?
>> that is,  in the MulticastSocket.getInterface()  method  the invocation
>>
>> InetAddress ia = (InetAddress) 
>> getImpl().getOption(SocketOptions.IP_MULTICAST_IF)
>>
>> doesn't return the same address as that which was set by the
>> MulticastSocket.setInterface()
>>
>> in the problematic configurations the IPv6 interface is not UP, but 
>> it is RUNNING, MULTICAST, and
>> the address is unspecified. It would be expected that the OS would 
>> return the address configured in the
>> previous setsockopt?
>> At least it would be assumed that the OS syscall would be using the 
>> state of the interface
>> as criteria to avoid returning the unspecified IPv6 address in
>> preference to the UP and RUNNING and selected IPv4 address?
>> It seems the OS preference is for IPv6 regardless of the state on the 
>> interface.
>> Is there an issue to be raised with Solaris OS ?
>>
>>
>> Additionally, wrt  the try block incorporating the  address search by
>> iterating  over the network interfaces, the catch clause will return ia
>> That is, the address retrieved with via the previous getOption 
>> invocation.
>> Should this not return null or even re-throw the Exception?
>> returning an Address in this case seems questionable.
>>
>> with respect to the change in MulticastSocket/Test.java
>> should the address checks be considered as OS agnostic?
>>
>> a number of multicast socket tests exclude the network interface 
>> unspecified address
>> and the loopback address for consideration.
>>
>> regards
>> Mark
>>
>>
>> On 05/05/2017 11:02, Chris Hegarty wrote:
>>>> On 5 May 2017, at 10:23, Michael McMahon 
>>>> <michael.x.mcmahon at oracle.com> wrote:
>>>>
>>>> Could I get the following changed reviewed please?
>>>>
>>>> It's a fix for the two Solaris Multicast socket tests that fail 
>>>> always.
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/
>>> This looks ok to me Michael. Good to have this loooooooooong standing
>>> issue finally addressed. Thank you.
>>>
>>> -Chris.
>>

From chris.hegarty at oracle.com  Fri May  5 17:14:37 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 18:14:37 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <590C9818.7010001@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com> <590C9818.7010001@oracle.com>
Message-ID: <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>


> On 5 May 2017, at 16:19, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/

InetAddress.scope_id is optional ( 0 if unset ), should the code
only use it if it is non-zero?

-Chris.

From michael.x.mcmahon at oracle.com  Fri May  5 17:29:07 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 18:29:07 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com> <590C9818.7010001@oracle.com>
 <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>
Message-ID: <590CB663.8040202@oracle.com>



On 05/05/2017, 18:14, Chris Hegarty wrote:
>> On 5 May 2017, at 16:19, Michael McMahon<michael.x.mcmahon at oracle.com>  wrote:
>>
>> Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/
> InetAddress.scope_id is optional ( 0 if unset ), should the code
> only use it if it is non-zero?
>
> -Chris.

Do you mean if the Inet6Address passed in has zero for the scope_id that the
search should ignore it, and do what happens now, ie. return the first 
address found?

Michael.

From chris.hegarty at oracle.com  Fri May  5 17:30:28 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 18:30:28 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <590CB663.8040202@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com> <590C9818.7010001@oracle.com>
 <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>
 <590CB663.8040202@oracle.com>
Message-ID: <633D343B-D440-4BAB-A291-B338064DD415@oracle.com>


> On 5 May 2017, at 18:29, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> ...
> 
> Do you mean if the Inet6Address passed in has zero for the scope_id that the
> search should ignore it, and do what happens now, ie. return the first address found?

Yes, that is what I wanted to say. Does it make sense?

-Chris.


From michael.x.mcmahon at oracle.com  Fri May  5 17:36:14 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 May 2017 18:36:14 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <633D343B-D440-4BAB-A291-B338064DD415@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com> <590C9818.7010001@oracle.com>
 <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>
 <590CB663.8040202@oracle.com>
 <633D343B-D440-4BAB-A291-B338064DD415@oracle.com>
Message-ID: <590CB80E.3070002@oracle.com>



On 05/05/2017, 18:30, Chris Hegarty wrote:
>> On 5 May 2017, at 18:29, Michael McMahon<michael.x.mcmahon at oracle.com>  wrote:
>> ...
>>
>> Do you mean if the Inet6Address passed in has zero for the scope_id that the
>> search should ignore it, and do what happens now, ie. return the first address found?
> Yes, that is what I wanted to say. Does it make sense?
>
> -Chris.
>
Yes, I think so. It's not unreasonable to have an address that might be 
unique
on the local system and in some circumstances might not need a scope id.
So, a scope id of zero would never match then.

I won't regenerate the webrev but just change the condition to:

             if (scopeid != 0 && scopeid != ((struct 
sockaddr_in6*)addrP->addr)->sin6_scope_id)
                         break;

am running tests again though.

Thanks
Michael.


From chris.hegarty at oracle.com  Fri May  5 18:07:57 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 May 2017 19:07:57 +0100
Subject: RFR: 8179559 Solaris MulticastSocket issues
In-Reply-To: <590CB80E.3070002@oracle.com>
References: <590C4483.6090908@oracle.com>
 <F23AB690-351D-41C8-8E4A-BD3AF2BB21C7@oracle.com>
 <de5f16e6-5e7a-772d-edcc-743750aa9cbe@oracle.com>
 <590C8A1A.9040705@oracle.com> <590C9818.7010001@oracle.com>
 <E8209ADB-F3B4-4CAF-96F6-03EE4F4FC68A@oracle.com>
 <590CB663.8040202@oracle.com>
 <633D343B-D440-4BAB-A291-B338064DD415@oracle.com>
 <590CB80E.3070002@oracle.com>
Message-ID: <D34C143E-EDF1-4199-9B1C-27B879B3953A@oracle.com>


> On 5 May 2017, at 18:36, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> 
> 
> On 05/05/2017, 18:30, Chris Hegarty wrote:
>>> On 5 May 2017, at 18:29, Michael McMahon<michael.x.mcmahon at oracle.com>  wrote:
>>> ...
>>> 
>>> Do you mean if the Inet6Address passed in has zero for the scope_id that the
>>> search should ignore it, and do what happens now, ie. return the first address found?
>> Yes, that is what I wanted to say. Does it make sense?
>> 
>> -Chris.
>> 
> Yes, I think so. It's not unreasonable to have an address that might be unique
> on the local system and in some circumstances might not need a scope id.
> So, a scope id of zero would never match then.
> 
> I won't regenerate the webrev but just change the condition to:
> 
>            if (scopeid != 0 && scopeid != ((struct sockaddr_in6*)addrP->addr)->sin6_scope_id)
>                        break;

Looks good.

-Chris.

From vyom.tewari at oracle.com  Tue May  9 09:55:26 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 9 May 2017 15:25:26 +0530
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
Message-ID: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>

Hi ,

Please review the code change for below issue.

Webrev  : http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html

BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905

This issue is duplicate of "JDK-8165437", where pushed code change 
failed on 32 bit platforms so we revert back code changes as part of 
"JDK-8179602".

Please find below is the webrev that was pushed as part of "JDK-8165437".

Webrev  : http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html

Thanks,

Vyom


From michael.x.mcmahon at oracle.com  Tue May  9 11:35:24 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 09 May 2017 12:35:24 +0100
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
In-Reply-To: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
References: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
Message-ID: <5911A97C.6020208@oracle.com>

This looks fine to me Vyom.

Thanks,
Michael

On 09/05/2017, 10:55, Vyom Tewari wrote:
> Hi ,
>
> Please review the code change for below issue.
>
> Webrev  : 
> http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
>
> BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905
>
> This issue is duplicate of "JDK-8165437", where pushed code change 
> failed on 32 bit platforms so we revert back code changes as part of 
> "JDK-8179602".
>
> Please find below is the webrev that was pushed as part of "JDK-8165437".
>
> Webrev  : 
> http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html
>
> Thanks,
>
> Vyom
>

From pavel.rappo at oracle.com  Tue May  9 13:52:42 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 9 May 2017 14:52:42 +0100
Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox
 repo
Message-ID: <BFC24D27-4228-4DC1-A6A5-9F819CC5222B@oracle.com>

Hello,

Please review the following change:

  http://cr.openjdk.java.net/~prappo/8179021/webrev.00/

Along with refactoring this change contains a number of critical fixes for
WebSocket. Critical fixes are applied to Receiver, WebSocketImpl and
OpeningHandshake.

Also this change removes 2 convenience methods and 1 constant from WebSocket
interface. Since this interface is a part of incubation feature there shouldn't
be any problem. Those members were initially controversial. 

Thanks,
-Pavel


From daniel.fuchs at oracle.com  Tue May  9 14:49:46 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 9 May 2017 15:49:46 +0100
Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the
 sandbox repo
In-Reply-To: <BFC24D27-4228-4DC1-A6A5-9F819CC5222B@oracle.com>
References: <BFC24D27-4228-4DC1-A6A5-9F819CC5222B@oracle.com>
Message-ID: <1812b3f4-d35c-1198-d7b4-09d30cbc973b@oracle.com>

Hi Pavel,

A few nits:

jdk/incubator/http/WebSocket.java:

line 501: should use {@linkplain

Also (line 46 and 501) the link target #sendClose may cause trouble
if sendClose is overloaded - so I wonder if it may be better to
have the  full prototype there:
    #sendClose(int, String)
(though I guess it's OK as long as there is only 1 sendClose method).

jdk/incubator/http/internal/websocket/OutgoingMessage.java

  75         // maskingKeys, CharsetDecoder and should be here

  what does this means? are some words missing?

jdk/incubator/http/internal/websocket/Transmitter.java

   58      * The supplied handler may be invoked in the calling thread, 
so watch out
   59      * for stack overflow, if there's a possibility of send being 
called again
   60      * from the handler.

Can we reformulate this again?
Something like:

         * The supplied handler may be invoked in the calling thread.
         * A {@code StackOverflowException} may thus occur if there's a
         * possibility that this method is called again by the supplied
         * handler.

   93                   // or tuned off

I guess you meant 'turned off'

jdk/incubator/http/internal/websocket/WebSocketImpl.java

196         if (alreadyCompleted) {
197             throw new InternalError();
...
321         if (!added) {
322             throw new InternalError();

A comment similar to the other places where InternalError is thrown
would be nice.

best regards,

-- daniel


On 09/05/2017 14:52, Pavel Rappo wrote:
> Hello,
>
> Please review the following change:
>
>   http://cr.openjdk.java.net/~prappo/8179021/webrev.00/
>
> Along with refactoring this change contains a number of critical fixes for
> WebSocket. Critical fixes are applied to Receiver, WebSocketImpl and
> OpeningHandshake.
>
> Also this change removes 2 convenience methods and 1 constant from WebSocket
> interface. Since this interface is a part of incubation feature there shouldn't
> be any problem. Those members were initially controversial.
>
> Thanks,
> -Pavel
>


From claes.redestad at oracle.com  Tue May  9 17:50:21 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 9 May 2017 19:50:21 +0200
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
In-Reply-To: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
References: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
Message-ID: <b4d161b7-2388-ca94-222c-8acf72e9b915@oracle.com>

Hi,

doesn't this need to consider numerical overflows, e.g., what happens if 
someone sets a timeout value near 0x7fffffffffffffffL before and after 
this change?

/Claes

On 2017-05-09 11:55, Vyom Tewari wrote:
> Hi ,
>
> Please review the code change for below issue.
>
> Webrev  : 
> http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
>
> BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905
>
> This issue is duplicate of "JDK-8165437", where pushed code change 
> failed on 32 bit platforms so we revert back code changes as part of 
> "JDK-8179602".
>
> Please find below is the webrev that was pushed as part of "JDK-8165437".
>
> Webrev  : 
> http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html
>
> Thanks,
>
> Vyom
>


From vyom.tewari at oracle.com  Wed May 10 06:28:07 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 10 May 2017 11:58:07 +0530
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
In-Reply-To: <b4d161b7-2388-ca94-222c-8acf72e9b915@oracle.com>
References: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
 <b4d161b7-2388-ca94-222c-8acf72e9b915@oracle.com>
Message-ID: <b4927dc4-c01e-40b7-a450-685ccea35f62@oracle.com>

Hi Claes,

thanks for review, timeout is "int" so even if you set max(2147483647) 
value that int data type can hold, there will not be any overflow. If 
you try to set very large number like "0x7fffffffffffffff" to int data 
type you will get compile time error(integer number too large: 
7fffffffffffffff).

Thanks,
Vyom

On Tuesday 09 May 2017 11:20 PM, Claes Redestad wrote:
> Hi,
>
> doesn't this need to consider numerical overflows, e.g., what happens 
> if someone sets a timeout value near 0x7fffffffffffffffL before and 
> after this change?
>
> /Claes
>
> On 2017-05-09 11:55, Vyom Tewari wrote:
>> Hi ,
>>
>> Please review the code change for below issue.
>>
>> Webrev  : 
>> http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
>>
>> BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905
>>
>> This issue is duplicate of "JDK-8165437", where pushed code change 
>> failed on 32 bit platforms so we revert back code changes as part of 
>> "JDK-8179602".
>>
>> Please find below is the webrev that was pushed as part of 
>> "JDK-8165437".
>>
>> Webrev  : 
>> http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html
>>
>> Thanks,
>>
>> Vyom
>>
>


From claes.redestad at oracle.com  Wed May 10 08:53:21 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 May 2017 10:53:21 +0200
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
In-Reply-To: <b4927dc4-c01e-40b7-a450-685ccea35f62@oracle.com>
References: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
 <b4d161b7-2388-ca94-222c-8acf72e9b915@oracle.com>
 <b4927dc4-c01e-40b7-a450-685ccea35f62@oracle.com>
Message-ID: <9c3ab492-b202-127e-cfab-7c221b001de2@oracle.com>

Hi,

yes, when we do int -> jlong conversion before multiplication is fine, 
but there are some methods, such as NET_Timeout that takes long timeout 
that seemed in danger.

After offline discussion it seems these are always called with what's 
essentially an int thus we should be safe, but as a follow-up I suggest 
narrowing to int or jint in such method signatures just to make this clear.

Thanks!

/Claes

On 2017-05-10 08:28, Vyom Tewari wrote:
> Hi Claes,
>
> thanks for review, timeout is "int" so even if you set max(2147483647) 
> value that int data type can hold, there will not be any overflow. If 
> you try to set very large number like "0x7fffffffffffffff" to int data 
> type you will get compile time error(integer number too large: 
> 7fffffffffffffff).
>
> Thanks,
> Vyom
>
> On Tuesday 09 May 2017 11:20 PM, Claes Redestad wrote:
>> Hi,
>>
>> doesn't this need to consider numerical overflows, e.g., what happens 
>> if someone sets a timeout value near 0x7fffffffffffffffL before and 
>> after this change?
>>
>> /Claes
>>
>> On 2017-05-09 11:55, Vyom Tewari wrote:
>>> Hi ,
>>>
>>> Please review the code change for below issue.
>>>
>>> Webrev  : 
>>> http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
>>>
>>> BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905
>>>
>>> This issue is duplicate of "JDK-8165437", where pushed code change 
>>> failed on 32 bit platforms so we revert back code changes as part of 
>>> "JDK-8179602".
>>>
>>> Please find below is the webrev that was pushed as part of 
>>> "JDK-8165437".
>>>
>>> Webrev  : 
>>> http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>
>


From michael.x.mcmahon at oracle.com  Wed May 10 09:22:44 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 10 May 2017 10:22:44 +0100
Subject: RFR 8179905: Remove the use of gettimeofday in Networking code
In-Reply-To: <9c3ab492-b202-127e-cfab-7c221b001de2@oracle.com>
References: <38219fff-85ff-4adf-8fa0-d49d33ff99e8@oracle.com>
 <b4d161b7-2388-ca94-222c-8acf72e9b915@oracle.com>
 <b4927dc4-c01e-40b7-a450-685ccea35f62@oracle.com>
 <9c3ab492-b202-127e-cfab-7c221b001de2@oracle.com>
Message-ID: <5912DBE4.8040202@oracle.com>

Yes, I think the only public API that uses a long timeout value is the 
NIO Selector class
and this doesn't use NET_Timeout() in its implementation.

- Michael

On 10/05/2017, 09:53, Claes Redestad wrote:
> Hi,
>
> yes, when we do int -> jlong conversion before multiplication is fine, 
> but there are some methods, such as NET_Timeout that takes long 
> timeout that seemed in danger.
>
> After offline discussion it seems these are always called with what's 
> essentially an int thus we should be safe, but as a follow-up I 
> suggest narrowing to int or jint in such method signatures just to 
> make this clear.
>
> Thanks!
>
> /Claes
>
> On 2017-05-10 08:28, Vyom Tewari wrote:
>> Hi Claes,
>>
>> thanks for review, timeout is "int" so even if you set 
>> max(2147483647) value that int data type can hold, there will not be 
>> any overflow. If you try to set very large number like 
>> "0x7fffffffffffffff" to int data type you will get compile time 
>> error(integer number too large: 7fffffffffffffff).
>>
>> Thanks,
>> Vyom
>>
>> On Tuesday 09 May 2017 11:20 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> doesn't this need to consider numerical overflows, e.g., what 
>>> happens if someone sets a timeout value near 0x7fffffffffffffffL 
>>> before and after this change?
>>>
>>> /Claes
>>>
>>> On 2017-05-09 11:55, Vyom Tewari wrote:
>>>> Hi ,
>>>>
>>>> Please review the code change for below issue.
>>>>
>>>> Webrev  : 
>>>> http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html
>>>>
>>>> BugId     : https://bugs.openjdk.java.net/browse/JDK-8179905
>>>>
>>>> This issue is duplicate of "JDK-8165437", where pushed code change 
>>>> failed on 32 bit platforms so we revert back code changes as part 
>>>> of "JDK-8179602".
>>>>
>>>> Please find below is the webrev that was pushed as part of 
>>>> "JDK-8165437".
>>>>
>>>> Webrev  : 
>>>> http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>
>>
>

From pavel.rappo at oracle.com  Wed May 10 11:03:42 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 10 May 2017 12:03:42 +0100
Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the
 sandbox repo
In-Reply-To: <1812b3f4-d35c-1198-d7b4-09d30cbc973b@oracle.com>
References: <BFC24D27-4228-4DC1-A6A5-9F819CC5222B@oracle.com>
 <1812b3f4-d35c-1198-d7b4-09d30cbc973b@oracle.com>
Message-ID: <A260EF1B-0D43-47BB-826D-0C431735A9A2@oracle.com>

Daniel, thanks a lot for looking into this! I've addressed most of your suggestions:

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

> On 9 May 2017, at 15:49, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Pavel,
> 
> A few nits:
> 
> jdk/incubator/http/WebSocket.java:
> 
> line 501: should use {@linkplain
> 
> Also (line 46 and 501) the link target #sendClose may cause trouble
> if sendClose is overloaded - so I wonder if it may be better to
> have the  full prototype there:
>   #sendClose(int, String)
> (though I guess it's OK as long as there is only 1 sendClose method).
> 
> jdk/incubator/http/internal/websocket/OutgoingMessage.java
> 
> 75         // maskingKeys, CharsetDecoder and should be here
> 
> what does this means? are some words missing?
> 
> jdk/incubator/http/internal/websocket/Transmitter.java
> 
>  58      * The supplied handler may be invoked in the calling thread, so watch out
>  59      * for stack overflow, if there's a possibility of send being called again
>  60      * from the handler.
> 
> Can we reformulate this again?
> Something like:
> 
>        * The supplied handler may be invoked in the calling thread.
>        * A {@code StackOverflowException} may thus occur if there's a
>        * possibility that this method is called again by the supplied
>        * handler.
> 
>  93                   // or tuned off
> 
> I guess you meant 'turned off'
> 
> jdk/incubator/http/internal/websocket/WebSocketImpl.java
> 
> 196         if (alreadyCompleted) {
> 197             throw new InternalError();
> ...
> 321         if (!added) {
> 322             throw new InternalError();
> 
> A comment similar to the other places where InternalError is thrown
> would be nice.
> 
> best regards,
> 
> -- daniel
> 
> 
> On 09/05/2017 14:52, Pavel Rappo wrote:
>> Hello,
>> 
>> Please review the following change:
>> 
>>  http://cr.openjdk.java.net/~prappo/8179021/webrev.00/
>> 
>> Along with refactoring this change contains a number of critical fixes for
>> WebSocket. Critical fixes are applied to Receiver, WebSocketImpl and
>> OpeningHandshake.
>> 
>> Also this change removes 2 convenience methods and 1 constant from WebSocket
>> interface. Since this interface is a part of incubation feature there shouldn't
>> be any problem. Those members were initially controversial.
>> 
>> Thanks,
>> -Pavel
>> 
> 


From daniel.fuchs at oracle.com  Wed May 10 12:31:34 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 May 2017 13:31:34 +0100
Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the
 sandbox repo
In-Reply-To: <A260EF1B-0D43-47BB-826D-0C431735A9A2@oracle.com>
References: <BFC24D27-4228-4DC1-A6A5-9F819CC5222B@oracle.com>
 <1812b3f4-d35c-1198-d7b4-09d30cbc973b@oracle.com>
 <A260EF1B-0D43-47BB-826D-0C431735A9A2@oracle.com>
Message-ID: <eaf2dd1c-7751-d921-15ed-a280371cad4e@oracle.com>

Hi Pavel,

Looks good.
Some files didn't have their copyright years updated - maybe
you could fix that before pushing.

jdk/incubator/http/internal/websocket/OpeningHandshake.java
line 121: It might be worth mentioning that '13' is mandated by
[RFC 6455](https://tools.ietf.org/html/rfc6455)

best regards,

-- daniel

On 10/05/2017 12:03, Pavel Rappo wrote:
> Daniel, thanks a lot for looking into this! I've addressed most of your suggestions:
>
>     http://cr.openjdk.java.net/~prappo/8179021/webrev.01/
>
>> On 9 May 2017, at 15:49, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> A few nits:
>>
>> jdk/incubator/http/WebSocket.java:
>>
>> line 501: should use {@linkplain
>>
>> Also (line 46 and 501) the link target #sendClose may cause trouble
>> if sendClose is overloaded - so I wonder if it may be better to
>> have the  full prototype there:
>>   #sendClose(int, String)
>> (though I guess it's OK as long as there is only 1 sendClose method).
>>
>> jdk/incubator/http/internal/websocket/OutgoingMessage.java
>>
>> 75         // maskingKeys, CharsetDecoder and should be here
>>
>> what does this means? are some words missing?
>>
>> jdk/incubator/http/internal/websocket/Transmitter.java
>>
>>  58      * The supplied handler may be invoked in the calling thread, so watch out
>>  59      * for stack overflow, if there's a possibility of send being called again
>>  60      * from the handler.
>>
>> Can we reformulate this again?
>> Something like:
>>
>>        * The supplied handler may be invoked in the calling thread.
>>        * A {@code StackOverflowException} may thus occur if there's a
>>        * possibility that this method is called again by the supplied
>>        * handler.
>>
>>  93                   // or tuned off
>>
>> I guess you meant 'turned off'
>>
>> jdk/incubator/http/internal/websocket/WebSocketImpl.java
>>
>> 196         if (alreadyCompleted) {
>> 197             throw new InternalError();
>> ...
>> 321         if (!added) {
>> 322             throw new InternalError();
>>
>> A comment similar to the other places where InternalError is thrown
>> would be nice.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 09/05/2017 14:52, Pavel Rappo wrote:
>>> Hello,
>>>
>>> Please review the following change:
>>>
>>>  http://cr.openjdk.java.net/~prappo/8179021/webrev.00/
>>>
>>> Along with refactoring this change contains a number of critical fixes for
>>> WebSocket. Critical fixes are applied to Receiver, WebSocketImpl and
>>> OpeningHandshake.
>>>
>>> Also this change removes 2 convenience methods and 1 constant from WebSocket
>>> interface. Since this interface is a part of incubation feature there shouldn't
>>> be any problem. Those members were initially controversial.
>>>
>>> Thanks,
>>> -Pavel
>>>
>>
>


From kumar.x.srinivasan at oracle.com  Wed May 10 18:57:57 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 10 May 2017 11:57:57 -0700
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging,
 jdk.httpserver, jdk.net, jdk.sctp
Message-ID: <591362B5.9070806@oracle.com>

Hello,

Please review HTML5 related changes to the above modules, please
note there are no changes to the verbiage.

Thanks
Kumar

Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8179697

From daniel.fuchs at oracle.com  Thu May 11 18:19:31 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 May 2017 19:19:31 +0100
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <591362B5.9070806@oracle.com>
References: <591362B5.9070806@oracle.com>
Message-ID: <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>

Hi Kumar,

Looks mostly good.
I'm not too sure about the changes from <h4> to <h3> and <h2> to
<h3> though.

Now some of the package.html files in java.naming retain their
<h2>Package Specification</h2> section, and others have it
changed to <h3>Package Specification</h3>.

best regards,

-- daniel

On 10/05/2017 19:57, Kumar Srinivasan wrote:
> Hello,
>
> Please review HTML5 related changes to the above modules, please
> note there are no changes to the verbiage.
>
> Thanks
> Kumar
>
> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697


From kumar.x.srinivasan at oracle.com  Thu May 11 23:16:56 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 11 May 2017 16:16:56 -0700
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
Message-ID: <5914F0E8.2090707@oracle.com>


Hi Daniel,

As Jon surmised, this is an ARIA/accessibility requirement, in that one 
can't
have holes in the usage of h* tags,  as javadoc tool itself uses h1 and h2,
the API docs have to start with h3.

With respect to your comment, the h2->h3 is erroneous and have reverted
them back, so the only changes wrt. h* are h4 -> h3.

New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/

Thanks
Kumar



> Hi Kumar,
>
> Looks mostly good.
> I'm not too sure about the changes from <h4> to <h3> and <h2> to
> <h3> though.
>
> Now some of the package.html files in java.naming retain their
> <h2>Package Specification</h2> section, and others have it
> changed to <h3>Package Specification</h3>.
>
> best regards,
>
> -- daniel
>
> On 10/05/2017 19:57, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review HTML5 related changes to the above modules, please
>> note there are no changes to the verbiage.
>>
>> Thanks
>> Kumar
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
>


From daniel.fuchs at oracle.com  Fri May 12 09:18:42 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 May 2017 10:18:42 +0100
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <5914F0E8.2090707@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
 <5914F0E8.2090707@oracle.com>
Message-ID: <3227dd91-0ab8-b411-322e-312026503b9e@oracle.com>

Hi Kumar,

On 12/05/2017 00:16, Kumar Srinivasan wrote:
>
> Hi Daniel,
>
> As Jon surmised, this is an ARIA/accessibility requirement, in that one
> can't
> have holes in the usage of h* tags,  as javadoc tool itself uses h1 and h2,
> the API docs have to start with h3.
>
> With respect to your comment, the h2->h3 is erroneous and have reverted
> them back, so the only changes wrt. h* are h4 -> h3.
>
> New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/

This looks good now. Thanks for explaining the issue with holes in
the usage of h* tags - it makes it much easier to understand the
rationale behind the changes.

A few nits:
com/sun/net/httpserver/HttpServer.java:
   62  * <table><caption  style="display:none">description</caption>
   71  * <table><caption  style="display:none">description</caption>

there are 2 spaces after 'caption'


javax/naming/event/package.html:
   82 <h4>Threading Issues</h4>
  101 <h4>Exception Handling</h4>

I wonder if these two tags should be changed to <h3> as well,
so as not to introduce a hierarchy that was not there before.
(these do not seem to be sub-concepts of <h3>Naming Events</h3>
  as far as I can see - but then I'm not a JNDI expert)

Otherwise looks good, no need for a new webrev.

best regards,

-- daniel


>
> Thanks
> Kumar
>
>
>
>> Hi Kumar,
>>
>> Looks mostly good.
>> I'm not too sure about the changes from <h4> to <h3> and <h2> to
>> <h3> though.
>>
>> Now some of the package.html files in java.naming retain their
>> <h2>Package Specification</h2> section, and others have it
>> changed to <h3>Package Specification</h3>.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 10/05/2017 19:57, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review HTML5 related changes to the above modules, please
>>> note there are no changes to the verbiage.
>>>
>>> Thanks
>>> Kumar
>>>
>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
>>
>


From michael.x.mcmahon at oracle.com  Fri May 12 16:24:09 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 12 May 2017 17:24:09 +0100
Subject: RFR 9: 8180303: Remove technote doc link from
 ProxySelector/B8035158.java test
Message-ID: <5915E1A9.2040507@oracle.com>

This is a trivial test change (in comments only) to remove a URL 
reference to a document
whose location is different in the JDK 9 docs tree. The link is not 
needed in the test.
So, it is removed.

http://cr.openjdk.java.net/~michaelm/8180303/webrev.1/index.html

Thanks,
Michael.

From chris.hegarty at oracle.com  Fri May 12 16:25:01 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 May 2017 17:25:01 +0100
Subject: RFR 9: 8180303: Remove technote doc link from
 ProxySelector/B8035158.java test
In-Reply-To: <5915E1A9.2040507@oracle.com>
References: <5915E1A9.2040507@oracle.com>
Message-ID: <8a407677-5e12-66cc-6432-d6402a301dcc@oracle.com>

On 12/05/17 17:24, Michael McMahon wrote:
> This is a trivial test change (in comments only) to remove a URL
> reference to a document
> whose location is different in the JDK 9 docs tree. The link is not
> needed in the test.
> So, it is removed.
>
> http://cr.openjdk.java.net/~michaelm/8180303/webrev.1/index.html

Looks fine.

-Chris

From thomas.stuefe at gmail.com  Tue May 16 12:50:32 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 16 May 2017 14:50:32 +0200
Subject: RFR (xxs): 8180424: Another build issue on AIX after 8034174
Message-ID: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>

Hi all,

may I have a review for this tiny fix:

Issue: https://bugs.openjdk.java.net/browse/JDK-8180424
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8180424-another-build-issue-on-aix-after-8034174/webrev.00/webrev/

The prototypes for NET_RecvFrom and NET_Accept do not match their
implementations for AIX since 8034174. This did not lead to an error in
jdk9 because there, the header (net_util_md.h) was not included by
aix_close.c. In JDK10, it is included and therefore does not build.

I believe this did not lead to a runtime error on jdk9, at least not for
the typical values involved; the mismatch is between int* and unsigned int*
(native socklen_t).

Kind Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170516/ecf03caa/attachment.html>

From christoph.langer at sap.com  Wed May 17 15:11:26 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 May 2017 15:11:26 +0000
Subject: RFR (xxs): 8180424: Another build issue on AIX after 8034174
In-Reply-To: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>
References: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>
Message-ID: <57ba6104846c4ca2b8fd496f119ee853@sap.com>

Hi Thomas,

this looks good and should definitely be downported to JDK9 as soon as possible.

Best regards
Christoph

From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
Sent: Dienstag, 16. Mai 2017 14:51
To: ppc-aix-port-dev at openjdk.java.net; net-dev <net-dev at openjdk.java.net>
Subject: RFR (xxs): 8180424: Another build issue on AIX after 8034174

Hi all,

may I have a review for this tiny fix:

Issue: https://bugs.openjdk.java.net/browse/JDK-8180424
webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8180424-another-build-issue-on-aix-after-8034174/webrev.00/webrev/

The prototypes for NET_RecvFrom and NET_Accept do not match their implementations for AIX since 8034174. This did not lead to an error in jdk9 because there, the header (net_util_md.h) was not included by aix_close.c. In JDK10, it is included and therefore does not build.

I believe this did not lead to a runtime error on jdk9, at least not for the typical values involved; the mismatch is between int* and unsigned int* (native socklen_t).

Kind Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170517/7ba6b196/attachment.html>

From vyom.tewari at oracle.com  Wed May 17 15:17:26 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 17 May 2017 20:47:26 +0530
Subject: RFR (xxs): 8180424: Another build issue on AIX after 8034174
In-Reply-To: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>
References: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>
Message-ID: <dfbcd3f8-1956-34d2-8549-6921e9a0d0a1@oracle.com>

Hi Thomas,

fix look good to me, but i am not jdk10 reviewer.

Thanks,

Vyom


On Tuesday 16 May 2017 06:20 PM, Thomas St?fe wrote:
> Hi all,
>
> may I have a review for this tiny fix:
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8180424
> webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8180424-another-build-issue-on-aix-after-8034174/webrev.00/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8180424-another-build-issue-on-aix-after-8034174/webrev.00/webrev/>
>
> The prototypes for NET_RecvFrom and NET_Accept do not match their 
> implementations for AIX since 8034174. This did not lead to an error 
> in jdk9 because there, the header (net_util_md.h) was not included by 
> aix_close.c. In JDK10, it is included and therefore does not build.
>
> I believe this did not lead to a runtime error on jdk9, at least not 
> for the typical values involved; the mismatch is between int* and 
> unsigned int* (native socklen_t).
>
> Kind Regards, Thomas


From thomas.stuefe at gmail.com  Thu May 18 10:07:55 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 18 May 2017 12:07:55 +0200
Subject: RFR (xxs): 8180424: Another build issue on AIX after 8034174
In-Reply-To: <dfbcd3f8-1956-34d2-8549-6921e9a0d0a1@oracle.com>
References: <CAA-vtUxE4PA3QmS6JCTnRdjqmeQVqxEPk7d55yoRDmxVCfWV4Q@mail.gmail.com>
 <dfbcd3f8-1956-34d2-8549-6921e9a0d0a1@oracle.com>
Message-ID: <CAA-vtUyyJa0Ji7PKK2TVbR1EuksGCad8ycZrwOcZpc=-YYRKpw@mail.gmail.com>

Thanks guys!

I requested a fix for jdk9. Lets see how that goes.

Best Regards, Thomas

On Wed, May 17, 2017 at 5:17 PM, Vyom Tewari <vyom.tewari at oracle.com> wrote:

> Hi Thomas,
>
> fix look good to me, but i am not jdk10 reviewer.
>
> Thanks,
>
> Vyom
>
>
> On Tuesday 16 May 2017 06:20 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> may I have a review for this tiny fix:
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8180424
>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8180424-another-
>> build-issue-on-aix-after-8034174/webrev.00/webrev/ <
>> http://cr.openjdk.java.net/%7Estuefe/webrevs/8180424-anothe
>> r-build-issue-on-aix-after-8034174/webrev.00/webrev/>
>>
>> The prototypes for NET_RecvFrom and NET_Accept do not match their
>> implementations for AIX since 8034174. This did not lead to an error in
>> jdk9 because there, the header (net_util_md.h) was not included by
>> aix_close.c. In JDK10, it is included and therefore does not build.
>>
>> I believe this did not lead to a runtime error on jdk9, at least not for
>> the typical values involved; the mismatch is between int* and unsigned int*
>> (native socklen_t).
>>
>> Kind Regards, Thomas
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170518/e41ce59b/attachment.html>

From michael.x.mcmahon at oracle.com  Fri May 19 14:29:03 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 19 May 2017 15:29:03 +0100
Subject: RFR (9): 8180498 Remove httpclient internal APIs which supply
 ByteBuffers to read calls
Message-ID: <591F012F.60707@oracle.com>

Could I get the following change reviewed please?

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

Webrev: http://cr.openjdk.java.net/~michaelm/8180498/webrev.1/

Thanks,
Michael.

From daniel.fuchs at oracle.com  Fri May 19 16:42:45 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 19 May 2017 17:42:45 +0100
Subject: RFR (9): 8180498 Remove httpclient internal APIs which supply
 ByteBuffers to read calls
In-Reply-To: <591F012F.60707@oracle.com>
References: <591F012F.60707@oracle.com>
Message-ID: <c96ed358-e4f1-727f-3b71-dcb20822cc31@oracle.com>

Hi Michael,

Looks good - but what purpose does the rxBuffer now
serves in Exchange.java?

If I'm not mistaken it's an empty 0 sized buffer that
is never replaced... At the very least it should be
final (and not volatile), but maybe getBuffer() could
simply be removed here?

best regards,

-- daniel

On 19/05/2017 15:29, Michael McMahon wrote:
> Could I get the following change reviewed please?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180498
>
> Webrev: http://cr.openjdk.java.net/~michaelm/8180498/webrev.1/
>
> Thanks,
> Michael.


From michael.x.mcmahon at oracle.com  Fri May 19 17:01:24 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 19 May 2017 18:01:24 +0100
Subject: RFR (9): 8180498 Remove httpclient internal APIs which supply
 ByteBuffers to read calls
In-Reply-To: <c96ed358-e4f1-727f-3b71-dcb20822cc31@oracle.com>
References: <591F012F.60707@oracle.com>
 <c96ed358-e4f1-727f-3b71-dcb20822cc31@oracle.com>
Message-ID: <591F24E4.7020605@oracle.com>

You're right Daniel. It's actually a vestige of the original intention
to support pipelined requests, which are not supported. getBuffer() is 
actually
called from Http1Response, but it would be better to get the empty 
buffer reference
at that point.

Thanks
Michael

On 19/05/2017, 17:42, Daniel Fuchs wrote:
> Hi Michael,
>
> Looks good - but what purpose does the rxBuffer now
> serves in Exchange.java?
>
> If I'm not mistaken it's an empty 0 sized buffer that
> is never replaced... At the very least it should be
> final (and not volatile), but maybe getBuffer() could
> simply be removed here?
>
> best regards,
>
> -- daniel
>
> On 19/05/2017 15:29, Michael McMahon wrote:
>> Could I get the following change reviewed please?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180498
>>
>> Webrev: http://cr.openjdk.java.net/~michaelm/8180498/webrev.1/
>>
>> Thanks,
>> Michael.
>

From michael.x.mcmahon at oracle.com  Mon May 22 14:38:41 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 22 May 2017 15:38:41 +0100
Subject: RFR (9): 8180498 Remove httpclient internal APIs which supply
 ByteBuffers to read calls
In-Reply-To: <591F24E4.7020605@oracle.com>
References: <591F012F.60707@oracle.com>
 <c96ed358-e4f1-727f-3b71-dcb20822cc31@oracle.com>
 <591F24E4.7020605@oracle.com>
Message-ID: <5922F7F1.7050305@oracle.com>

Daniel

I've updated the webrev at 
http://cr.openjdk.java.net/~michaelm/8180498/webrev.2/

The diffs between the two versions is the following:

Thanks,
Michael.

./src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Exchange.java

36d35
< import java.nio.ByteBuffer;
79,81d77
<     // buffer for receiving response headers
<     private volatile ByteBuffer rxBuffer = Utils.EMPTY_BYTEBUFFER;
<
124,127d119
<     ByteBuffer getBuffer() {
<         return rxBuffer;
<     }
<

./src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http1Exchange.java

77c77
<         this.buffer = exchange.getBuffer();
---
 >         this.buffer = Utils.EMPTY_BYTEBUFFER;

---
 >         this.buffer = Utils.EMPTY_BYTEBUFFER;


On 19/05/2017, 18:01, Michael McMahon wrote:
> You're right Daniel. It's actually a vestige of the original intention
> to support pipelined requests, which are not supported. getBuffer() is 
> actually
> called from Http1Response, but it would be better to get the empty 
> buffer reference
> at that point.
>
> Thanks
> Michael
>
> On 19/05/2017, 17:42, Daniel Fuchs wrote:
>> Hi Michael,
>>
>> Looks good - but what purpose does the rxBuffer now
>> serves in Exchange.java?
>>
>> If I'm not mistaken it's an empty 0 sized buffer that
>> is never replaced... At the very least it should be
>> final (and not volatile), but maybe getBuffer() could
>> simply be removed here?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 19/05/2017 15:29, Michael McMahon wrote:
>>> Could I get the following change reviewed please?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180498
>>>
>>> Webrev: http://cr.openjdk.java.net/~michaelm/8180498/webrev.1/
>>>
>>> Thanks,
>>> Michael.
>>

From daniel.fuchs at oracle.com  Mon May 22 16:08:39 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 22 May 2017 17:08:39 +0100
Subject: RFR (9): 8180498 Remove httpclient internal APIs which supply
 ByteBuffers to read calls
In-Reply-To: <5922F7F1.7050305@oracle.com>
References: <591F012F.60707@oracle.com>
 <c96ed358-e4f1-727f-3b71-dcb20822cc31@oracle.com>
 <591F24E4.7020605@oracle.com> <5922F7F1.7050305@oracle.com>
Message-ID: <c0caf980-a374-37d9-3dc6-2f4baa5d1666@oracle.com>

On 22/05/2017 15:38, Michael McMahon wrote:
> Daniel
>
> I've updated the webrev at
> http://cr.openjdk.java.net/~michaelm/8180498/webrev.2/
>
> The diffs between the two versions is the following:

Looks good Michael!

-- daniel

>
> Thanks,
> Michael.
>
> ./src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Exchange.java
>
>
> 36d35
> < import java.nio.ByteBuffer;
> 79,81d77
> <     // buffer for receiving response headers
> <     private volatile ByteBuffer rxBuffer = Utils.EMPTY_BYTEBUFFER;
> <
> 124,127d119
> <     ByteBuffer getBuffer() {
> <         return rxBuffer;
> <     }
> <
>
> ./src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http1Exchange.java
>
>
> 77c77
> <         this.buffer = exchange.getBuffer();
> ---
>>         this.buffer = Utils.EMPTY_BYTEBUFFER;
>
> ---
>>         this.buffer = Utils.EMPTY_BYTEBUFFER;
>
>
> On 19/05/2017, 18:01, Michael McMahon wrote:
>> You're right Daniel. It's actually a vestige of the original intention
>> to support pipelined requests, which are not supported. getBuffer() is
>> actually
>> called from Http1Response, but it would be better to get the empty
>> buffer reference
>> at that point.
>>
>> Thanks
>> Michael
>>
>> On 19/05/2017, 17:42, Daniel Fuchs wrote:
>>> Hi Michael,
>>>
>>> Looks good - but what purpose does the rxBuffer now
>>> serves in Exchange.java?
>>>
>>> If I'm not mistaken it's an empty 0 sized buffer that
>>> is never replaced... At the very least it should be
>>> final (and not volatile), but maybe getBuffer() could
>>> simply be removed here?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 19/05/2017 15:29, Michael McMahon wrote:
>>>> Could I get the following change reviewed please?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180498
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~michaelm/8180498/webrev.1/
>>>>
>>>> Thanks,
>>>> Michael.
>>>


From daniel.fuchs at oracle.com  Wed May 24 09:16:45 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 May 2017 10:16:45 +0100
Subject: 9 (test only) RFR: 8180279: java/net/httpclient/whitebox/Driver.java
 failed due to timeout
Message-ID: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>

[sent by mistake to core-libs-dev, sorry for cross posting]

Hi,

Please find below a test-only fix for:

8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
https://bugs.openjdk.java.net/browse/JDK-8180279

The failing testcase is RawChannelTest.

The test appears to be failing because of a flaw in the test logic which
allowed for a race condition between the client and the (fake) server.

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

What can be seen from the traces is that when the test fails,
the client is writing bytes to the server and the server is
writing bytes to the client but the client never wakes up to read
the bytes. It can also be seen that the client has found some bytes
in the 'initialByteBuffer' of the RawChannel.

What happens here is that the initialRawBuffer has read all
the bytes that were available in the channel - and the server
is waiting for the client to stall before writing more bytes.
But the code that will unblock the server is never executed,
because it is triggered by a selector read event, and the
channel is already dry so the event is never fired.

I reworked the tests a bit, adding two new CountDownLatches to
ensure that 1. the client will always find initial bytes in the
channel's initialByteBuffer (the intermittent condition that made
the test fail) and 2. the server will wait for the client to
signal that it has got the initial bytes, and write an additional
chunk of bytes that will trigger the selector read (which will
in turn ensure that the client will unblock the server later on).

best regards,

-- daniel

From michael.x.mcmahon at oracle.com  Wed May 24 10:37:40 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 24 May 2017 11:37:40 +0100
Subject: 9 (test only) RFR: 8180279:
 java/net/httpclient/whitebox/Driver.java failed due to timeout
In-Reply-To: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>
References: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>
Message-ID: <59256274.5010007@oracle.com>

Hi Daniel,

Just so I understand correctly. The synchronization is needed
to guarantee that the error situation expected actually occurs,
where some data is left in this buffer on the client side
and it's not just dealing with some strange implementation detail of the 
test?

Michael

On 24/05/2017, 10:16, Daniel Fuchs wrote:
> [sent by mistake to core-libs-dev, sorry for cross posting]
>
> Hi,
>
> Please find below a test-only fix for:
>
> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
> https://bugs.openjdk.java.net/browse/JDK-8180279
>
> The failing testcase is RawChannelTest.
>
> The test appears to be failing because of a flaw in the test logic which
> allowed for a race condition between the client and the (fake) server.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
>
> What can be seen from the traces is that when the test fails,
> the client is writing bytes to the server and the server is
> writing bytes to the client but the client never wakes up to read
> the bytes. It can also be seen that the client has found some bytes
> in the 'initialByteBuffer' of the RawChannel.
>
> What happens here is that the initialRawBuffer has read all
> the bytes that were available in the channel - and the server
> is waiting for the client to stall before writing more bytes.
> But the code that will unblock the server is never executed,
> because it is triggered by a selector read event, and the
> channel is already dry so the event is never fired.
>
> I reworked the tests a bit, adding two new CountDownLatches to
> ensure that 1. the client will always find initial bytes in the
> channel's initialByteBuffer (the intermittent condition that made
> the test fail) and 2. the server will wait for the client to
> signal that it has got the initial bytes, and write an additional
> chunk of bytes that will trigger the selector read (which will
> in turn ensure that the client will unblock the server later on).
>
> best regards,
>
> -- daniel

From daniel.fuchs at oracle.com  Wed May 24 10:41:45 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 May 2017 11:41:45 +0100
Subject: 9 (test only) RFR: 8180279:
 java/net/httpclient/whitebox/Driver.java failed due to timeout
In-Reply-To: <59256274.5010007@oracle.com>
References: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>
 <59256274.5010007@oracle.com>
Message-ID: <12fb9b78-7065-bcd9-146e-d6e0e0698229@oracle.com>

On 24/05/2017 11:37, Michael McMahon wrote:
> Hi Daniel,
>
> Just so I understand correctly. The synchronization is needed
> to guarantee that the error situation expected actually occurs,
> where some data is left in this buffer on the client side
> and it's not just dealing with some strange implementation detail of the
> test?

Note sure what you're asking. I modified the test to make the
situation in which it failed the norm rather than the exception,
and I also modified the test to fix the race condition that
used to occur in this situation, so that the test no longer
(intermittently) fails.

best regards,

-- daniel

>
> Michael
>
> On 24/05/2017, 10:16, Daniel Fuchs wrote:
>> [sent by mistake to core-libs-dev, sorry for cross posting]
>>
>> Hi,
>>
>> Please find below a test-only fix for:
>>
>> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
>> https://bugs.openjdk.java.net/browse/JDK-8180279
>>
>> The failing testcase is RawChannelTest.
>>
>> The test appears to be failing because of a flaw in the test logic which
>> allowed for a race condition between the client and the (fake) server.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
>>
>> What can be seen from the traces is that when the test fails,
>> the client is writing bytes to the server and the server is
>> writing bytes to the client but the client never wakes up to read
>> the bytes. It can also be seen that the client has found some bytes
>> in the 'initialByteBuffer' of the RawChannel.
>>
>> What happens here is that the initialRawBuffer has read all
>> the bytes that were available in the channel - and the server
>> is waiting for the client to stall before writing more bytes.
>> But the code that will unblock the server is never executed,
>> because it is triggered by a selector read event, and the
>> channel is already dry so the event is never fired.
>>
>> I reworked the tests a bit, adding two new CountDownLatches to
>> ensure that 1. the client will always find initial bytes in the
>> channel's initialByteBuffer (the intermittent condition that made
>> the test fail) and 2. the server will wait for the client to
>> signal that it has got the initial bytes, and write an additional
>> chunk of bytes that will trigger the selector read (which will
>> in turn ensure that the client will unblock the server later on).
>>
>> best regards,
>>
>> -- daniel


From michael.x.mcmahon at oracle.com  Wed May 24 10:57:17 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 24 May 2017 11:57:17 +0100
Subject: 9 (test only) RFR: 8180279:
 java/net/httpclient/whitebox/Driver.java failed due to timeout
In-Reply-To: <12fb9b78-7065-bcd9-146e-d6e0e0698229@oracle.com>
References: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>
 <59256274.5010007@oracle.com>
 <12fb9b78-7065-bcd9-146e-d6e0e0698229@oracle.com>
Message-ID: <5925670D.70208@oracle.com>



On 24/05/2017, 11:41, Daniel Fuchs wrote:
> On 24/05/2017 11:37, Michael McMahon wrote:
>> Hi Daniel,
>>
>> Just so I understand correctly. The synchronization is needed
>> to guarantee that the error situation expected actually occurs,
>> where some data is left in this buffer on the client side
>> and it's not just dealing with some strange implementation detail of the
>> test?
>
> Note sure what you're asking. I modified the test to make the
> situation in which it failed the norm rather than the exception,
Yes, that's what I was asking. Thanks
> and I also modified the test to fix the race condition that
> used to occur in this situation, so that the test no longer
> (intermittently) fails.
>
> best regards,
>
> -- daniel
>
>>
>> Michael
>>
>> On 24/05/2017, 10:16, Daniel Fuchs wrote:
>>> [sent by mistake to core-libs-dev, sorry for cross posting]
>>>
>>> Hi,
>>>
>>> Please find below a test-only fix for:
>>>
>>> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
>>> https://bugs.openjdk.java.net/browse/JDK-8180279
>>>
>>> The failing testcase is RawChannelTest.
>>>
>>> The test appears to be failing because of a flaw in the test logic 
>>> which
>>> allowed for a race condition between the client and the (fake) server.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
>>>
>>> What can be seen from the traces is that when the test fails,
>>> the client is writing bytes to the server and the server is
>>> writing bytes to the client but the client never wakes up to read
>>> the bytes. It can also be seen that the client has found some bytes
>>> in the 'initialByteBuffer' of the RawChannel.
>>>
>>> What happens here is that the initialRawBuffer has read all
>>> the bytes that were available in the channel - and the server
>>> is waiting for the client to stall before writing more bytes.
>>> But the code that will unblock the server is never executed,
>>> because it is triggered by a selector read event, and the
>>> channel is already dry so the event is never fired.
>>>
>>> I reworked the tests a bit, adding two new CountDownLatches to
>>> ensure that 1. the client will always find initial bytes in the
>>> channel's initialByteBuffer (the intermittent condition that made
>>> the test fail) and 2. the server will wait for the client to
>>> signal that it has got the initial bytes, and write an additional
>>> chunk of bytes that will trigger the selector read (which will
>>> in turn ensure that the client will unblock the server later on).
>>>
>>> best regards,
>>>
>>> -- daniel
>

From michael.x.mcmahon at oracle.com  Wed May 24 15:54:44 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 24 May 2017 16:54:44 +0100
Subject: 9 (test only) RFR: 8180279:
 java/net/httpclient/whitebox/Driver.java failed due to timeout
In-Reply-To: <12fb9b78-7065-bcd9-146e-d6e0e0698229@oracle.com>
References: <55e490b9-b9d8-3573-6f66-755ffced16b5@oracle.com>
 <59256274.5010007@oracle.com>
 <12fb9b78-7065-bcd9-146e-d6e0e0698229@oracle.com>
Message-ID: <5925ACC4.4050303@oracle.com>

The change looks fine to me Daniel

- Michael

On 24/05/2017, 11:41, Daniel Fuchs wrote:
> On 24/05/2017 11:37, Michael McMahon wrote:
>> Hi Daniel,
>>
>> Just so I understand correctly. The synchronization is needed
>> to guarantee that the error situation expected actually occurs,
>> where some data is left in this buffer on the client side
>> and it's not just dealing with some strange implementation detail of the
>> test?
>
> Note sure what you're asking. I modified the test to make the
> situation in which it failed the norm rather than the exception,
> and I also modified the test to fix the race condition that
> used to occur in this situation, so that the test no longer
> (intermittently) fails.
>
> best regards,
>
> -- daniel
>
>>
>> Michael
>>
>> On 24/05/2017, 10:16, Daniel Fuchs wrote:
>>> [sent by mistake to core-libs-dev, sorry for cross posting]
>>>
>>> Hi,
>>>
>>> Please find below a test-only fix for:
>>>
>>> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
>>> https://bugs.openjdk.java.net/browse/JDK-8180279
>>>
>>> The failing testcase is RawChannelTest.
>>>
>>> The test appears to be failing because of a flaw in the test logic 
>>> which
>>> allowed for a race condition between the client and the (fake) server.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
>>>
>>> What can be seen from the traces is that when the test fails,
>>> the client is writing bytes to the server and the server is
>>> writing bytes to the client but the client never wakes up to read
>>> the bytes. It can also be seen that the client has found some bytes
>>> in the 'initialByteBuffer' of the RawChannel.
>>>
>>> What happens here is that the initialRawBuffer has read all
>>> the bytes that were available in the channel - and the server
>>> is waiting for the client to stall before writing more bytes.
>>> But the code that will unblock the server is never executed,
>>> because it is triggered by a selector read event, and the
>>> channel is already dry so the event is never fired.
>>>
>>> I reworked the tests a bit, adding two new CountDownLatches to
>>> ensure that 1. the client will always find initial bytes in the
>>> channel's initialByteBuffer (the intermittent condition that made
>>> the test fail) and 2. the server will wait for the client to
>>> signal that it has got the initial bytes, and write an additional
>>> chunk of bytes that will trigger the selector read (which will
>>> in turn ensure that the client will unblock the server later on).
>>>
>>> best regards,
>>>
>>> -- daniel
>

From felix.yang at oracle.com  Thu May 25 08:08:31 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Thu, 25 May 2017 16:08:31 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
Message-ID: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>

Hi there,

    please review following patch to convert all shell cases under 
java/net to plain java codes.

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8166139


Thanks,

Felix


From Roger.Riggs at Oracle.com  Thu May 25 19:24:10 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 15:24:10 -0400
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
Message-ID: <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>

Hi Felix,

closetest/CloseTest:

32: Please put the @modules directives together (and not repeat)

44: do not use wildcard imports  (reconfigure your IDE if necessary to 
avoid accidents).

63: setup() is invoked twice...  remove 1 or explain why 2 calls

69, 78,90,91,... :  space in method call is not proper style

sealing/CheckSealed.java:
  - Why is @test block removed?
     Should be converted to @run main CheckSealed

Regards, Roger



On 5/25/2017 4:08 AM, Felix Yang wrote:
> Hi there,
>
>    please review following patch to convert all shell cases under 
> java/net to plain java codes.
>
> Webrev:
>
>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8166139
>
>
> Thanks,
>
> Felix
>


From felix.yang at oracle.com  Fri May 26 03:14:32 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 26 May 2017 11:14:32 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
Message-ID: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>

Hi Roger,

     please review the updated webrev:

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/

Thanks,
Felix
On 2017/5/26 3:24, Roger Riggs wrote:
> Hi Felix,
>
> closetest/CloseTest:
>
> 32: Please put the @modules directives together (and not repeat)
Fixed
-Felix
>
> 44: do not use wildcard imports  (reconfigure your IDE if necessary to 
> avoid accidents).
Fixed and also organized imports in other test files
-Felix
>
> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
Fixed
-Felix
>
> 69, 78,90,91,... :  space in method call is not proper style
Fixed and also formatted other history codes. Just format only without 
logic change.
Not restricted to this test. I only formatted history codes "nearby", to 
avoid hiding real logic changes in the patch.

-Felix
>
> sealing/CheckSealed.java:
>  - Why is @test block removed?
>     Should be converted to @run main CheckSealed
There was a checksealed.sh. I replaced it with CheckSealedTest.java and 
declared @test there.
http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html

BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
removed. That is because corresponding prerequisite was removed even in 
JDK 8.

-Felix
>
> Regards, Roger
>
>
>
> On 5/25/2017 4:08 AM, Felix Yang wrote:
>> Hi there,
>>
>>    please review following patch to convert all shell cases under 
>> java/net to plain java codes.
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>
>>
>> Thanks,
>>
>> Felix
>>
>


From amy.lu at oracle.com  Fri May 26 03:43:10 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 26 May 2017 11:43:10 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
Message-ID: <c7c8e881-eb6d-cdaf-b2de-5d604fa2e3e9@oracle.com>

Hi, Felix

I noticed that CompilerUtils from jdk/test/lib/testlibrary is still used 
in tests. It?s better to use the version [1] from top level.

(Not a reviewer.)

Thanks,
Amy

[1] 
http://hg.openjdk.java.net/jdk10/jdk10/file/tip/test/lib/jdk/test/lib/compiler/CompilerUtils.java

On 5/26/17 11:14 AM, Felix Yang wrote:
> Hi Roger,
>
>     please review the updated webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>
> Thanks,
> Felix
> On 2017/5/26 3:24, Roger Riggs wrote:
>> Hi Felix,
>>
>> closetest/CloseTest:
>>
>> 32: Please put the @modules directives together (and not repeat)
> Fixed
> -Felix
>>
>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>> to avoid accidents).
> Fixed and also organized imports in other test files
> -Felix
>>
>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
> Fixed
> -Felix
>>
>> 69, 78,90,91,... :  space in method call is not proper style
> Fixed and also formatted other history codes. Just format only without 
> logic change.
> Not restricted to this test. I only formatted history codes "nearby", 
> to avoid hiding real logic changes in the patch.
>
> -Felix
>>
>> sealing/CheckSealed.java:
>>  - Why is @test block removed?
>>     Should be converted to @run main CheckSealed
> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
> and declared @test there.
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>
>
> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
> removed. That is because corresponding prerequisite was removed even 
> in JDK 8.
>
> -Felix
>>
>> Regards, Roger
>>
>>
>>
>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>> Hi there,
>>>
>>>    please review following patch to convert all shell cases under 
>>> java/net to plain java codes.
>>>
>>> Webrev:
>>>
>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>
>>> Bug:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>
>


From felix.yang at oracle.com  Fri May 26 04:46:40 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 26 May 2017 12:46:40 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <c7c8e881-eb6d-cdaf-b2de-5d604fa2e3e9@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <c7c8e881-eb6d-cdaf-b2de-5d604fa2e3e9@oracle.com>
Message-ID: <0f5ec587-1654-7f35-f88b-a7dd99ffe571@oracle.com>

Hi Amy,

     it is intended, because in my changes CompilerUtils is usually used 
together with JarUtils, which has not been moved yet. It is a bit 
confusing to add two lib directories, and even there are files with the 
same name. So it may be clearer to refactor lib usage unified in 
JDK-8075327 <https://bugs.openjdk.java.net/browse/JDK-8075327> or 
clean-ups tasks with single purpose.

Thanks,

Felix

On 2017/5/26 11:43, Amy Lu wrote:
> Hi, Felix
>
> I noticed that CompilerUtils from jdk/test/lib/testlibrary is still 
> used in tests. It?s better to use the version [1] from top level.
>
> (Not a reviewer.)
>
> Thanks,
> Amy
>
> [1] 
> http://hg.openjdk.java.net/jdk10/jdk10/file/tip/test/lib/jdk/test/lib/compiler/CompilerUtils.java
>
> On 5/26/17 11:14 AM, Felix Yang wrote:
>> Hi Roger,
>>
>>     please review the updated webrev:
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>
>> Thanks,
>> Felix
>> On 2017/5/26 3:24, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> closetest/CloseTest:
>>>
>>> 32: Please put the @modules directives together (and not repeat)
>> Fixed
>> -Felix
>>>
>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>>> to avoid accidents).
>> Fixed and also organized imports in other test files
>> -Felix
>>>
>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>> Fixed
>> -Felix
>>>
>>> 69, 78,90,91,... :  space in method call is not proper style
>> Fixed and also formatted other history codes. Just format only 
>> without logic change.
>> Not restricted to this test. I only formatted history codes "nearby", 
>> to avoid hiding real logic changes in the patch.
>>
>> -Felix
>>>
>>> sealing/CheckSealed.java:
>>>  - Why is @test block removed?
>>>     Should be converted to @run main CheckSealed
>> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
>> and declared @test there.
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>
>>
>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
>> removed. That is because corresponding prerequisite was removed even 
>> in JDK 8.
>>
>> -Felix
>>>
>>> Regards, Roger
>>>
>>>
>>>
>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>> Hi there,
>>>>
>>>>    please review following patch to convert all shell cases under 
>>>> java/net to plain java codes.
>>>>
>>>> Webrev:
>>>>
>>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>
>>>> Bug:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Felix
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170526/304a4b3c/attachment.html>

From Roger.Riggs at Oracle.com  Fri May 26 19:50:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 26 May 2017 15:50:46 -0400
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
Message-ID: <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>

Hi Felix,

fyi, there is a new version of webrev.ksh that provides convenient next 
and previous links.
http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh


CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not 
make sense.

Ditto: closetest/GetResourceAsStream.java

URLConnection/6212146/Test.java:47 typo: ULR -> URL

Regards, Roger


On 5/25/2017 11:14 PM, Felix Yang wrote:
> Hi Roger,
>
>     please review the updated webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>
> Thanks,
> Felix
> On 2017/5/26 3:24, Roger Riggs wrote:
>> Hi Felix,
>>
>> closetest/CloseTest:
>>
>> 32: Please put the @modules directives together (and not repeat)
> Fixed
> -Felix
>>
>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>> to avoid accidents).
> Fixed and also organized imports in other test files
> -Felix
>>
>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
> Fixed
> -Felix
>>
>> 69, 78,90,91,... :  space in method call is not proper style
> Fixed and also formatted other history codes. Just format only without 
> logic change.
> Not restricted to this test. I only formatted history codes "nearby", 
> to avoid hiding real logic changes in the patch.
>
> -Felix
>>
>> sealing/CheckSealed.java:
>>  - Why is @test block removed?
>>     Should be converted to @run main CheckSealed
> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
> and declared @test there.
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>
>
> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
> removed. That is because corresponding prerequisite was removed even 
> in JDK 8.
Perhaps then add a comment to CheckSealed.java indicating it is compiled 
and executed by CheckSealedTest.java.

Roger

>
> -Felix
>>
>> Regards, Roger
>>
>>
>>
>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>> Hi there,
>>>
>>>    please review following patch to convert all shell cases under 
>>> java/net to plain java codes.
>>>
>>> Webrev:
>>>
>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>
>>> Bug:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20170526/1c1e3332/attachment.html>

From felix.yang at oracle.com  Sat May 27 01:15:16 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Sat, 27 May 2017 09:15:16 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
Message-ID: <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>

Hi Roger,

     thanks for the comments. Please see the new webrev

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/

-Felix
On 2017/5/27 3:50, Roger Riggs wrote:
> Hi Felix,
>
> fyi, there is a new version of webrev.ksh that provides convenient 
> next and previous links.
> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>
>
> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not 
> make sense.
>
> Ditto: closetest/GetResourceAsStream.java
Removed such check, since the test depends on several system 
properties("test.src", "user.dir"). It is not expected to run outside jtreg.

-Felix
>
> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>
> Regards, Roger
>
>
> On 5/25/2017 11:14 PM, Felix Yang wrote:
>> Hi Roger,
>>
>>     please review the updated webrev:
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>
>> Thanks,
>> Felix
>> On 2017/5/26 3:24, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> closetest/CloseTest:
>>>
>>> 32: Please put the @modules directives together (and not repeat)
>> Fixed
>> -Felix
>>>
>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>>> to avoid accidents).
>> Fixed and also organized imports in other test files
>> -Felix
>>>
>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>> Fixed
>> -Felix
>>>
>>> 69, 78,90,91,... :  space in method call is not proper style
>> Fixed and also formatted other history codes. Just format only 
>> without logic change.
>> Not restricted to this test. I only formatted history codes "nearby", 
>> to avoid hiding real logic changes in the patch.
>>
>> -Felix
>>>
>>> sealing/CheckSealed.java:
>>>  - Why is @test block removed?
>>>     Should be converted to @run main CheckSealed
>> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
>> and declared @test there.
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>
>>
>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
>> removed. That is because corresponding prerequisite was removed even 
>> in JDK 8.
> Perhaps then add a comment to CheckSealed.java indicating it is 
> compiled and executed by CheckSealedTest.java.
>
> Roger
>
>>
>> -Felix
>>>
>>> Regards, Roger
>>>
>>>
>>>
>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>> Hi there,
>>>>
>>>>    please review following patch to convert all shell cases under 
>>>> java/net to plain java codes.
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Felix
>>>>
>>>
>>
>


From chris.hegarty at oracle.com  Mon May 29 10:19:00 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 May 2017 11:19:00 +0100
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
Message-ID: <ca7d2e13-eeba-73dc-76b2-f6d4dc445cc7@oracle.com>

Felix,

Thanks for taking this one. A few comments:


1) test/java/net/URLConnection/6212146/TestDriver.java
    Please check indentation around L81:

   80         Files.copy(testJar,
              ___________targetDir.resolve(ARCHIVE_NAME),
   81         ___________StandardCopyOption.REPLACE_EXISTING);


    Also, and more importantly, the ulimit that was executed in the shell
    is supposed to affect the potential file descriptor usage of the
    following java process. I believe that is not captured correctly
    in the TestDriver.java, since there is no parent/child relationship
    between the processes, no?


2) test/java/net/URLClassLoader/getresourceasstream/policy

    Please add a copyright/header.

3) getresourceasstream/TestDriver.java, CheckSealedTest.java, CloseTest.java

    If you statically import StandardCopyOption.REPLACE_EXISTING in a
    few places it may lead to a few shorter lines.

4) Why has the test for 5077773 simply been removed?

-Chris.


On 27/05/17 02:15, Felix Yang wrote:
> Hi Roger,
>
>     thanks for the comments. Please see the new webrev
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>
> -Felix
> On 2017/5/27 3:50, Roger Riggs wrote:
>> Hi Felix,
>>
>> fyi, there is a new version of webrev.ksh that provides convenient
>> next and previous links.
>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>>
>>
>>
>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>> make sense.
>>
>> Ditto: closetest/GetResourceAsStream.java
> Removed such check, since the test depends on several system
> properties("test.src", "user.dir"). It is not expected to run outside
> jtreg.
>
> -Felix
>>
>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>
>> Regards, Roger
>>
>>
>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>> Hi Roger,
>>>
>>>     please review the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>
>>> Thanks,
>>> Felix
>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>> Hi Felix,
>>>>
>>>> closetest/CloseTest:
>>>>
>>>> 32: Please put the @modules directives together (and not repeat)
>>> Fixed
>>> -Felix
>>>>
>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>> to avoid accidents).
>>> Fixed and also organized imports in other test files
>>> -Felix
>>>>
>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>> Fixed
>>> -Felix
>>>>
>>>> 69, 78,90,91,... :  space in method call is not proper style
>>> Fixed and also formatted other history codes. Just format only
>>> without logic change.
>>> Not restricted to this test. I only formatted history codes "nearby",
>>> to avoid hiding real logic changes in the patch.
>>>
>>> -Felix
>>>>
>>>> sealing/CheckSealed.java:
>>>>  - Why is @test block removed?
>>>>     Should be converted to @run main CheckSealed
>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>> and declared @test there.
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html
>>>
>>>
>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>> removed. That is because corresponding prerequisite was removed even
>>> in JDK 8.
>> Perhaps then add a comment to CheckSealed.java indicating it is
>> compiled and executed by CheckSealedTest.java.
>>
>> Roger
>>
>>>
>>> -Felix
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>>
>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>> Hi there,
>>>>>
>>>>>    please review following patch to convert all shell cases under
>>>>> java/net to plain java codes.
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>
>>>>> Bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Felix
>>>>>
>>>>
>>>
>>
>

From felix.yang at oracle.com  Mon May 29 15:17:20 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 29 May 2017 23:17:20 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <ca7d2e13-eeba-73dc-76b2-f6d4dc445cc7@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 <ca7d2e13-eeba-73dc-76b2-f6d4dc445cc7@oracle.com>
Message-ID: <f4ad23ff-530e-1f69-3de4-881b8bb8eb0a@oracle.com>

Hi Chris,

     please review the updated webrev below. Comments inline.

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/

-Felix
On 2017/5/29 18:19, Chris Hegarty wrote:
> Felix,
>
> Thanks for taking this one. A few comments:
>
>
> 1) test/java/net/URLConnection/6212146/TestDriver.java
>    Please check indentation around L81:
>
>   80         Files.copy(testJar,
>              ___________targetDir.resolve(ARCHIVE_NAME),
>   81         ___________StandardCopyOption.REPLACE_EXISTING);
>
>    Also, and more importantly, the ulimit that was executed in the shell
>    is supposed to affect the potential file descriptor usage of the
>    following java process. I believe that is not captured correctly
>    in the TestDriver.java, since there is no parent/child relationship
>    between the processes, no?
Fixed, thanks
Felix
>
>
> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>
>    Please add a copyright/header.
>
Checked existing test policy files, all of them have no 
copyright/header. So I hesitated to add here. Please confirm.

-Felix
> 3) getresourceasstream/TestDriver.java, CheckSealedTest.java, 
> CloseTest.java
>
>    If you statically import StandardCopyOption.REPLACE_EXISTING in a
>    few places it may lead to a few shorter lines.
Changed, thanks
Felix
>
> 4) Why has the test for 5077773 simply been removed?
As priorly commented, the test is probably not necessary.
Because it actually quits immediately after prerequisite checking for 
"javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it 
is to cover endorsed scenarios, while endorsed mechanism has been 
removed in JDK 9.

-Felix
>
> -Chris.
>
>
> On 27/05/17 02:15, Felix Yang wrote:
>> Hi Roger,
>>
>>     thanks for the comments. Please see the new webrev
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>
>> -Felix
>> On 2017/5/27 3:50, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> fyi, there is a new version of webrev.ksh that provides convenient
>>> next and previous links.
>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh 
>>>
>>>
>>>
>>>
>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>>> make sense.
>>>
>>> Ditto: closetest/GetResourceAsStream.java
>> Removed such check, since the test depends on several system
>> properties("test.src", "user.dir"). It is not expected to run outside
>> jtreg.
>>
>> -Felix
>>>
>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>
>>> Regards, Roger
>>>
>>>
>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>> Hi Roger,
>>>>
>>>>     please review the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>
>>>> Thanks,
>>>> Felix
>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>> Hi Felix,
>>>>>
>>>>> closetest/CloseTest:
>>>>>
>>>>> 32: Please put the @modules directives together (and not repeat)
>>>> Fixed
>>>> -Felix
>>>>>
>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>> to avoid accidents).
>>>> Fixed and also organized imports in other test files
>>>> -Felix
>>>>>
>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>> Fixed
>>>> -Felix
>>>>>
>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>> Fixed and also formatted other history codes. Just format only
>>>> without logic change.
>>>> Not restricted to this test. I only formatted history codes "nearby",
>>>> to avoid hiding real logic changes in the patch.
>>>>
>>>> -Felix
>>>>>
>>>>> sealing/CheckSealed.java:
>>>>>  - Why is @test block removed?
>>>>>     Should be converted to @run main CheckSealed
>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>> and declared @test there.
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>>>
>>>>
>>>>
>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>> removed. That is because corresponding prerequisite was removed even
>>>> in JDK 8.
>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>> compiled and executed by CheckSealedTest.java.
>>>
>>> Roger
>>>
>>>>
>>>> -Felix
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>>
>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>> Hi there,
>>>>>>
>>>>>>    please review following patch to convert all shell cases under
>>>>>> java/net to plain java codes.
>>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>
>>>>>> Bug:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Felix
>>>>>>
>>>>>
>>>>
>>>
>>


From chris.hegarty at oracle.com  Tue May 30 09:44:05 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 May 2017 10:44:05 +0100
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <f4ad23ff-530e-1f69-3de4-881b8bb8eb0a@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 <ca7d2e13-eeba-73dc-76b2-f6d4dc445cc7@oracle.com>
 <f4ad23ff-530e-1f69-3de4-881b8bb8eb0a@oracle.com>
Message-ID: <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>

On 29/05/17 16:17, Felix Yang wrote:
> Hi Chris,
>
>     please review the updated webrev below. Comments inline.
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/

Thanks Felix.

> ..
>> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>>
>>    Please add a copyright/header.
>>
> Checked existing test policy files, all of them have no
> copyright/header. So I hesitated to add here. Please confirm.

The code is not consistent, but please do add the copyright
header here ( we'll fix the other files at a later time ).

>> ...
>> 4) Why has the test for 5077773 simply been removed?
> As priorly commented, the test is probably not necessary.
> Because it actually quits immediately after prerequisite checking for
> "javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it
> is to cover endorsed scenarios, while endorsed mechanism has been
> removed in JDK 9.

Ok, sorry for not seeing the previous reply.

I am finished reviewing this. No need for an updated webrev, for
the license header.

-Chris.

> -Felix
>>
>> -Chris.
>>
>>
>> On 27/05/17 02:15, Felix Yang wrote:
>>> Hi Roger,
>>>
>>>     thanks for the comments. Please see the new webrev
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>>
>>> -Felix
>>> On 2017/5/27 3:50, Roger Riggs wrote:
>>>> Hi Felix,
>>>>
>>>> fyi, there is a new version of webrev.ksh that provides convenient
>>>> next and previous links.
>>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>>>>
>>>>
>>>>
>>>>
>>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>>>> make sense.
>>>>
>>>> Ditto: closetest/GetResourceAsStream.java
>>> Removed such check, since the test depends on several system
>>> properties("test.src", "user.dir"). It is not expected to run outside
>>> jtreg.
>>>
>>> -Felix
>>>>
>>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>>> Hi Roger,
>>>>>
>>>>>     please review the updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Felix
>>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>>> Hi Felix,
>>>>>>
>>>>>> closetest/CloseTest:
>>>>>>
>>>>>> 32: Please put the @modules directives together (and not repeat)
>>>>> Fixed
>>>>> -Felix
>>>>>>
>>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>>> to avoid accidents).
>>>>> Fixed and also organized imports in other test files
>>>>> -Felix
>>>>>>
>>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>>> Fixed
>>>>> -Felix
>>>>>>
>>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>>> Fixed and also formatted other history codes. Just format only
>>>>> without logic change.
>>>>> Not restricted to this test. I only formatted history codes "nearby",
>>>>> to avoid hiding real logic changes in the patch.
>>>>>
>>>>> -Felix
>>>>>>
>>>>>> sealing/CheckSealed.java:
>>>>>>  - Why is @test block removed?
>>>>>>     Should be converted to @run main CheckSealed
>>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>>> and declared @test there.
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html
>>>>>
>>>>>
>>>>>
>>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>>> removed. That is because corresponding prerequisite was removed even
>>>>> in JDK 8.
>>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>>> compiled and executed by CheckSealedTest.java.
>>>>
>>>> Roger
>>>>
>>>>>
>>>>> -Felix
>>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>>    please review following patch to convert all shell cases under
>>>>>>> java/net to plain java codes.
>>>>>>>
>>>>>>> Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Felix
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From felix.yang at oracle.com  Tue May 30 14:58:55 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 30 May 2017 22:58:55 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 <ca7d2e13-eeba-73dc-76b2-f6d4dc445cc7@oracle.com>
 <f4ad23ff-530e-1f69-3de4-881b8bb8eb0a@oracle.com>
 <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>
Message-ID: <eb26b525-0a83-54c1-b39d-475809b7150e@oracle.com>

Hi Chris,

    pushed, thank you very much!

-Felix
On 2017/5/30 17:44, Chris Hegarty wrote:
> On 29/05/17 16:17, Felix Yang wrote:
>> Hi Chris,
>>
>>     please review the updated webrev below. Comments inline.
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/
>
> Thanks Felix.
>
>> ..
>>> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>>>
>>>    Please add a copyright/header.
>>>
>> Checked existing test policy files, all of them have no
>> copyright/header. So I hesitated to add here. Please confirm.
>
> The code is not consistent, but please do add the copyright
> header here ( we'll fix the other files at a later time ).
Added.
>
>>> ...
>>> 4) Why has the test for 5077773 simply been removed?
>> As priorly commented, the test is probably not necessary.
>> Because it actually quits immediately after prerequisite checking for
>> "javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it
>> is to cover endorsed scenarios, while endorsed mechanism has been
>> removed in JDK 9.
>
> Ok, sorry for not seeing the previous reply.
>
> I am finished reviewing this. No need for an updated webrev, for
> the license header.
>
> -Chris.
>
>> -Felix
>>>
>>> -Chris.
>>>
>>>
>>> On 27/05/17 02:15, Felix Yang wrote:
>>>> Hi Roger,
>>>>
>>>>     thanks for the comments. Please see the new webrev
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>>>
>>>> -Felix
>>>> On 2017/5/27 3:50, Roger Riggs wrote:
>>>>> Hi Felix,
>>>>>
>>>>> fyi, there is a new version of webrev.ksh that provides convenient
>>>>> next and previous links.
>>>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does 
>>>>> not
>>>>> make sense.
>>>>>
>>>>> Ditto: closetest/GetResourceAsStream.java
>>>> Removed such check, since the test depends on several system
>>>> properties("test.src", "user.dir"). It is not expected to run outside
>>>> jtreg.
>>>>
>>>> -Felix
>>>>>
>>>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>>     please review the updated webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Felix
>>>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>>>> Hi Felix,
>>>>>>>
>>>>>>> closetest/CloseTest:
>>>>>>>
>>>>>>> 32: Please put the @modules directives together (and not repeat)
>>>>>> Fixed
>>>>>> -Felix
>>>>>>>
>>>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>>>> to avoid accidents).
>>>>>> Fixed and also organized imports in other test files
>>>>>> -Felix
>>>>>>>
>>>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>>>> Fixed
>>>>>> -Felix
>>>>>>>
>>>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>>>> Fixed and also formatted other history codes. Just format only
>>>>>> without logic change.
>>>>>> Not restricted to this test. I only formatted history codes 
>>>>>> "nearby",
>>>>>> to avoid hiding real logic changes in the patch.
>>>>>>
>>>>>> -Felix
>>>>>>>
>>>>>>> sealing/CheckSealed.java:
>>>>>>>  - Why is @test block removed?
>>>>>>>     Should be converted to @run main CheckSealed
>>>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>>>> and declared @test there.
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>>>> removed. That is because corresponding prerequisite was removed even
>>>>>> in JDK 8.
>>>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>>>> compiled and executed by CheckSealedTest.java.
>>>>>
>>>>> Roger
>>>>>
>>>>>>
>>>>>> -Felix
>>>>>>>
>>>>>>> Regards, Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>>    please review following patch to convert all shell cases under
>>>>>>>> java/net to plain java codes.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Felix
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From pavel.rappo at oracle.com  Wed May 31 10:30:23 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 31 May 2017 11:30:23 +0100
Subject: RFR [9] 8180155: WebSocket secure connection get stuck after onOpen
Message-ID: <ED3A7BDC-9528-4B89-A966-344A937A1A2E@oracle.com>

Hello,

Please review the following change:

 http://cr.openjdk.java.net/~prappo/8180155/webrev.00/

This change addresses 2 separate issues:

    https://bugs.openjdk.java.net/browse/JDK-8180155
    https://bugs.openjdk.java.net/browse/JDK-8156518

The first one is a busy-wait for data on the socket which manifests itself as
non-returning invocation of WebSocket.request(long).

The second one is an issue with a timeout for an asynchronous HTTP request.
This issue affects both HttpClient and WebSocket implementations.

Thanks,
-Pavel


From daniel.fuchs at oracle.com  Wed May 31 11:13:52 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 31 May 2017 12:13:52 +0100
Subject: RFR [9] 8180155: WebSocket secure connection get stuck after
 onOpen
In-Reply-To: <ED3A7BDC-9528-4B89-A966-344A937A1A2E@oracle.com>
References: <ED3A7BDC-9528-4B89-A966-344A937A1A2E@oracle.com>
Message-ID: <4ca16c02-eb0f-d1f4-f110-d4af2e08c67a@oracle.com>

Hi Pavel,

Receiver.java:

  120     private void pushContinuously() {
  121         while (true) {
  122             if (!readable.get()) {
  123                 if (!initialized) {
  124                     initialized = true;
  125                     try {
  126                         channel.registerEvent(event);
  127                     } catch (IOException e) {
  128                         messageConsumer.onError(e);
  129                     }
  130                 }
  131                 break;
  132             } else if (demand.get() > 0 && !handler.isStopped()) {
  133                 pushOnce();
  134             } else {
  135                 break;
  136             }
  137         }
  138     }

I think you might have an issue here, if the initialBuffer
already contains all the data that there is to be read, then
the readable.get() will be false, initialized will be false,
pushOnce() will not be called, and you're going to register
an event that will never be triggered.

best regards,

-- daniel

On 31/05/2017 11:30, Pavel Rappo wrote:
> Hello,
> 
> Please review the following change:
> 
>   http://cr.openjdk.java.net/~prappo/8180155/webrev.00/
> 
> This change addresses 2 separate issues:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8180155
>      https://bugs.openjdk.java.net/browse/JDK-8156518
> 
> The first one is a busy-wait for data on the socket which manifests itself as
> non-returning invocation of WebSocket.request(long).
> 
> The second one is an issue with a timeout for an asynchronous HTTP request.
> This issue affects both HttpClient and WebSocket implementations.
> 
> Thanks,
> -Pavel
>