RFR 8220480: Typo in java.net.http.HttpResponse.BodySubscriber documentation

[Chris Hegarty]

Minor typo in the link target, should be BodySubscribers ( plural ).

--- a/src/java.net.http/share/classes/java/net/http/HttpResponse.java
+++ b/src/java.net.http/share/classes/java/net/http/HttpResponse.java
@@ -1,7 +1,7 @@
 /*
- * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.  Oracle designates this
@@ -826,11 +826,11 @@
 }
 
 /**
  * A {@code BodySubscriber} consumes response body bytes and converts them
  * into a higher-level Java type.  The class {@link BodySubscribers
- * BodySubscriber} provides implementations of many common body 
subscribers.
+ * BodySubscribers} provides implementations of many common body 
subscribers.
  *
  *  The object acts as a {@link Flow.Subscriber}<{@link 
List}<{@link
  * ByteBuffer}>> to the HTTP Client implementation, which publishes
  * lists of ByteBuffers containing the response body. The Flow of data, as
  * well as the order of ByteBuffers in the Flow lists, is a strictly 
ordered


-Chris.

Re: RFR 8220480: Typo in java.net.http.HttpResponse.BodySubscriber documentation

[Alan Bateman]

On 12/03/2019 09:05, Chris Hegarty wrote:

Minor typo in the link target, should be BodySubscribers ( plural ).


Looks okay.

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Daniel Fuchs]

Hi Arthur,

This looks good to me. I have launched the changes in your second
webrev through our test system and not observed any regression.
I don't know if Chris still has some tests running, but from
my standpoint you're good to go!

best regards,

-- daniel

On 11/03/2019 18:14, Arthur Eubanks wrote:
Updated copyright years (I asked around, it should be fine), updated 
commit message.

http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01

On Mon, Mar 11, 2019 at 10:46 AM Martin Buchholz > wrote:


These changes are clean progress and allow tests to pass on any of
the 4 (!) combinations of IPV4/IPV6 support available.  LGTM.

BUT ... in the current multi-protocol world it's probably better to
test against all the interfaces available on the host machine.
Maybe there should be a InetAddress.getLoopbackAddresses (note the
plural!) and tests should run against all the InetAddress objects
returned by such an API?
But this is a big task (mostly spec work I would guess) for the
net-dev team.

On Mon, Mar 11, 2019 at 9:55 AM Arthur Eubanks mailto:aeuba...@google.com>> wrote:

bug: https://bugs.openjdk.java.net/browse/JDK-8220083
webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/

First of a few ipv6 patches to come.

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Chris Hegarty]

Hi Arthur,

> On 11 Mar 2019, at 18:14, Arthur Eubanks  > wrote:
> 
> Updated copyright years (I asked around, it should be fine), updated commit 
> message.
> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01 
> 
This is a welcome improvement to the tests. Reviewed, with some minor
comments and additions below.

It will not be easy to get all the JDK networking tests passing
successfully on IPv6-only environments ( ignoring the other combinations
for now ). But this is a good improvement, and hopefully the start of
a number of changes that add similar incremental improvements. To this
end, I've created an umbrella task, 8220499, to track these test changes
( in one place ), and updated this issue, 8220083, to be a sub-task of
it. Let's add more sub-tasks as needed.

Specific webrev comment:
 * Can you please split the long line in TunnelThroughProxy.java

Suggestion for similar changes while here:
 * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html 


-Chris.

8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl

[Alan Bateman]

We have a branch in the sandbox named "niosocketimpl-branch" with a 
replacement for the underlying implementation used by java.net.Socket 
and ServerSocket. I've mentioned this in previous mails [1]. We also 
have a draft JEP [2].


I'd like to get the changes that allow for the platform SocketImpl to be 
replaced into jdk/jdk in advance of the JEP. The reasoning is to reduce 
the size of the overall patch, make the changes easier to review, and 
get some of the narly behavior changes out of the way before the main event.


To that end, I've created JDK-8220493 [3] to bring the "preparatory 
changes" into jdk/jdk. A summary of the changes is:


- ServerSocket is changed to use a platform SocketImpl by default, it 
used to use the SOCKS SocketImpl.


- Socket use a SOCKS SocketImpl by default. The SOCKS SocketImpl now 
delegates to a platform SocketImpl rather than extending it. The HTTP 
SocketImpl is also changed to delegate to a platform SocketImpl.


- ServerSocket.accept has been overhauled to disallow nonsensical 
combinations of SocketImpl. For example, it is nuts to create a 
ServerSocket using a custom SocketImpl and have it try to accept a 
connection with a platform SocketImpl. There is a big matrix of possible 
scenarios that are tested with a new combinations test. Chris, Michael 
and I spent time on a white board going through all the possible 
scenarios to make sure that all sane scenarios work as before, only the 
nonsensical comminations are disallowed.


- Socket has been changed to wrap the input/output streams returned by 
the underlying SocketImpl so that closing of these streams will close 
the socket. This is important to allow for socket implementations 
outside of the java.net package but it requires changes to JFR as it 
instruments these changes.


I've created a CSR [4] to document the subtle behavior changes.

The webrev with the corresponding changes is here:
  http://cr.openjdk.java.net/~alanb/8220493/0/webrev/

-Alan

[1] 
https://mail.openjdk.java.net/pipermail/net-dev/2019-January/012135.html

[2] http://openjdk.java.net/jeps/8218559
[3] https://bugs.openjdk.java.net/browse/JDK-8220493
[4] https://bugs.openjdk.java.net/browse/JDK-8220494

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Arthur Eubanks]

Thanks for creating the umbrella bug.

Split long line.
Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
suggestions. The other 2 involve URI/URLs, and there are a lot of those
changes, will group them in a later change.

PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/


On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty 
wrote:

> Hi Arthur,
>
>
> On 11 Mar 2019, at 18:14, Arthur Eubanks  wrote:
>
> Updated copyright years (I asked around, it should be fine), updated
> commit message.
> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
>
>
> This is a welcome improvement to the tests. Reviewed, with some minor
> comments and additions below.
>
> It will not be easy to get all the JDK networking tests passing
> successfully on IPv6-only environments ( ignoring the other combinations
> for now ). But this is a good improvement, and hopefully the start of
> a number of changes that add similar incremental improvements. To this
> end, I've created an umbrella task, 8220499, to track these test changes
> ( in one place ), and updated this issue, 8220083, to be a sub-task of
> it. Let's add more sub-tasks as needed.
>
> Specific webrev comment:
>  * Can you please split the long line in TunnelThroughProxy.java
>
> Suggestion for similar changes while here:
>  * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html
>
> -Chris.
>

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Chris Hegarty]

Arthur,

> On 12 Mar 2019, at 16:59, Arthur Eubanks  wrote:
> 
> Thanks for creating the umbrella bug.
> 
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's 
> suggestions.

Thanks.

> The other 2 involve URI/URLs, and there are a lot of those changes, will 
> group them in a later change.

That is true, and it is absolutely fine to leave them until a follow on.

The reason I suggested the change is because almost all of the other
HTTP Client tests run successfully on an IPv6-only environment. The
reason is that the URL-string when converted to a URI has the square
brackets added by URI.create. Anyway, not critical for now.

> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/ 
> 
Looks good.

You are probably all set, but if you need a sponsor just ask.

-Chris.

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Arthur Eubanks]

Thanks!

Just curious, what tests did you run and under what environment?

On Tue, Mar 12, 2019 at 10:34 AM Chris Hegarty 
wrote:

> Arthur,
>
> On 12 Mar 2019, at 16:59, Arthur Eubanks  wrote:
>
> Thanks for creating the umbrella bug.
>
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
> suggestions.
>
>
> Thanks.
>
> The other 2 involve URI/URLs, and there are a lot of those changes, will
> group them in a later change.
>
>
> That is true, and it is absolutely fine to leave them until a follow on.
>
> The reason I suggested the change is because almost all of the other
> HTTP Client tests run successfully on an IPv6-only environment. The
> reason is that the URL-string when converted to a URI has the square
> brackets added by URI.create. Anyway, not critical for now.
>
> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/
>
>
> Looks good.
>
> You are probably all set, but if you need a sponsor just ask.
>
> -Chris.
>

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Chris Hegarty]

Arthur,

> On 12 Mar 2019, at 17:54, Arthur Eubanks  wrote:
> 
> Thanks!
> 
> Just curious, what tests did you run and under what environment?

I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit
of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and 
preferIPv6Addresses effectively forced. The /etc/hosts on my system
returns IPv6 addresses for `localhost` and the machine host name. This
env reproduces the same set of failures as you ( I assume from your 
webrev ), and more. It's just enough to get me started and able to
review / help out.

-Chris.

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

[Vyom Tiwari]

Hi Arthur,

Changes looks good to me, one minor comment, in HTTPTestServer.java  we can
avoid  new local variable (InetAddress address) .

Thanks,
Vyom

On Tue, Mar 12, 2019 at 10:30 PM Arthur Eubanks  wrote:

> Thanks for creating the umbrella bug.
>
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
> suggestions. The other 2 involve URI/URLs, and there are a lot of those
> changes, will group them in a later change.
>
> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/
>
>
> On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty 
> wrote:
>
>> Hi Arthur,
>>
>>
>> On 11 Mar 2019, at 18:14, Arthur Eubanks  wrote:
>>
>> Updated copyright years (I asked around, it should be fine), updated
>> commit message.
>> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
>>
>>
>> This is a welcome improvement to the tests. Reviewed, with some minor
>> comments and additions below.
>>
>> It will not be easy to get all the JDK networking tests passing
>> successfully on IPv6-only environments ( ignoring the other combinations
>> for now ). But this is a good improvement, and hopefully the start of
>> a number of changes that add similar incremental improvements. To this
>> end, I've created an umbrella task, 8220499, to track these test changes
>> ( in one place ), and updated this issue, 8220083, to be a sub-task of
>> it. Let's add more sub-tasks as needed.
>>
>> Specific webrev comment:
>>  * Can you please split the long line in TunnelThroughProxy.java
>>
>> Suggestion for similar changes while here:
>>  * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html
>>
>> -Chris.
>>
>

-- 
Thanks,
Vyom