JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.openjdk.java.net/browse/JDK-8010371 Webrev http:/

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote: > On 01/10/2013 11:31, Brian Burkhalter wrote: >> Hello net-dev members, >> >> Please review this proposed fix at your convenience. >> >> Summary >> When looking up a host and an EAGAIN error is encoun

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 1, 2013, at 11:59 AM, Brian Burkhalter wrote: > It seems a bit unclear to me and to depend on which system one is on. There > is also the possibility apparently of it returning EAI_AGAIN. It might be > best to test both the return value and if that is EAI_SYSTEM to test

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 1, 2013, at 1:25 PM, Michael McMahon wrote: >> The approach I initially was going to take was to retry once after a short >> wait and then fail with the proposed exception if the retry failed. > > I'm not sure about the short wait. I know the submitter claims that it worked > after 50ms

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

All, Please see comments inline. Thanks, Brian On Oct 1, 2013, at 8:44 PM, Alan Bateman wrote: > On 01/10/2013 12:46, Brian Burkhalter wrote: >> : >> >> I updated the webrev >> >> http://cr.openjdk.java.net/~bpb/8010371/ >> >> with changes in th

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

Resuming this discussion … Thanks for the previous comments. My feeling at this point is to do one of two things: A) defer to something after JDK 8, or B) on EAI_AGAIN do not retry but set the cause of the UAE to "new SomeException(gai_strerror(error))" where SomeException could be for example

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 8, 2013, at 2:43 AM, Alan Bateman wrote: >> Thanks for the previous comments. My feeling at this point is to do one of >> two things: >> >> A) defer to something after JDK 8, or >> B) on EAI_AGAIN do not retry but set the cause of the UAE to "new >> SomeException(gai_strerror(error))" wh

hg: jdk8/tl/jdk: 8016252: More defensive HashSet.readObject

Changeset: b86e6700266e Author:bpb Date: 2013-10-09 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b86e6700266e 8016252: More defensive HashSet.readObject Summary: Add data validation checks in readObject(). Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 9, 2013, at 11:16 AM, Brian Burkhalter wrote: > For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and > modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not > yet been compiled pending comments. Since compiled successfully on Wi

hg: jdk8/tl/jdk: 7189139: BigInteger's staticRandom field can be a source of bottlenecks.

andoz Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 10, 2013, at 6:52 AM, Alan Bateman wrote: > Thanks for persevering with this, we are on the right road now. > > I just looked at JDK-8010371 and the "OS" field is set to "linux". I don't > know if this is right but as IPv6 is usually enabled by default these days > then I have to guess

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 10, 2013, at 12:37 PM, Brian Burkhalter wrote: > Yes, I read about the thread safety. There are other ways to do this but I > wanted first to air the general idea using gai_strerror() before doing any > further work. > >> […] > > Thanks, I did read about Form

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 14, 2013, at 1:58 AM, Alan Bateman wrote: >> 2) In Inet4AddressImpl.c and Inet6AddressImpl.c replace >> NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowByNameWithLastError >> (see net_md_util.c). >> >> […] >> >> If the "con" of option 2 is acceptable then I think that would be

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 15, 2013, at 6:21 AM, Alan Bateman wrote: >> Here's the patch updated for this option: >> >> http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ >> > I think this is okay, the only concern is that the host name is no longer > guaranteed

hg: jdk8/tl/jdk: 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

. Reviewed-by: alanb, chegar, michaelm, dsamersoff Contributed-by: Brian Burkhalter ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

Dmitry, I think you are correct: that slipped by both me and the reviewers. I have reopened the issue and posted an amendment to the original webrev here: http://cr.openjdk.java.net/~bpb/8010371/webrev.4-amendment/ Thanks for catching this. Brian On Oct 16, 2013, at 3:06 PM, Dmitry Samersoff

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

Sorry about that. Obviously I still need to learn some things about the process, e.g., review the prescribed workflow. Thanks, Brian On Oct 16, 2013, at 7:48 PM, David Holmes wrote: > Brian, > > On 17/10/2013 9:21 AM, Brian Burkhalter wrote: >> Dmitry, >> >> I

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On Oct 17, 2013, at 5:37 AM, Alan Bateman wrote: > On 17/10/2013 00:21, Brian Burkhalter wrote: >> Dmitry, >> >> I think you are correct: that slipped by both me and the reviewers. I have >> reopened the issue and posted an amendment to the origin

JDK 8 RFR 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6

Burkhalter wrote: > > On Oct 17, 2013, at 5:37 AM, Alan Bateman wrote: > >> On 17/10/2013 00:21, Brian Burkhalter wrote: >>> Dmitry, >>> >>> I think you are correct: that slipped by both me and the reviewers. I have >>> reopened the issue

hg: jdk8/tl/jdk: 8026832: Clean up straggling doclint warnings in java.math

Changeset: e76bb2436b04 Author:bpb Date: 2013-10-17 15:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76bb2436b04 8026832: Clean up straggling doclint warnings in java.math Summary: Fix empty paragraph tag warnings. Reviewed-by: lancea ! src/share/classes/java/math/BigDe

hg: jdk8/tl/jdk: 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6

Changeset: 9758edb6976f Author:bpb Date: 2013-10-22 10:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9758edb6976f 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6 Summary: Check getaddrinfo return value before ca

hg: jdk8/tl/jdk: 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE; ...

Changeset: 2be08cdd1ced Author:bpb Date: 2013-10-22 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2be08cdd1ced 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE 6445180: URLClassLoader does not describe the behavior of several methods w

hg: jdk8/tl/jdk: 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers; ...

Changeset: 0734e1584d9d Author:bpb Date: 2013-10-30 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0734e1584d9d 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers 8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infini

hg: jdk8/tl/jdk: 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size

Changeset: 92fb6baaebc4 Author:bpb Date: 2013-11-04 08:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92fb6baaebc4 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size Summary: Add @run tag to specify heap size Reviewed-by: alan

hg: jdk8/tl/jdk: 8022181: Tune algorithm crossover thresholds in BigInteger

Changeset: c138b0d33980 Author:bpb Date: 2013-12-03 12:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138b0d33980 8022181: Tune algorithm crossover thresholds in BigInteger Summary: Change multiplication, squaring, division, and base conversion thresholds to values which

hg: jdk8/tl/jdk: 2 new changesets

Changeset: d3c4e8fe98c3 Author:bpb Date: 2013-12-05 07:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3c4e8fe98c3 8029514: java/math/BigInteger/BigIntegerTest.java failing since thresholds adjusted in 8022181 Summary: Ensure the value returned by getLower() is unsigned.

[9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense

Please review at your convenience. This a doc-only change. Issue: https://bugs.openjdk.java.net/browse/JDK-8074937 Patch: http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ This is in effect an amplification of extant javadoc suggested as an enhancement by an external user. I performed some te

Re: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense

ying add additional clarification around something that > has never, to the best of my knowledge, been the source of confusion. The > description in JIRA seems overly pedantic. > > -Chris. > > On 19/03/15 14:47, Alan Bateman wrote: >> On 19/03/2015 14:30, Brian Burkhalter w

Re: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense

Identical verbiage is in fact also present in http://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#ServerSocket-int-int- and http://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#ServerSocket-int-int-java.net.InetAddress- To wit: "The backlog argument is the reques

[9] RFR of 8129499: Structure of java/rmi/activation/rmidViaInheritedChannel tests masks exception

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8129499 Patch: http://cr.openjdk.java.net/~bpb/8129499/webrev.00/ Summary: The instance variable ‘rmid’ is never initialized due to some error which occurs before the statement which would initialize it but it i

Fwd: [9] RFR of 8129499: Structure of java/rmi/activation/rmidViaInheritedChannel tests masks exception

Sorry: posted to wrong list. Re-direct this thread to: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034223.html Begin forwarded message: > From: Brian Burkhalter > Subject: [9] RFR of 8129499: Structure of > java/rmi/activation/rmidViaInheritedChannel tests masks

[9] RFR of 8129510: java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java should exclude testing the Teredo tunneling interface on Windows

Please review this test-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8129510 Patch: see diff below The analysis in the comments on https://bugs.openjdk.java.net/browse/JDK-8042902 suggests that excluding testing of Teredo tunneling in this test might be app

RFC on 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams

This core-libs-dev RFR http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037847.html was already approved on core-libs-dev but I would like to make sure there is no objection from the net-dev community. Thanks, Brian

Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

Hi Sergey, This is not my area of expertise so probably a second Reviewer would be in order here but the changes appear straightforward. On Jul 8, 2016, at 2:40 PM, Sergey Kuksenko wrote: > Could you please review the following fix for JDK-8161091? > > http://cr.openjdk.java.net/~skuksenko/je

JDK 9 RFR of 8162745: content-types.properties files are missing some modern types

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8162745 Patch: http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ Add some content types from HTML5 and Xiph. Note that this patch depends on the prior application of the patch for JDK-8146215 [1] which is await

Re: RFR 8175305: Typos in net.properties

+1 On Feb 21, 2017, at 8:01 AM, Pavel Rappo wrote: > Hello, > > Could you please review the following trivial change for [1]? > > http://cr.openjdk.java.net/~prappo/8175305/webrev.00/ > > Thanks, > -Pavel > >

Re: RFR [9] 8178161: Default multicast interface on Mac

On Apr 6, 2017, at 11:07 AM, Chris Hegarty wrote: >> On 6 Apr 2017, at 17:50, Michael McMahon >> wrote: >> >> Looks fine to me Chris. Stylistically, the boolean tests >> in line 104 could remove the == true obviously, but not a big deal. > > Thanks, I’ll make this change before pushing. +1

Re: RFR: JDK-7155591 - [macosx] regression test java/net/MulticastSocket/SetOutgoingIf.java fail

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 wrote: > Hi, >plea

Re: Fix typo in InetSocketAddress.getAddress() documentation

Hi Chris, Sure, no problem: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html Brian On Jan 4, 2018, at 1:13 PM, Chris Hegarty wrote: > Would you mind adding the below typo to another you are fixing under > JDK-8193861 ( to reduce the overhead ).

RFR 8198302: VS2017 (C4477) java.base/windows/native/libnet/NetworkInterface_winXP.c incorrect printf format strings

https://bugs.openjdk.java.net/browse/JDK-8198302 Changes are in the diff below. Thanks, Brian --- a/src/java.base/windows/native/libnet/NetworkInterface_winXP.c +++ b/src/java.base/windows/native/libnet/NetworkInterface_winXP.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2017, Oracle and/or its

Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations

Hi Christoph, This looks OK to me but probably a net-dev engineer should also comment. The bug needs a noreg label, e.g., noreg-cleanup. Brian On Apr 26, 2018, at 11:56 AM, Langer, Christoph wrote: > Ping, can some reviewer please have a look at this small fix? > […] > > Bug: https://bugs

[12] 8194899: Remove unused sun.net classes

https://bugs.openjdk.java.net/browse/JDK-8194899 The proposed change is to remove these classes which are unused in the JDK: sun.net.NetworkServer sun.net.URLCanonicalizer Thanks, Brian

Re: [12] 8194899: Remove unused sun.net classes

On Jul 2, 2018, at 10:23 AM, Alan Bateman wrote: > On 02/07/2018 18:21, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8194899 >> >> The proposed change is to remove these classes which are unused in the JDK: >> >> sun.net.NetworkS

Re: [XS] RFR: 8209994: windows: Java_java_net_NetworkInterface_getAll misses releasing interface-list

Hi Matthias, This looks fine to me. Thanks, Brian On Aug 27, 2018, at 8:12 AM, Baesken, Matthias wrote: > Hello, please review this small fix ; > > When returning from Java_java_net_NetworkInterface_getAll (windows > version), we have to free resources to avoid leaks. > In some speci

Re: [XS] RFR: 8209994: windows: Java_java_net_NetworkInterface_getAll misses releasing interface-list

Hi Matthias, I neglected to mention that an appropriate noreg-* label [1], perhaps “noreg-cleanup," will be needed on the issue as it seems likely untestable. Thanks, Brian [1] http://openjdk.java.net/guide/changePlanning.html#bug, section 6. On Aug 27, 2018, at 8:12 AM, Baesken, Matthias wr

Re: [XS] RFR: 8209994: windows: Java_java_net_NetworkInterface_getAll misses releasing interface-list

+3 Thanks, Brian On Aug 28, 2018, at 12:19 AM, Baesken, Matthias wrote: > looking at the coding, your sceanario ***should*** not happen ; however > to be on the safe side it is for sure better to do the initialization > you propose. > > Looking a bit more at the coding, there is a

8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

https://bugs.openjdk.java.net/browse/JDK-8213210 Please see diff included below. CSR to follow. Thanks, Brian --- a/src/java.base/share/classes/java/net/ServerSocket.java +++ b/src/java.base/share/classes/java/net/ServerSocket.java @@ -76,10 +76,13 @@ private boolean oldImpl = false;

Re: 8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

> On Oct 31, 2018, at 12:16 PM, Alan Bateman wrote: > > On 31/10/2018 19:13, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8213210 >> <https://bugs.openjdk.java.net/browse/JDK-8213210> >> >> Please see diff included below. CSR to

Re: 8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

> On Oct 31, 2018, at 12:20 PM, Brian Burkhalter > wrote: > > -ServerSocket(SocketImpl impl) { > +protected ServerSocket(SocketImpl impl) { > this.impl = impl; > impl.setServerSocket(this); // <- NPE if impl == null > } Oops, it can th

Re: RFR 8217740: SocksIPv6Test.java compilation error

Verified against current repo. +1 Brian > On Jan 24, 2019, at 10:58 AM, Roger Riggs wrote: > > Please review a quick fix for a test compilation error, as a side effect of > 8216986. > > diff --git a/test/jdk/java/net/Socks/SocksIPv6Test.java > b/test/jdk/java/net/Socks/SocksIPv6Test.java >

Re: RFR (testbug): 8217882: java/net/httpclient/MaxStreams.java failed once

Hi Daniel, Perhaps consistently capitalize the first word in each message? Otherwise OK. No need to refresh. Thanks, Brian > On Jan 28, 2019, at 9:42 AM, Daniel Fuchs wrote: > > Please find below a patch for: > > 8217882: java/net/httpclient/MaxStreams.java failed once > https://bugs.openjd

8218882: NET_Writev is declared, NET_WriteV is defined

Removing NET_Write{V,v} does not break the Unix build, at least for Linux, macOS, and Solaris, so perhaps these can in fact be removed [1] as suggested in the issue description. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8218882/webrev.00/

8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

https://bugs.openjdk.java.net/browse/JDK-8223813 http://cr.openjdk.java.net/~bpb/8223813/webrev.00/ FormatMessage() and FormatMessageW() occur in a number of locations: src/java.base/windows/

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Roger, Thanks for the $0.02. > On Jun 11, 2019, at 12:14 PM, Roger Riggs wrote: > > Having the extraneous suffix consistently removed seems like a good thing. > Though I'm not sure what the best form of the utility function is: > 1) return the count of characters to remove > 2) just trunca

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Ivan, I updated the patch: http://cr.openjdk.java.net/~bpb/8223813/webrev.01/ Please see comments inline below. > On Jun 11, 2019, at 5:06 PM, Ivan Gerasimov wrote: > > Inet4AddressImpl.c: > > 1) There is an extra space after FormatMess

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Ivan, I am perhaps beating a dead horse here, but how about this instead? if (n > 0) { NET_ThrowNew(env, err, buf); LocalFree(buf); } else { NET_ThrowNew(env, err, "FormatMessage failed");

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

gt; On Jun 12, 2019, at 9:51 AM, Brian Burkhalter > wrote: > > I am perhaps beating a dead horse here, but how about this instead? > > if (n > 0) { > NET_ThrowNew(env, err, buf); > LocalFree(

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Ivan, > On Jun 12, 2019, at 4:03 PM, Ivan Gerasimov wrote: > > On 6/12/19 10:02 AM, Brian Burkhalter wrote: >> Actually, never mind, I am being completely lame here: both NET_ThrowNew() >> and the Windows function LocalFree() are robust to a NULL-valued buf so I >&g

Re: RFR [13] 8226730: Missing `@` in code tags

Hi Patrick, Looks OK to me except the 2017 copyright year in URLStreamHandler needs to be 2019. Thanks, Brian > On Jun 25, 2019, at 7:36 AM, Patrick wrote: > > Hi, > > Would it be possible to have my fix for JDK-8226730 reviewed? > > Fix inserts missing '@' symbols in code tags. > > Webre

Re: [teststabilization] RFR: 8226825: Replace wildcard address with loopback or local host in tests - part 19

Hi Julia, (part 19 (!)) In AsyncDisconnect line 57 could be replaced with ioe.printStackTrace() to be consistent with lines 85 and 88. Same thing for B6641309 line 58, and B6660405 line 108. I’ll leave comments on the more substantive changes to the net-dev experts. Thanks, Brian > On Jun 26

Re: RFR: 8227721: NetworkInterfaceRetrievalTests.java should open the java.net package

Hi Patrick, Based on [1] this looks OK to me. Brian [1] https://openjdk.java.net/jtreg/tag-spec.html > On Jul 17, 2019, at 9:52 AM, Patrick Concannon > wrote: > > Would it be possible to have my fix for JDK-8227721 reviewed? > > test/jdk/java/net/NetworkInterface/NetworkInterfaceRetrievalTe

Re: RFR: 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java

On Wed, 28 Oct 2020 18:48:51 GMT, Michael McMahon wrote: > …nnelConnectionSetup.java UnixSocketChannelReadWrite.java Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/912

Re: RFR: 8258696: Temporarily revert use of pattern match instanceof until docs-reference is fixed

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty wrote: > Temporarily revert use of pattern match instanceof construct until > docs-reference is fixed, see JDK-8258657. > > ... > Generating REFERENCE_API javadoc for 21 modules > > if (delegate instanceof ExecutorService service)

Re: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil

On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and > deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSS

Re: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0

On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > There seems to be an early return in > Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. > > Sonar reports : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=

Re: RFR: 8262296 Fix remaining doclint warnings in jdk.httpserver [v2]

On Wed, 24 Feb 2021 16:21:59 GMT, Chris Hegarty wrote: >> Trivial clean up of remaining doclint warnings in jdk.httpserver. >> >> The minor spec clarifications do not amount to a normative change, so no CSR >> is required (they're documented the obvious and only possible behaviour). > > Chris

Re: RFR: 8263233: Update java.net and java.nio to use instanceof pattern variable [v2]

On Tue, 9 Mar 2021 17:59:27 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.net` >> and `java.nio` packages to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the

Re: RFR: 8266155: Convert java.base to use Stream.toList()

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves wrote: > 8266155: Convert java.base to use Stream.toList() Looks all right. - Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3734

RFR: 8269481: SctpMultiChannel never releases own file descriptor

Please review this change to the Unix implementations of `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == ChannelState.UNINITIALIZED`. - Commit messages: - 8269481: SctpMultiChannel never releases own file descriptor Changes: https://git.openjdk.java.net/

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor

On Tue, 29 Jun 2021 00:44:25 GMT, Brian Burkhalter wrote: > Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. It would be good if someone more familiar with the SCTP

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v2]

On Tue, 29 Jun 2021 06:52:47 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8269481: Set state to KILLED *before* closing socket > > src/jdk.sct

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v2]

> Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 826

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v2]

On Tue, 29 Jun 2021 16:55:33 GMT, Chris Hegarty wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8269481: Set state to KILLED *before* closing socket > > src/jdk.sct

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v2]

On Tue, 29 Jun 2021 16:58:53 GMT, Chris Hegarty wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8269481: Set state to KILLED *before* closing socket > > test/jdk/com

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v3]

> Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v3]

On Tue, 29 Jun 2021 17:50:48 GMT, Brian Burkhalter wrote: >> Please review this change to the Unix implementations of >> `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == >> ChannelState.UNINITIALIZED`. > > Brian Burkhalter has updated the pu

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v3]

On Jul 1, 2021, at 1:17 AM, Alan Bateman mailto:al...@openjdk.java.net>> wrote: It looks like you've changed some but not all cases. I realize ChannelState.UNINITIALIZED is not too interesting but further maintainers may wonder about it. I’m not seeing that I missed any cases. I don’t really

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v3]

Oh I see now. Thanks. On Jul 1, 2021, at 8:56 AM, Alan Bateman mailto:alan.bate...@oracle.com>> wrote: I should have been clearer. Look at SctpServerChannelImpl.java L284 and SctpMultiChannelImpl.java L376. SctpNet.close(fdVal) added with the patch added them them before setting the state. Th

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v4]

> Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 826

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v5]

> Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 82

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v5]

On Fri, 2 Jul 2021 16:14:25 GMT, Brian Burkhalter wrote: >> Please review this change to the Unix implementations of >> `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == >> ChannelState.UNINITIALIZED`. > > Brian Burkhalter has updated the pu

Re: RFR: 8269481: SctpMultiChannel never releases own file descriptor [v6]

> Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

Integrated: 8269481: SctpMultiChannel never releases own file descriptor

On Tue, 29 Jun 2021 00:44:25 GMT, Brian Burkhalter wrote: > Please review this change to the Unix implementations of > `sun.nio.ch.sctp.Sctp*ChannelImpl#kill()` to close the socket if `state == > ChannelState.UNINITIALIZED`. This pull request has now been integrated. Changeset:

Re: RFR: 8273243: Fix indentations in java.net.InetAddress methods

On Wed, 1 Sep 2021 16:53:50 GMT, Aleksei Efimov wrote: > Hi, > > The fix changes indentations in the following `java.net.InetAddress` methods: > - getAddressesFromNameService > - getHostFromNameService > > It helps to improve code readability. Can't say the same about > `getHostFromNameService

Re: RFR: 8273655: content-types.properties files are missing some common types [v2]

On Thu, 16 Sep 2021 15:28:36 GMT, Julia Boes wrote: >> This change adds some common types to the content-type.properties files, >> notably .js, .css, and .jar, as well as some others. >> >> The duplicated entry for .zip is removed from the Windows properties file. > > Julia Boes has updated th

Re: RFR: 8274835: Remove unnecessary castings in java.base

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't > touch primitive types casts. `java.io` change looks all right. -

Re: RFR: 8286378: Address possibly lossy conversions in java.base

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy > conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not > assignment compatible with the type of the variable, a cast is

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy >> conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not >> assignment compatible with the type of the variable, a c

RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux

Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). - Commit messages: - 8287237: (fs) Files.probeContentType r

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2]

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the > file extension in the entire file name if it is not found in the portion of > the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request increment

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2]

On Fri, 27 May 2022 12:15:07 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8287237: Refactor and clean up > > src/java.base/share/classes/sun/net/www/Mime

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2]

On Sat, 28 May 2022 14:39:16 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8287237: Refactor and clean up > > src/java.base/share/classes/sun/net/www/Mime

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2]

On Tue, 31 May 2022 16:41:57 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/net/www/MimeTable.java line 188: >> >>> 186: int hashIndex = fname.lastIndexOf(HASH_MARK); >>> 187: if (hashIndex > 0) { >>> 188:

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v3]

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the > file extension in the entire file name if it is not found in the portion of > the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request increment

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v4]

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the > file extension in the entire file name if it is not found in the portion of > the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request increment

Integrated: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux

On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter wrote: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the > file extension in the entire file name if it is not found in the portion of > the name preceding the optional fragment beginning with a hash (`#

Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v4]

On Wed, 1 Jun 2022 07:28:11 GMT, Vyom Tewari wrote: > Looks ok, i tested on centos 7 and it is working as expected. To really verify it you would have to suppress `~/.mime.types` and `/etc/mime.types` before running the test. - PR: https://git.openjdk.java.net/jdk/pull/8909

Re: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17]

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess wrote: >> as title. > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > do it as naotoj said `java.io` and `java.nio` look all right. - Marked as reviewed by bpb (Reviewer