Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

[Stuart Marks]

Hi Christoph,

I'm still not entirely sure why this is so, but the introduction of a local 
variable in MethodHandles.java seems to make things work for Eclipse. Addition 
of a local variable seems to be minimally invasive, so it makes sense to see if 
this technique can be applied to other cases.


(In ConcurrentSkipListMap the issue seems to be solved by addition of wildcards, 
as I had suggested previously, and it cleans up the unchecked cast that was 
there in the first place. So I think that one is ok already.)


In ManagementFactory.java, an unchecked cast and warnings suppression is 
introduced, and in ExchangeImpl.java a helper method was introduced. I've found 
ways to introduce local variables that make Eclipse happy for these cases. 
(Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See 
diffs below.


The type of the local variable in ExchangeImpl.java is a mouthful. Interestingly 
I had to change Function.identity() to the lambda x -> x. I think this is 
because Function.identity() returns a function that doesn't allow its return 
type to vary from its argument, whereas x -> x allows a widening conversion. 
(This might provide a clue as to the differences between javac and Eclipse here, 
but a full understanding eludes me.)


s'marks



diff -r 006dadb903ab 
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Fri May 17 15:46:14 2019 -0700

@@ -1712,9 +1712,7 @@
 Map m = (Map) o;
 try {
 Comparator cmp = comparator;
-@SuppressWarnings("unchecked")
-Iterator> it =
-(Iterator>)m.entrySet().iterator();
+Iterator> it = m.entrySet().iterator();
 if (m instanceof SortedMap &&
 ((SortedMap)m).comparator() == cmp) {
 Node b, n;
diff -r 006dadb903ab 
src/java.management/share/classes/java/lang/management/ManagementFactory.java
--- 
a/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Fri May 17 15:46:14 2019 -0700

@@ -872,12 +872,12 @@
 public static Set>
getPlatformManagementInterfaces()
 {
-return platformComponents()
+Stream> pmos = 
platformComponents()
 .stream()
 .flatMap(pc -> pc.mbeanInterfaces().stream())
 .filter(clazz -> 
PlatformManagedObject.class.isAssignableFrom(clazz))

-.map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
-.collect(Collectors.toSet());
+.map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
+ return pmos.collect(Collectors.toSet());
 }

 private static final String NOTIF_EMITTER =
diff -r 006dadb903ab 
src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
--- a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Mon May 13 17:15:56 2019 -0700
+++ b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Fri May 17 15:46:14 2019 -0700

@@ -92,8 +92,9 @@
 CompletableFuture c2f = 
c2.getConnectionFor(request, exchange);

 if (debug.on())
 debug.log("get: Trying to get HTTP/2 connection");
-return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection))

-.thenCompose(Function.identity());
+CompletableFuture>> 
fxi =
+c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection));

+return fxi.thenCompose(x -> x);
 }
 }

Re: [ipv6]: 8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment

[Daniel Fuchs]

On 17/05/19 18:02, Arthur Eubanks wrote:


Oh yes, http://cr.openjdk.java.net/~aeubanks/8224014/webrev.02/
Made sure that the "caught expected exception" lines were printed out 
under IPv6-only environment.


Yes, looks good!

best regards,

-- daniel

Re: [ipv6]: 8224019: test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes IPv4 is always available

[Alan Bateman]

On 17/05/2019 18:22, Arthur Eubanks wrote:


Done, order is protocol family, group/notGroup InetAddress, 
NetworkInterface, source InetAddress

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

Thanks, this version looks okay to me.

-Alan

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

[Chris Hegarty]

Arthur,

> On 17 May 2019, at 17:50, Arthur Eubanks  wrote:
> 
> Looks good.
> 
> Trivially, maybe amend the comment to be more explicit
> 
>86   // SOCKS V4 ( requires IPv4 )
> 
> -Chris.
> Done
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ 
> 
> 
> I will wait for another review from security-dev.

You have my Review ( conditional on a Reviewer for the test in the security 
area ).

-Chris.

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

[Ao Qi]

Hi,

Aleksey has helped to push:
http://hg.openjdk.java.net/jdk/jdk/rev/3205f4c40716. Thank you all!

Cheers,
Ao Qi

On Fri, May 17, 2019 at 8:19 AM David Holmes  wrote:
>
> On 17/05/2019 9:14 am, Martin Buchholz wrote:
> > On Thu, May 16, 2019 at 4:05 PM David Holmes  > > wrote:
> >
> > On 17/05/2019 8:57 am, Martin Buchholz wrote:
> >  > Maybe you just need to ask gcc to use a more modern -std=...
> >  > It might reasonably be defaulting to gnu89
> >  >
> > 
> > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu
> >
> > Yes, but I thought we'd already done this dance. Solaris was setting a
> > flag to use C89 IIRC and we removed it.
> >
> >
> > A flag to use C89 is obviously bad if you're using features from a later
> > standard.
> > I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I
> > would go whole hog to C11)
>
> Again I thought we had done this dance. We set -std=gnu++98 but that
> only affects .cpp files. We need a similar thing for .c files. I know
> this has been discussed so I'll see if I can dig up the history and find
> out why we didn't do it. I'll file a build bug if needed.
>
> Cheers,
> David
>
>
> >   $ gcc -v --help |& grep std=.*' C '
> >-std=c11Conform to the ISO 2011 C standard
> >-std=c89Conform to the ISO 1990 C standard
> >-std=c90Conform to the ISO 1990 C standard
> >-std=c99Conform to the ISO 1999 C standard
> >-std=gnu11  Conform to the ISO 2011 C standard with GNU
> >-std=gnu89  Conform to the ISO 1990 C standard with GNU
> >-std=gnu90  Conform to the ISO 1990 C standard with GNU
> >-std=gnu99  Conform to the ISO 1999 C standard with GNU
> >-std=iso9899:1990   Conform to the ISO 1990 C standard
> >-std=iso9899:199409 Conform to the ISO 1990 C standard as
> > amended in
> >-std=iso9899:1999   Conform to the ISO 1999 C standard
> >-std=iso9899:2011   Conform to the ISO 2011 C standard

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

[Chris Hegarty]

Arthur,

On 17/05/2019 06:57, Arthur Eubanks wrote:



On Thu, May 16, 2019 at 7:44 PM Vyom Tiwari > wrote:


Hi Arthur,
do we need "Integer.toString(4)" to convert int to string in
SocksProxyVersion ?
Thanks,
Vyom

Fixed.
http://cr.openjdk.java.net/~aeubanks/8224081/webrev.01/index.html


Looks good.

Trivially, maybe amend the comment to be more explicit

  86   // SOCKS V4 ( requires IPv4 )

-Chris.

Re: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should choose loopback address that is available

[Daniel Fuchs]

Hi Arthur,

On 17/05/2019 00:18, Arthur Eubanks wrote:
I've tried to run this through the submit repo twice, haven't gotten a 
result from either run. Could somebody check what's happened to those runs?

The branch names are "JDK-8223214" and "JDK-8223214-1".


I'm not seeing anything for JDK-8223214 in the history.
When did you submit those? It looks as they never run,
as I can see jobs from some month ago. Maybe the trigger
didn't work (whatever that is).

Can you submit a again and let me know - and I'll try
to have a look at the jdk-submit CI?

best regards,

-- daniel

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

[Vyom Tiwari]

+1

On Fri, May 17, 2019 at 3:29 PM Daniel Fuchs 
wrote:

> Hi Arthur,
>
> On 17/05/2019 00:16, Arthur Eubanks wrote:
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224081
> > webrev:
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html
> >
> > Tests that try to use SOCKS v4 will fail in an IPv6 only environment
> > since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.
>
> Your changes to java/net/Socks/SocksProxyVersion.java look good to me.
>
> However I'd like your changes to
> test/jdk/sun/security/x509/URICertStore/SocksProxy.java
> to be reviewed by the security-dev team which I have added
> in cc:, since I believe this falls into their area.
>
> best regards,
>
> -- daniel
>
>

-- 
Thanks,
Vyom

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

[Daniel Fuchs]

Hi Arthur,

On 17/05/2019 00:16, Arthur Eubanks wrote:

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

Tests that try to use SOCKS v4 will fail in an IPv6 only environment 
since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.


Your changes to java/net/Socks/SocksProxyVersion.java look good to me.

However I'd like your changes to
test/jdk/sun/security/x509/URICertStore/SocksProxy.java
to be reviewed by the security-dev team which I have added
in cc:, since I believe this falls into their area.

best regards,

-- daniel

Re: [ipv6]: 8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment

[Daniel Fuchs]

Hi Arthur,

On 16/05/2019 18:01, Arthur Eubanks wrote:

Good idea, done. PTAL. Tested with and without IPv4 support.
http://cr.openjdk.java.net/~aeubanks/8224014/webrev.01/index.html


Shouldn't you remove:

  38 IPSupport.throwSkippedExceptionIfNonOperational();

In this case?

best regards,

-- daniel

Re: [ipv6]: 8224019: test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes IPv4 is always available

[Alan Bateman]

On 16/05/2019 23:38, Arthur Eubanks wrote:

I've added testing exceptions to IPv6 as well, PTAL.
This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4 
and IPv6 code paths. Else DatagramChannel.join() fails since you can't 
mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost() can only 
be one of those.


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


Adding back nio-dev as it seems to have been dropped from thread again.

On webrev.01, I think the approach looks okay but would you have 
re-ordering the parameters to both membershipKeyTests and exceptionTests 
so that the protocol family is first, then the groups, then the 
NetworkInterface as that will align with the usages and the join methods 
where the order is always group, networkInterface (and optionally source).


-Alan