Hi Alex,
looks good now.
Cheers
Christoph
> -Original Message-
> From: Alex Kashchenko
> Sent: Dienstag, 24. März 2020 19:09
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: net-dev@openjdk.java.net
> Subject: Re: [11u] RFR: 8183369
Hi Alex,
I think this looks good overall.
There's one line in
test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where
you got the indentation wrong. Please check and fix that.
Best regards
Christoph
> -Original Message-
> From: jdk-updates-dev On
> Behalf Of Alex
Hi Vipin,
I'm forwarding this to net-dev where it should be reviewed.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Vipin Mv1
> Sent: Dienstag, 3. März 2020 11:54
> To: core-libs-...@openjdk.java.net
> Subject: RFR 8129841 Update comment for
> Java_jav
Hi Matthias,
this seems fine to me. The change in NetworkInterface.c is correct, too.
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 25. Juli 2019 15:45
> To: Doerr, Martin ; 'hotspot-
> d...@openjdk.java.net' ; cor
Hi Matthias,
looks good to me, too. And +1 for dropping the comment.
Best regards
Christoph
> -Original Message-
> From: net-dev On Behalf Of Chris
> Hegarty
> Sent: Freitag, 16. August 2019 13:44
> To: Baesken, Matthias
> Cc: net-dev@openjdk.java.net
> Subject: Re: RFR [XS] : 8229706:
Hi,
please review the jdk11u backport of another fix for test
java/net/httpclient/UnknownBodyLengthTest.java. The patch did apply mostly
clean but needed some help in the import directives. Now the change looks
effectively the same as the original.
Bug: https://bugs.openjdk.java.net/browse/JDK
Hi,
please review the jdk11u backport of a fix for test
java/net/httpclient/UnknownBodyLengthTest.java. The test is instable in jdk11u,
too, so it should be backported. The patch did apply mostly but the changes to
the @run main/othervm directives needed some manual intervention.
Bug: https://b
Hi Matthias,
looks good, thanks for doing this.
How far are we then from enabling "warnings as errors" on AIX? :P
Best regards
Christoph
From: awt-dev On Behalf Of Baesken, Matthias
Sent: Dienstag, 16. Juli 2019 17:04
To: Java Core Libs ; nio-...@openjdk.java.net;
net-dev@openjdk.jav
Hi Severin,
looks good, ship it 😊
Thanks
Christoph
> -Original Message-
> From: net-dev On Behalf Of Severin
> Gehwolf
> Sent: Freitag, 28. Juni 2019 10:41
> To: jdk8u-dev
> Cc: net-dev
> Subject: [8u] RFR: 8226928: [TESTBUG]
> test/java/net/NetworkInterface/IPv4Only.java fails interm
Hi Rob,
sending this over to net-dev, where it should be discussed...
/Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Rob Spoor
> Sent: Montag, 24. Juni 2019 22:58
> To: core-libs-...@openjdk.java.net
> Subject: [BUG] Inet6Address.isIPv4CompatibleAddress uses wrong
Thanks, Chris. I pushed it then on behalf of Arno.
> -Original Message-
> From: net-dev On Behalf Of Chris
> Hegarty
> Sent: Freitag, 31. Mai 2019 16:06
> To: Zeller, Arno
> Cc: net-dev@openjdk.java.net
> Subject: Re: [RFR] 8194231:
> java/net/DatagramSocket/ReuseAddressTest.java failed
Hi,
Thanks, Arno. This looks good to me, too.
@Chris: We were running with this patch in our nightly test system for a while
now and we don't see regressions. But looking forward to hear from your results.
Best regards
Christoph
> -Original Message-
> From: net-dev On Behalf Of Zeller
> Overall, introducing a local variable is more-or-less reasonable even if it's
> used only once. One point is that somebody might come along and "clean
> up" the
> code and inline local variables and reintroduce the problem. Another point is
> that, hypothetically, if in the future Eclipse is chan
tted and I should at the same time
submit another bug to evaluate these code places at a time when the final
resolution for JDK-8016207 was provided?
Thank you
Christoph
> -Original Message-
> From: Stuart Marks
> Sent: Samstag, 18. Mai 2019 00:56
> To: Langer, Christoph
&
this code again from a compiler/spec perspective and make
the according modifications?
Thanks
Christoph
> -Original Message-
> From: David Holmes
> Sent: Mittwoch, 15. Mai 2019 00:05
> To: Langer, Christoph ; Daniel Fuchs
> ; core-libs-dev d...@openjdk.java.net&
Christoph
> -Original Message-
> From: Daniel Fuchs
> Sent: Dienstag, 14. Mai 2019 18:04
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile wi
Hi Daniel,
> > unfortunately, your proposed solution does not work with javac. I get this
> in the build:
>
> Oh darn. I should have double checked.
> Can we at least reduce the scope of the @SuppressedWarnings by
> introducing a private method that just has the return call?
Sure, what about thi
ableFuture
1 error
So I think we need to go back to my initial proposal which works for both, IDE
and javac: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
Thanks
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Freitag, 10. Mai 2019 11:17
> To: Daniel
> -Original Message-
> From: Daniel Fuchs
> Sent: Donnerstag, 9. Mai 2019 17:24
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; net-dev
> Cc: compiler-...@openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
&g
Hi,
please review a small change that I'd like to see in OpenJDK to get rid of
compilation errors in the Eclipse IDE.
It seems the root cause for the compilation errors is that javac would
sometimes widen capture variables and is hence able to compile the places that
I touch here. The EC4J com
Hi Thomas,
looks good 😊
Christoph
From: net-dev On Behalf Of Thomas Stüfe
Sent: Montag, 25. März 2019 14:15
To: net-dev
Subject: RFR(xxxs): 8221406: Windows 32bit build error in
NetworkInterface_winXP.c
Hi all,
please review this tiny fix to a windows 32 build warning:
Issue: https://bugs
Hi Ivan,
looks good to me.
Best regards
Christoph
> -Original Message-
> From: net-dev On Behalf Of Ivan
> Gerasimov
> Sent: Mittwoch, 20. März 2019 17:18
> To: net-dev
> Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
>
> Hello!
>
> The function Java_java_n
Looks good, +1
/Christoph
From: net-dev On Behalf Of Chris Hegarty
Sent: Donnerstag, 14. März 2019 17:47
To: net-dev
Subject: RFR 8179549: Typo in network properties documentation
Trivial typo fix.
diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html
b/src/java.bas
Hi Amy,
seems reasonable to me. +1
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Amy Lu
> Sent: Mittwoch, 27. Februar 2019 02:41
> To: OpenJDK Dev list ; Core-Libs-Dev libs-...@openjdk.java.net>
> Subject: [JDK 13] RFR 8219802: Problem list
> java/net
Hi Sean,
thanks for looking at this. I agree. Will remove othervm...
Best regards
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Donnerstag, 24. Januar 2019 17:43
> To: Langer, Christoph ; OpenJDK Dev list
> ; OpenJDK Network Dev list d...@openjdk.java.net
Hi Goetz,
thanks for the review.
I've added the comment as you suggested:
http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/
Will run it through our nightly tests before submitting...
/Christoph
From: Lindenmaier, Goetz
Sent: Donnerstag, 24. Januar 2019 08:48
To: Langer, Chri
Hi,
please review a small test update.
Bug: https://bugs.openjdk.java.net/browse/JDK-8217657
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/
I'd like to move the test for the correct default value of security property
"jdk.includeInExceptions" into an own testcase in the jdk.secu
Hi Alan,
the change looks good to me.
In src/java.base/unix/native/libnio/ch/Net.c and
src/java.base/windows/native/libnio/ch/Net.c you could change the code from
...
int n = NET_SocketAvailable(fdval(env, fdo), &count);
if (n != 0) {
...
to one line
if (NET_SocketAvailable(fdval(env, fdo), &c
Thanks, Steve and Chris for reviewing. Pushed to jdk12.
> -Original Message-
> From: Chris Hegarty
> Sent: Freitag, 18. Januar 2019 15:15
> To: Langer, Christoph ; Steve Groeger
>
> Cc: net-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
> Subj
rstag, 17. Januar 2019 12:27
To: Langer, Christoph
Cc: net-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX
On 17 Jan 2019, at 10:55, Langer, Christoph
mailto:christoph.lan...@sap.com>> wrote:
Hi,
here is a
Test.java). Could you check this also with the
AIX team whether they consider this a bug or working as expected?
Thanks & Best regards
Christoph
From: Steve Groeger
Sent: Donnerstag, 17. Januar 2019 14:32
To: Langer, Christoph
Cc: Chris Hegarty ; net-dev@openjdk.java.net; net-dev
; ppc-aix-
issues on other platforms. I'll send an
updated webrev tomorrow.
Best regards
Christoph
From: Chris Hegarty
Sent: Donnerstag, 17. Januar 2019 12:27
To: Langer, Christoph
Cc: net-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: 8207404: MulticastSocket tests failing on AI
England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From: "Langer, Christoph"
<mailto:christoph.lan...@sap.com>
To:"net-dev@openjdk.java.net"<mailto:net-dev@openjdk.java.net>
<mailto:net
Hi,
here is a fix for the MulticastSocket tests failing on AIX (in certain
sceanrios):
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8207404
First of all, I "modernized" the testcases
test/jdk/java/net/MulticastSocket/SetGetNetwork
Hi,
please help to review a tiny fix.
While working on the issue with the AIX multicast tests
(https://bugs.openjdk.java.net/browse/JDK-8207404), I found a place where a
SocketException thrown in a specific error case could be improved. There
already exists code to throw a SocketException with
Hi Ivan,
yes, sure, push it 😊
Best regards
Christoph
> -Original Message-
> From: Ivan Gerasimov
> Sent: Dienstag, 15. Januar 2019 20:53
> To: Baesken, Matthias ; net-
> d...@openjdk.java.net; Langer, Christoph
> Subject: Re: RFR 8007606 : Handle realloc() failur
Hi Steve,
I have looked into this topic. I started some work in that area a few years ago
and never finished it. I think the root cause of the issue got already pointed
out in this discussion.
The JVM (correctly) detects that the system is capable of IPv6 and hence opens
new sockets with addre
Hi,
that's right, good catch. Either set localifs to 0 or maybe even keep the old
pointer with the old value of localifs. I guess the case is a bit theoretical
but it should be done right.
In line 695 fclose (f); the formatting can be fixed (also remove space
between fclose and the bracket
Hi Ivan,
looks good.
Best regards
Christoph
> -Original Message-
> From: net-dev On Behalf Of Ivan
> Gerasimov
> Sent: Freitag, 11. Januar 2019 05:29
> To: net-dev@openjdk.java.net
> Subject: RFR 8007606 : Handle realloc() failure in
> unix/native/libnet/net_util_md.c correctly
>
> Hel
Hi Matthias,
looks good to me.
In src/java.base/unix/native/libnet/NetworkInterface.c, lines 1019 and 1034,
I'd prefer if the style was:
if (addr == NULL) {
return 0;
}
Thanks
Christoph
From: net-dev On Behalf Of Baesken, Matthias
Sent: Mittwoch, 9. Januar 2019 10:02
To: net-dev
Cc: Rob
Hi Matthias,
looks good (and trivial). Ccing serviceability-dev because of change in libjdwp.
Best regards
Christoph
From: nio-dev On Behalf Of Baesken, Matthias
Sent: Mittwoch, 26. September 2018 11:25
To: 'build-...@openjdk.java.net' ; net-dev
; nio-...@openjdk.java.net
Cc: Lindenmaier, Goet
018 11:02
> To: Langer, Christoph
> Cc: OpenJDK Network Dev list
> Subject: Re: RFR of JDK-8210802,temp files left by tests in
> jdk/java/net/httpclient
>
> Hi Christoph,
>
> Thank you for review.
>
> Normally I prefer to use "finally" too.
>
> Bu
Hi Hamlin,
wouldn't it be better/cleaner to move the deletion of files into finally
blocks? But I guess one can do it with deleteOnExit() as well...
Best regards
Christoph
> -Original Message-
> From: net-dev On Behalf Of Hamlin Li
> Sent: Montag, 17. September 2018 07:55
> To: OpenJDK
Hi Matthias,
> Can I have a second review please ?
+1
Best regards
Christoph
Hi Matthias,
forwarding to serviceability-dev, because debugging is usually discussed there.
Yes, I would think this coding should be fixed, too. Can you open a bug and
prepare a change?
Thanks
Christoph
> -Original Message-
> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On
Hi,
As I had written previously, I’m still unclear whether the naming of the MacOS
implementation files is the best choice.
Currently it is:
src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java
src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c
Maybe it should rather be:
src/jdk.net/
:chris.hega...@oracle.com]
> Sent: Montag, 30. April 2018 11:45
> To: Langer, Christoph ; Thomas Stüfe
>
> Cc: net-dev@openjdk.java.net
> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in
> Unix Inet*AddressImpl_getLocalHostName implementations
>
>
>
27. April 2018 18:15
> To: Langer, Christoph
> Cc: vyom tewari ; net-dev@openjdk.java.net;
> Brian Burkhalter
> Subject: Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in
> Unix Inet*AddressImpl_getLocalHostName implementations
>
> Hi Christoph,
>
>
tions/getnameinfo.html
> -Original Message-
> From: vyom tewari [mailto:vyom.tew...@oracle.com]
> Sent: Freitag, 27. April 2018 08:38
> To: Thomas Stüfe
> Cc: Langer, Christoph ; net-
> d...@openjdk.java.net
> Subject: Re: RFR(XS): 8202181: Correctly specify size of host
Ping, can some reviewer please have a look at this small fix?
Thanks
Christoph
From: Langer, Christoph
Sent: Dienstag, 24. April 2018 11:39
To: net-dev@openjdk.java.net
Subject: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix
Inet*AddressImpl_getLocalHostName implementations
Ok, let's get some more opinions on that... 😊
> -Original Message-
> From: vyom tewari [mailto:vyom.tew...@oracle.com]
> Sent: Donnerstag, 26. April 2018 12:31
> To: Langer, Christoph ; Chris Hegarty
> ; OpenJDK Network Dev list d...@openjdk.java.net>
> Su
Hi Vyom,
what about my suggestions for renaming?
src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java ->
src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java
src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c ->
src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c
This wo
Hi Vyom,
> I think, it is intentional to handle case where return "hostname" is to large
> to
> fit in array. if you see the man page(http://man7.org/linux/man-
> pages/man2/gethostname.2.html) it says that it is unspecified whether
> returned buffer includes a terminating null byte.
>
> curre
Hi,
please help reviewing a small change that I stumbled over when looking into the
getLocalHostName implementation. I found that the length of the hostname buffer
is not correctly passed to sub functions. The buffer size is specified as
"NI_MAXHOST + 1", so this size should be handed down to g
Hi Ivan,
looks good. I agree that the fields that Vyom mentioned should be final.
Best regards
Christoph
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of vyom tewari
Sent: Dienstag, 24. April 2018 08:29
To: net-dev@openjdk.java.net
Subject: Re: RFR 8202154 : Remove unused cod
Hi,
I created a JDK 8 backport proposal for JDK-8201369:
http://cr.openjdk.java.net/~clanger/webrevs/8201369-jdk8.0/
This is the Bug: https://bugs.openjdk.java.net/browse/JDK-8201369
The issue was recently discussed and reviewed here:
http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011
Hi Ivan,
this looks good to me. Next nice step in cleaning up the socket implementation.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
> Ivan Gerasimov
> Sent: Freitag, 20. April 2018 22:40
> To: net-dev@openjdk.java.ne
Thank you. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/a838e3707f3a
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Mittwoch, 18. April 2018 16:20
> To: Langer, Christoph
> Cc: Srividya Shamaiah ; OpenJDK Network Dev list
>
>
Hi Chris,
our testing didn’t show regressions. Are we good to push?
Best regards
Christoph
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: Montag, 16. April 2018 16:39
To: Langer, Christoph
Cc: Srividya Shamaiah ; OpenJDK Network Dev list
Subject: Re: RFR(XS): 8201369
Hi Vyom,
I had a quick glance through your changes.
Apart from the suggestions you've already got (use snprintf instead of string
concatenation, method ordering...), I think
"src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java" and "
src/jdk.net/macosx/native/libextnet/UnixSocketOptions.
so do some
testing.
I'll also take care of the backport after the push to jdk11.
Best regards
Christoph
From: Srividya Shamaiah [mailto:ssham...@in.ibm.com]
Sent: Montag, 16. April 2018 10:44
To: Langer, Christoph
Cc: Chris Hegarty ; OpenJDK Network Dev list
Subject: R
Hi,
thanks, I've pushed it then: http://hg.openjdk.java.net/jdk/jdk/rev/bc1c7e41e285
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Freitag, 13. April 2018 16:07
> To: Langer, Christoph ; Joel Peláez
Hi Chris, Joel,
testing went fine and did not show regressions. Same for the Oracle tests?
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Mittwoch, 11. April 2018 18:11
> To: Langer, Christoph ; Joel Peláez Jorge
: Joel Peláez Jorge [mailto:joelpel...@gmail.com]
> Sent: Mittwoch, 11. April 2018 12:54
> To: Langer, Christoph ; net-
> d...@openjdk.java.net
> Subject: Re: JDK-8200719: Cannot connect to IPv6 host when exists any active
> network interface without IPv6 address
>
> Hi Chris
Hi Joel,
your fix sounds reasonable. In fact, I'm not even sure if the sin6_scope_id
should be set for multicast. Maybe it should be done only for link local
addresses.
Additionally, I guess the selection of the default interface (for IPv6) should
be improved because I still can imagine a scen
Hi Srividya,
I would also welcome this fix.
Will you do the fix based on the jdk (11) depot? I think
Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same
as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with
sponsoring/backporting to JDK8, if you
Hi Ivan,
I went through your changes and I really like this work.
Nothing to complain about - especially if there are no regressions with the
additional test coverage.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
>
Hi Alan,
looks good to me, +1.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
> Alan Bateman
> Sent: Mittwoch, 14. März 2018 15:31
> To: OpenJDK Network Dev list
> Subject: 8199329: Remove code that attempts to read byt
Hi Yuji,
looks good.
Best regards
Christoph
> -Original Message-
> From: KUBOTA Yuji [mailto:kubota.y...@gmail.com]
> Sent: Donnerstag, 8. März 2018 03:57
> To: Daniel Fuchs
> Cc: Langer, Christoph ; Yasumasa Suenaga
> ; OpenJDK Network Dev list d...@openjdk.java.
Looks good, Brian.
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Brian
Burkhalter
Sent: Dienstag, 6. März 2018 16:27
To: OpenJDK Network Dev list
Subject: RFR 8198302: VS2017 (C4477)
java.base/windows/native/libnet/NetworkInterface_winXP.c incorrect printf
format strings
Hi Ivan,
I went through the changes a bit and I would think it is really a good cleanup
and will make the future merge of the implementations easier.
One thing I saw was that TwoStacksPlainSocketImpl.c has an #include
in line 25. I think that can be removed!?
I had problems importing the patc
Hi Yuji,
I had a look and to me it seems safe to do like webrev.03 suggests. That is,
remove the throws clause. As Daniel pointed out, it seems that all callers of
the "handle" method would do merely the same. The only thing I'm not sure about
is the CancelledKeyException caught in line 413. In
Hi Pallavi,
this change looks good to me. The only thing left to mention is that you will
need to update the copyright years - I guess you would have done it on submit
anyway.
Best regards
Christoph
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Pallavi
Sonal
Sent: Freit
Cc: Langer, Christoph ; OpenJDK Serviceability
; OpenJDK Build
; OpenJDK Networking
Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996:
'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
One more to fix to cover the remaining test failures I was seeing.
Previou
Hi Gary,
> Here's a revised webrev
>
>http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html
>
> Still testing ...
>
> Using shutdown() fixed problems reported by the
> java/nio/channelSocketChannel tests.
The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysP
But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it?
I still don't see the reason...
-Original Message-
From: gary.ad...@oracle.com [mailto:gary.ad...@oracle.com]
Sent: Donnerstag, 1. Februar 2018 12:17
To: Langer, Christoph ; OpenJDK Serviceability
Hi Gary,
I was having a look at your changes.
I'm wondering what the reason is behind uncommenting WSASendDisconnect in
Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in
dbgsysSocketClose?
In socketTransport.c, line:
331 setLastError(0, "gethostb
Hi Martin,
I think the new code is more compact and readable which makes it nice. I
reviewed it to check that the result is still the same as before. However, I
can’t assess if it is acceptable from a performance point of view and would
defer this assessment to some other reviewer. But apart fr
Hi Roger,
ah, I see. I pushed with removing the comment then:
http://hg.openjdk.java.net/jdk10/master/rev/74e1913a98c0
Thanks
Christoph
From: Roger Riggs [mailto:roger.ri...@oracle.com]
Sent: Mittwoch, 18. Oktober 2017 20:37
To: Langer, Christoph ; net-dev@openjdk.java.net
Subject: Re: RFR(S
CP_QUICKACK socket option
>
> Hi All,
>
> please find the latest
> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.htm
> l).
>
> Thanks,
>
> Vyom
>
>
> On Wednesday 18 October 2017 08:21 PM, Langer, Christoph wrote:
> > Hi Vyom,
>
o:roger.ri...@oracle.com]
Sent: Mittwoch, 18. Oktober 2017 17:28
To: Langer, Christoph ; net-dev@openjdk.java.net
Subject: Re: RFR(S): 8155590: Dubious collection management in
sun.net.www.http.KeepAliveCache
Hi Christoph,
Looks ok.
The comment in remove() about CCE can be removed. ArrayDeque is not threa
Hi Vyom,
I just looked at your latest webrev which in general looks fine to me. Some
minor remarks:
make/lib/Lib-jdk.net.gmk:
- copyright year needs to be updated
src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java:
- private void addExtSocketOptions(...) looks a bit awful concern
s
are synchronized and in the same thread.
I think a CCE could occur during the iteration to find the entry when
Vector.Itr.next() checks.
(It you want to more radical fix, replace the Vector with something more
current.
It would be one less Vector).
Roger
On 10/16/17 2:33 AM, Langer, Christoph
move is get called from synchronize "remove
(HttpClient h, Object obj)" and the underline data structure is which is
java.util.Vector(ClientVector extends java.util.Stack) is also thread safe.
What do you think ?
Thanks,
Vyom
On Monday 16 October 2017 12:52 PM, Langer, Christoph wro
Hi,
Here is a proposal for a fix for bug 8155590. I already made this fix a while
ago in our JDK clone and I'd like to contribute this.
Bug: https://bugs.openjdk.java.net/browse/JDK-8155590
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/
Please review.
Thanks
Christoph
Hi Mark,
I overlooked that, you are completely right, recreateServerSocket is fine then.
Best regards
Christoph
> -Original Message-
> From: Mark Sheppard [mailto:mark.shepp...@oracle.com]
> Sent: Donnerstag, 7. September 2017 13:07
> To: Langer, Christoph ; Felix Yang
>
Hi Felix,
this looks good in general.
I would, however, suggest to rename the method 'recreateServerSocket' into '
createServerSocket' as the former name suggests that something which existed
once was recreated. But in this case the socket is simply created with a few
retries when exceptions o
Hi,
looks like a great piece of modern concurrent Java coding :) Well done! +1
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Freitag, 23. Juni 2017 15:28
> To: Seán Coffey ; Langer, Christoph
>
> Cc: net-
"-Thread-".
Best regards
Christoph
> -Original Message-
> From: Seán Coffey [mailto:sean.cof...@oracle.com]
> Sent: Freitag, 23. Juni 2017 11:57
> To: Langer, Christoph
> Cc: Vyom Tewari ; net-dev d...@openjdk.java.net>; Mark Sheppard
> Subject: Re: RFR :
Hi Sean,
I played with it a bit more and now really understand Vyoms observation. So,
what he sees is not the original concurrency issue but he encounters a
SocketException on some interface, where this is supposed to occur upon calling
getHardwareAddress().
So, to enable the testcase to run r
> From: Seán Coffey [mailto:sean.cof...@oracle.com]
> Sent: Donnerstag, 22. Juni 2017 18:29
> To: OpenJDK Network Dev list ; Langer,
> Christoph
> Subject: RFR : 8182672: Java 8u121 on Linux intermittently returns null for
> MAC address
>
> JDK 10 fix required to correct a ra
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-boun...@openjdk.java.net] On
Behalf Of Thomas Stüfe
Sent: Dienstag, 16. Mai 2017 14:51
To: ppc-aix-port-...@openjdk.java.net; net-de
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 [mailt
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 #
ril 2017 15:22
> To: Langer, Christoph
> Cc: net-dev@openjdk.java.net
> Subject: Re: [PATCH] 8035653: jdk8u152-b01 windows crash on
> DatagramSocket.getLocalAddress
>
> Hi Christoph,
>
> On 04/19/2017 10:53 AM, Langer, Christoph wrote:
> > Hi Alex,
> >
> >
Hi Alex,
I've just quickly checked this and it seems worthwile to me to downport 8035653
to JDK8.
As the patch will probably not apply cleanly to JDK8 after unshuffling [1] ,
you will need to create a new public review and post it on this mailing list.
Some JDK8 reviewer needs to review it and
Hi Martin and colleagues,
Sounds good. I’m supporting that and I’m willing to assist with
testing/reviewing.
But if it comes to larger changes and JEPs/CCCs (or the new CSR), it will need
an owner at Oracle… like Chris.
Best regards
Christoph
From: net-dev [mailto:net-dev-boun...@openjdk.java
Hi Michael,
Thanks for reviewing. So I'll push them in jdk10.
Best regards
Christoph
From: Michael McMahon [mailto:michael.x.mcma...@oracle.com]
Sent: Donnerstag, 26. Januar 2017 15:51
To: Langer, Christoph
Cc: Chris Hegarty ; net-dev@openjdk.java.net
Subject: Re: RFR(M): 8167457: Fixe
that I can get it out of my head. :)
Thanks & Best regards
Christoph
From: Langer, Christoph
Sent: Mittwoch, 21. Dezember 2016 15:57
To: net-dev@openjdk.java.net
Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows
Hi again,
after pushing the change for 81710
Hi,
I finally pushed the change:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f3115622562a
Best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 11. Januar 2017 16:50
> To: 'Chris Hegarty'
> Cc: Lindenmaier, Goetz ; net
1 - 100 of 221 matches
Mail list logo
