Hi all,
can I please get a review for a change to NetworkInterface.c
bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521
webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/
Apart from quite a few whitespace changes to clean up the coding, I went
through and replaced all occur
Hi,
@Chris: As for your points:
> I agree with the replacement of strcpy with strncpy, but I think we should
> explicitly null terminate in case the src is greater or equal to the dst
> buffer
> size. This is done elsewhere in this file too, e.g.
>
>strncpy(buf, input, sizeof(buf) - 1);
>
ttwoch, 11. Mai 2016 12:25
> To: Langer, Christoph
> Cc: Alan Bateman ; Dmitry Samersoff
> ; [email protected]
> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c
>
>
> On 11 May 2016, at 10:21, Langer, Christoph
> wrote:
>
>
Hi Doychin,
thanks for pointing me to this. I was already looking at that part of the code
and know about some gaps. So I'll take this item and open a bug and work on
integrating the proposed change.
I'll probably be able to start working on this next week. But before that my
fix for Bug 81565
ge-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Donnerstag, 12. Mai 2016 12:43
> To: Langer, Christoph
> Cc: Alan Bateman ; Dmitry Samersoff
> ; Mark Sheppard
> ; [email protected]
> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in Networ
Looks nice, thanks :)
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Donnerstag, 12. Mai 2016 17:36
> To: Langer, Christoph
> Cc: [email protected]
> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.
Hi,
to me the changes look good.
I'll take the patch into my queue and do some testing on AIX.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Chris
> Hegarty
> Sent: Donnerstag, 12. Mai 2016 17:32
> To: Martin Buchholz
Hi Chris,
looks nice, I had seen some of these places, too.
Here is another one which you could add:
--- a/src/java.base/unix/native/libnet/NetworkInterface.c Tue May 24
10:14:41 2016 -0700
+++ b/src/java.base/unix/native/libnet/NetworkInterface.c Wed May 25
14:56:31 2016 +0200
@@
Hi Doychin,
I think your issue/fix proposal is good. As I’m currently working on the addif
function and planning some change there, firstly motivated by AIX, I could work
your suggestions into my upcoming fix. If it can wait another one or two weeks
I’d even love to do it. But feel free to re
Hi all,
please review the following change:
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8158023
During error analysis I stumbled over a place where I encountered a
SocketException which was thrown along with some strerror informati
Hi,
ping - any comments on this?
Thanks
Christoph
From: Langer, Christoph
Sent: Freitag, 27. Mai 2016 10:30
To: [email protected]
Cc: [email protected]; [email protected]
Subject: RFR 8158023: SocketExceptions contain too little information sometimes
Hi all,
please
hing useful. So, shall I add the
error number to the message in any case?
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Mittwoch, 1. Juni 2016 11:26
> To: Langer, Christoph
> Cc: [email protected];
ttwoch, 1. Juni 2016 11:26
> To: Langer, Christoph
> Cc: [email protected]; Bernd Eckenfels
> Subject: Re: Ping - RFR 8158023: SocketExceptions contain too little
> information
> sometimes
>
> Christoph,
>
> > On 1 Jun 2016, at 08:33, e...@zusammenkunft.
Hi Chris,
I had already created a bug report for this:
https://bugs.openjdk.java.net/browse/JDK-8158170 in the meanwhile but
unfortunately, by mistake, I had just sent this information to Doychin and not
to the mailing list. So, feel free to close and mark my bug as duplicate.
I also started w
Hi,
this is another ping. Any review for my update?
Thanks
Christoph
-Original Message-
From: Langer, Christoph
Sent: Mittwoch, 1. Juni 2016 23:59
To: 'Chris Hegarty' ; Bernd Eckenfels
Cc: [email protected]
Subject: RE: Ping - RFR 8158023: SocketExceptions contain
one:
http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009880.html
There is an updated webrev but it obviously still contains this mistake.
Thanks
Christoph
> -Original Message-
> From: Kenji Kazumura [mailto:[email protected]]
> Sent: Mittwoch, 8. Juni 2016 02:51
>
Hi Chris,
I now took time to look at your proposal based on ioctl calls. This looks very
good. I came up with some modifications to your patch and created another
webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8158519.1/
This builds on Linux, AIX, Solaris and Mac and the basic test to lis
Hi,
can I please get a review the following change:
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
I made further fixes and cleanups for listing Unix type network interfaces,
especially on AIX and Linux. I ran builds and verif
> -Original Message-
> From: Kenji Kazumura [mailto:[email protected]]
> Sent: Mittwoch, 8. Juni 2016 02:51
> To: Langer, Christoph
> Cc: [email protected]; [email protected]; core-libs-
> [email protected]
> Subject: Re: RFR 8158023: SocketExceptions c
checking the return value of getLastErrorString: "if (n >
0)".
Best regards
Christoph
>
> On 27/06/2016 08:42, Langer, Christoph wrote:
> > Hi,
> >
> > eventually here is the - hopefully final - version of this fix:
> > http://cr.openjdk.java.net/~c
place: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/
Now I finally need a review…
Best regards
Christoph
From: Paul Benedict [mailto:[email protected]]
Sent: Montag, 27. Juni 2016 18:15
To: Langer, Christoph
Cc: Kenji Kazumura ; Chris Hegarty
; [email protected];
core
e jni up calls to invoke java methods.
>
> jni_util.c: line 216:
>
>You should not need to create an extra string; the string s is
> non-null and ready to use.
>
> jni_util.h:
>
>line 117-119, The original comment was just as informative as the
> replacement.
Thanks, pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b88eb2f451d
From: Roger Riggs [mailto:[email protected]]
Sent: Mittwoch, 29. Juni 2016 23:22
To: Langer, Christoph
Cc: [email protected]; [email protected];
[email protected]
Subject: Re: RFR 8158023
he IPv6 broadcast address - which I
think is common sense for IPv6.
Thanks in advance and best regards
Christoph
From: Langer, Christoph
Sent: Donnerstag, 23. Juni 2016 16:37
To: '[email protected]'
Subject: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
improvement
o getifaddrs at the time
the Java 10 branch opens to gain experience with that without shipment pressure.
Stay tuned :)
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 12. Juli 2016 16:10
> To: Langer, Christoph
>
[email protected]]
> Sent: Dienstag, 12. Juli 2016 16:10
> To: Langer, Christoph
> Cc: [email protected]
> Subject: Re: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
> improvements for network interface listing
>
> Christoph,
>
> > On 11 Jul 201
Hi folks,
I have a question to the experts - regarding an issue that was reported to me
by a customer.
In the customer scenario they are running a Servlet engine and the Servlet is
constantly sending data to a browser client. When the browser client is closed,
the server does not get a notific
Chris, David, Dmitry
thanks for your valuable input. This helps me a lot.
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Donnerstag, 14. Juli 2016 12:31
> To: Langer, Christoph
> Cc: net-dev@openjd
index also on BSD, where it was not done before.
Here I have the question if this is really the desired behavior to always set
the interface as scope of any IPv6 address?
Thanks in advance
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 13. Juli 2016 1
:[email protected]]
> Sent: Donnerstag, 21. Juli 2016 17:15
> To: Langer, Christoph ; [email protected]
> Subject: Re: PING: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and
> improvements for network interface listing
>
> Hi Christoph,
>
> On 19/0
Hi,
can you please review this very small change for AIX:
diff -r 8730c04eac90 -r 6451c746c6d5
src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c
--- a/src/java.base/unix/native/libnet/PlainDatagramSocketImpl.cFri Jul
29 19:00:54 2016 -0400
+++ b/src/java.base/unix/native/libnet
Hi,
please review these small fixes for Javadoc issues and removal of warnings.
Bug: https://bugs.openjdk.java.net/browse/JDK-8162819
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162819.1/
Thanks
Christoph
--Original Message-
> From: Daniel Fuchs [mailto:[email protected]]
> Sent: Montag, 1. August 2016 10:32
> To: Langer, Christoph ; [email protected]
> Subject: Re: RFR (XS): 8162819: fix minor Javadoc issues and remove warnings
> in java.net.Socket and java.net.In
il.com]
> Sent: Montag, 1. August 2016 10:23
> To: Langer, Christoph
> Cc: [email protected]; [email protected]
> Subject: Re: RFR (XXS): 8162811: use correct IPv6 multicast socket options for
> AIX in PlainDatagramSocketImpl.c
>
> Hi Christoph,
>
>
om: Daniel Fuchs [mailto:[email protected]]
> Sent: Montag, 1. August 2016 12:10
> To: Langer, Christoph ; [email protected]
> Subject: Re: RFR (XS): 8162819: fix minor Javadoc issues and remove warnings
> in java.net.Socket and java.net.Inet*Address
>
> Hi Christoph,
&g
Hi,
following up my change for https://bugs.openjdk.java.net/browse/JDK-8158023 I'd
like to discuss the removal of NET_ThrowByNameWithLastError and its replacement
with JNU_ThrowByNameWithLastError.
Currently NET_ThrowByNameWithLastError just adds the errno to a default message
and then calls
Hi,
I had made a few more cleanups when I was working on NetworkInterface.c which I
thought are worth contributing.
Please review: http://cr.openjdk.java.net/~clanger/webrevs/8163181.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8163181
As always, changes were built and tested on Linux, AIX,
Ping: Can I get a review for this small set of changes please?
Thanks
Christoph
From: Langer, Christoph
Sent: Donnerstag, 4. August 2016 15:04
To: [email protected]
Subject: RFR(S): 8163181: Further improvements for Unix NetworkInterface native
implementation
Hi,
I had made a few more
Hi Svetlana,
the patch looks nice. But unfortunately I'm not a reviewer.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of
> Svetlana Nikandrova
> Sent: Dienstag, 16. August 2016 17:35
> To: OpenJDK Network Dev list
> Sub
Hi Vyom,
to me the change looks good, apart from a few minor cosmetical remarks:
in SocketInputStream.c (new):
line 71: if (_timeout > 0) {
-> I think the if is indented by one space too much
line 109: LABEL: if (_timeout) {
-> as the length of "LABEL: " is more than 4 chars and hence the if is
Hi,
I made a little update to my change:
http://cr.openjdk.java.net/~clanger/webrevs/8163181.2/
Merely comments and a minor AIX specific correction.
Thanks in advance for reviewing
Christoph
From: Langer, Christoph
Sent: Dienstag, 16. August 2016 14:49
To: '[email protected]'
Hi Vyom,
the build on AIX was successful.
Best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 22. August 2016 14:40
> To: 'Vyom Tewari' ; net-dev [email protected]>
> Subject: RE: RFR 8075484:SocketInputStream.so
Hi Artem,
looks good - Unfortunately I'm no reviewer.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Artem
> Smotrakov
> Sent: Dienstag, 23. August 2016 04:03
> To: Net Dev OpenJDK
> Subject: [9] RFR: 8164592: java/net/
+1
From: net-dev [mailto:[email protected]] On Behalf Of Mark
Sheppard
Sent: Donnerstag, 1. September 2016 19:51
To: Vyom Tewari ; [email protected]
Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
soTimeout set
Hi Vyom,
thanks for doing the r
s are only opened for platforms where an ioctl is done
to determine the MacAddress.
As I've said, I've tested it on the Linux/Unix platforms.
Thanks a lot
Christoph
From: Langer, Christoph
Sent: Montag, 22. August 2016 15:30
To: '[email protected]'
Subject: RE: Ping:
Hi,
can you please review and approve a tiny and straightforward fix for AIX only
in JDK8.
Bug: https://bugs.openjdk.java.net/browse/JDK-8165320
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165320.8udev/
When integrating 8160174, I oversaw 2 minor places where JVM_Socket should be
used
That's great, thanks.
I'll push on Monday.
Best regards
Christoph
From: Mark Sheppard [mailto:[email protected]]
Sent: Freitag, 2. September 2016 16:50
To: Langer, Christoph ; [email protected]
Subject: Re: Ping: RFR(S): 8163181: Further improvements for Unix
Networ
Done: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2
Thanks for review/testing.
From: Langer, Christoph
Sent: Freitag, 2. September 2016 16:51
To: 'Mark Sheppard' ; [email protected]
Cc: 'Chris Hegarty'
Subject: RE: Ping: RFR(S): 8163181: Further i
Hi Vyom,
I'll do an AIX build with your patch and let you know later today.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Vyom
> Tewari
> Sent: Mittwoch, 7. September 2016 08:46
> To: Chris Hegarty
> Cc: net-dev@openjd
uggestion:
http://cr.openjdk.java.net/~clanger/webrevs/8075484-clanger/
Maybe that's a better distribution of code?
It builds on AIX - other platforms I didn't test so far.
Best regards
Christoph
> -Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 7. Septe
Hi Vyom,
did you have a look at my suggestions regarding AIX and refactoring? I can't
find none of it in the new webrev nor did you comment on it.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Vyom
> Tewari
> Sent: Mit
rom: Vyom Tewari [mailto:[email protected]]
> Sent: Mittwoch, 7. September 2016 18:31
> To: Langer, Christoph
> Cc: [email protected]; Chris Hegarty
> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
>
> Hi Chris,
>
&
).
And no "#include " would be needed in SocketInputStream.c - maybe
not even now as it is.
Best regards
Christoph
> -Original Message-
> From: Vyom Tewari [mailto:[email protected]]
> Sent: Donnerstag, 8. September 2016 05:20
> To: Langer, Christoph
> Cc: net
s, long timeout, long currentTime)
>^^^
> Thanks,
> -Chris.
>
> > Vyom
> >
> > On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote:
> >>
> >> On Thursday 08 September 2016 02:50 PM, Langer
Hi Rob,
this looks like a nice fix and I can't see anything besides the copyright year
which you will for sure update when submitting. :)
Unfortunately I'm not a reviewer so you'll have to get another real review.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-
Hi,
while looking at utility functions for creating exceptions in libjava/libnet I
found a small spot that should be consolidated right away.
The function NET_ThrowSocketException does only exist in the windows native
implementation and is only used in 3 places in SocketInputStream.c. I removed
Hi Felix,
looks ok to me, though I'm no reviewer.
One nit: test/java/net/MulticastSocket/TimeToLive.java, line 40, you could
remove the ';' from the try statement.
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Felix
>
me or the
JNU_JAVANETPKG define? Any opinion on that?
Thanks for taking care of this,
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Montag, 26. September 2016 16:51
> To: Langer, Christoph ; [email protected]
> Subjec
--Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 27. September 2016 10:10
> To: Langer, Christoph
> Cc: [email protected]
> Subject: Re: RFR(XS): 8166584: Remove obsolete utility function
> NET_ThrowSocketException in windows l
Thanks, I pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2b5229c75e93
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 27. September 2016 21:24
> To: Langer, Christoph
> Cc: [email protected]
Hi,
during my work on exception sites in the JDK, I spotted another minor place
that should be fixed. In the Windows native implementations of
DualStackPlainDatagramSocketImpl and DualStackPlainSocketImpl, there are calls
to evaluate OS API errors after unsuccessful return of NET_MapSocketOptio
Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/153b4781adcc
Thanks, Chris, for reviewing.
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Donnerstag, 29. September 2016 13:40
> To: Langer, Christoph
> Cc: [email protected]
+1 ... Looks good to me
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Chris
> Hegarty
> Sent: Donnerstag, 29. September 2016 10:21
> To: Vyom Tewari
> Cc: Kharbas, Kishor ; Viswanathan, Sandhya
> ; Aundhe, Shirish
> ; net-dev ; Kaczmarek,
> Er
Hi,
I think I would also support replacing sun.net.ConnectionResetException with a
publicly available java.net.ConnectionResetException that subclasses
java.net.SocketException. But, as Chris mentions. a usage example would be
helpful.
Best regards
Christoph
> -Original Message-
> Fro
Hi,
I'm looking to contribute a few of our diffs in the network area to OpenJDK.
This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295
This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/
Besides minor cleanups, initializations and fixes, the main thing that I'm
to
the queue for our nightly build/test runs and check for regressions...
Thanks
Christoph
From: Langer, Christoph
Sent: Donnerstag, 6. Oktober 2016 17:44
To: [email protected]
Cc: [email protected]
Subject: RFR(L): 8167295: Contribute further changes from SAP to native parts
of
Hi,
here's another review request for a cleanup:
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167420.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8167420
In unix/native/libnet/Inet4AddressImpl.c, there exist 2 implementations for
each of Java_java_net_Inet4AddressImpl_getLocalHostNa
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Montag, 10. Oktober 2016 14:08
> To: Langer, Christoph ; [email protected]
> Cc: [email protected]
> Subject: Re: RFR(L): 8167295: Further cleanup
Hi,
as I already mentioned, here is another proposal for cleanup in libnet:
https://bugs.openjdk.java.net/browse/JDK-8167481
http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/
This time I touched the includes. Generally I reordered the includes to include
"net_util.h" first, then any JNI inc
Hi networking experts,
I've got a question regarding AF_INET6.
In jdk native code you'll still find lots of code guarded by "#ifdef
AF_INET6". I'm wondering if there are still supported build environments where
AF_INET6 is not defined. Or is it time now to assume AF_INET6 and remove this
guar
Hi Chris,
> > I’ve got a question regarding AF_INET6.
> >
> > In jdk native code you’ll still find lots of code guarded by “#ifdef
> > AF_INET6”.
> I’m wondering if there are still supported build environments where AF_INET6
> is not defined. Or is it time now to assume AF_INET6 and remove this
Hi,
please review (@Chris or Mark) and approve the following downport.
Bug: https://bugs.openjdk.java.net/browse/JDK-8163181
Original Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2
New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163181.8udev/
Mail discussion:
http://ma
Hi,
is there any comments/reviews for my cleanup work here?
The changeset was added to our local OpenJDK build and test infrastructure
several days ago and it does not show issues...
Thanks
Christoph
From: Langer, Christoph
Sent: Mittwoch, 12. Oktober 2016 14:17
To: [email protected]
Thanks, Chris.
So then I'm asking for approval now...
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 18. Oktober 2016 12:53
> To: Langer, Christoph
> Cc: [email protected]; Mark
Hi Pavel,
overall this looks good. I've got a few minor remarks:
1. What about using the macro CHECK_NULL_RETURN in NetworkInterface_winXP.c?
2. in Java_java_net_TwoStacksPlainDatagramSocketImpl_peekData:
You could move
1178 /* make sure receive() picks up the right fd */
1179 (*env)->S
Hi Pavel,
> > On 20 Oct 2016, at 14:03, Langer, Christoph
> wrote:
> >
> > Hi Pavel,
> >
> > overall this looks good. I've got a few minor remarks:
> >
> > 1. What about using the macro CHECK_NULL_R
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 18. Oktober 2016 20:56
> To: Langer, Christoph ; [email protected]
> Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and includes for
Hi,
please review the cleanup of "#ifdef AF_INET6" in libnet coding. I have opened
a separate JIRA issue as requested
This is a mailthread where it was already discussed:
http://mail.openjdk.java.net/pipermail/net-dev/2016-October/010374.html
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/
Thanks, Chris. I pushed it...
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Mittwoch, 26. Oktober 2016 15:39
> To: Langer, Christoph
> Cc: [email protected]
> Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and incl
Thanks, Chris.
I pushed it: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6577fabed061
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Dienstag, 1. November 2016 14:34
> To: Langer, Christoph
> Cc: net-dev@o
appreciate any feedback on the points I elaborated above.
Thanks & Best regards
Christoph
From: Langer, Christoph
Sent: Montag, 10. Oktober 2016 09:32
To: '[email protected]'
Subject: RFR(S): 8167420: remove redundant code path in
unix/native/libnet/Inet4AddressImpl.
Hi,
here is the Windows counterpart of 8167420.
Bug: https://bugs.openjdk.java.net/browse/JDK-8167457
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167457.0/
Mainly I suggest to replace gethostbyaddr/gethostbyname in Inet4AddressImpl.c
to getaddrinfo/getnameinfo - such as Inet6AddressImp
't it? Maybe it's really better to always
return what the gethostname API says. Or is there a reason why IPv4 and IPv6
handling is different?
Best regards
Christoph
From: Langer, Christoph
Sent: Mittwoch, 2. November 2016 15:25
To: '[email protected]'
Subject: RFR(M):
Hi,
> On 10 Nov 2016, at 16:48, Alan Bateman wrote:
> > On 10/11/2016 16:39, Mark Sheppard wrote:
> >> Hi,
> >> please oblige and review the change
> >>
> http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/cl
> asses/java/net/NetworkInterface.java.sdiff.html
> >>
> >> to ad
Hi,
I just wanted to ping on that one to make sure it does not get forgotten...
Best regards
Christoph
From: Langer, Christoph
Sent: Donnerstag, 3. November 2016 16:46
To: '[email protected]'
Subject: RE: RFR(M): 8167420: remove redundant code path in
unix/nat
Same for that, as it goes together with 8167420.
From: Langer, Christoph
Sent: Mittwoch, 2. November 2016 15:37
To: '[email protected]'
Subject: RFR(M): 8167457: Switch Windows Inet4AddressImpl to
getaddrinfo/getnameinfo
Hi,
here is the Windows counterpart of 8167420.
Hi,
please review a downport of a few small fixes to JDK 8 which were done through
bugs 8034174, 8034182 and 8048518 to JDK 9 already.
Bug: https://bugs.openjdk.java.net/browse/JDK-8169865
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169865.8udev/
The change in Inet6AddressImpl.c is req
nt: Montag, 21. November 2016 15:18
> To: Langer, Christoph ; [email protected]
> Subject: Re: RFR(M): 8167420: remove redundant code path in
> unix/native/libnet/Inet4AddressImpl.c
>
> Hi Christoph,
>
> On 03/11/16 15:46, Langer, Christoph wrote:
> > Hi again,
Thanks, Chris.
It's pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/90d2c6ddcedd
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Montag, 21. November 2016 11:54
> To: Langer, Christoph
> Cc: net-dev@ope
enumerated all significant changes in its description. I did quite
some extensive testing in our landscape and would ask you to run it through
JPRT testing as well.
Thanks a lot in advance
Christoph
From: Langer, Christoph
Sent: Mittwoch, 2. November 2016 15:37
To: '[email protected]'
27;ll do getnameinfo/getaddrinfo for
all unix platforms for inet4 and only for solaris for inet6.
Thanks a lot in advance
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Freitag, 25. November 2016 11:42
> To: Langer, Ch
Hi,
please review the following change:
Bug: https://bugs.openjdk.java.net/browse/JDK-8170544
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8170544.0/
With this change I change some function signatures to use SOCKETADDRESS *
instead of struct sockaddr * where appropriate. This fixes some
gards
Christoph
From: Michael McMahon [mailto:[email protected]]
Sent: Mittwoch, 30. November 2016 17:57
To: Langer, Christoph
Cc: [email protected]; Chris Hegarty ;
Lindenmaier, Goetz
Subject: Re: RFR: 8170544: Fix code scan findings in libnet
I will run the change through
Hi Michael,
I have just updated http://cr.openjdk.java.net/~clanger/webrevs/8170544.0/ in
place. The old version caused a compile warning on Linux.
Best regards
Christoph
From: Langer, Christoph
Sent: Mittwoch, 30. November 2016 19:01
To: 'Michael McMahon'
Cc: [email protected].
Hi Felix,
looks ok to me.
You probably should remove the reference to the old shell script in comment
line 25, though:
25 * Test run from script, AcceptCauseFileDescriptorLeak.sh
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On
Hi,
I would also support if IOException could be enriched to expose the native
error code. However, the user then would need to evaluate this code in a
platform specific manner. Maybe there could be some class/interface which would
help to translate platform specific error codes to common const
Hi,
please review this small fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164057
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8164057.0/
The root cause of the wrong "@since" tags probably is that the classes
Inet[46]Address had been created as copy of InetAddress. InetAddress itse
Hi Chris,
Ok, thanks. Let me know when ccc is processed and it can be pushed.
Best regards
Christoph
> -Original Message-
> From: Chris Hegarty [mailto:[email protected]]
> Sent: Mittwoch, 7. Dezember 2016 11:52
> To: Langer, Christoph
> Cc: [email protected]
Hi Felix,
looks good also for me.
Small typo:
85 throw new RuntimeException("Mistmatch between default"
Mistmatch -> Mismatch :)
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:[email protected]] On Behalf Of Felix
> Yang
> Sent: Donn
Hi Michael,
the bug then obviously was a side effect of my change
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9f0ab4b20ff7 for 8167481. Sorry for
that.
To follow the concept of my cleanups I'd prefer if you could use #if
defined(MACOSX) rather than #ifdef MACOSX in net_util_md.c to be consiste
1 - 100 of 221 matches
Mail list logo