Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only

looks good to me, As Christoph already mentioned just update the copyright date. Vyom On Monday 16 April 2018 02:14 PM, Srividya Shamaiah wrote: Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/

Re: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/*

Hi Felix, Looks good to me, minor bit, please fix the tag order in all the tests, @summary should come immediately after @bug. In Tests.java there are unused imports(import java.net.*, java.io.*) can you please change it to use explicit classes. Thanks, Vyom On Tuesday 17 April 2018 09:04 A

Re: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/*

Hi Felix, latest code looks good to me, personally i prefer to throw exception instead returning null, but i can see that old code was also returning null. Hopping the code which invokes getFirstLocalIPv4Address, getFirstLocalIPv6Addres already taken care of null. Thanks, Vyom On Wednesda

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi Chris, On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: Vyom, On 13/04/18 10:50, vyom tewari wrote: Hi All, Please review the below code. BugId    : https://bugs.openjdk.java.net/browse/JDK-8194298 webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated  most of the review comments. Thanks, Vyom On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote: Vyom, On 13/04/18 10:50, vyom tewari wrote: Hi All, Please review

Re: RFR 8202154 : Remove unused code in java.base/windows/native/libnet

Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final.I see that Microsoft changed dynamic port range recently do we need to put some comment in PortConfig.java ? Thanks, Vyom On Tuesday 24 Apri

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

On Tuesday 24 April 2018 03:08 PM, Langer, Christoph wrote: 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 speci

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi Alan, Thanks for review comments, please find my answers inline. Vyom On Monday 23 April 2018 06:04 PM, Alan Bateman wrote: On 23/04/2018 13:05, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated  most

Re: RFR 8202154 : Remove unused code in java.base/windows/native/libnet

On Tuesday 24 April 2018 10:12 PM, Ivan Gerasimov wrote: Hi Vyom! On 4/23/18 11:29 PM, vyom tewari wrote: Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final. Yes, of course,

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

-Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 23. April 2018 14:06 To: Chris Hegarty ; OpenJDK Network Dev list Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive Hi, Please find t

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

Hi Christoph, On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: 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

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

On Friday 27 April 2018 10:58 AM, Thomas Stüfe wrote: On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari wrote: Hi Christoph, On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: Hi Vyom, I think, it is intentional to handle case where return "hostname" is to large to fit in

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

http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html [4] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html -Original Message- From: vyom tewari [mailto:vyom.tew...@oracle.com] Sent: Freitag, 27.

Re: RFR 8202558 : Access to freed memory in java.base/unix/native/libnet/net_util_md.c

Hi Ivan, the url(http://cr.openjdk.java.net/~igerasim/8202558/00/webrev/ ) is not accessible to me. Thanks, Vyom On Thursday 03 May 2018 01:51 AM, Ivan Gerasimov wrote: I just realized that we've got a similar issue in the same file in the function initLocalIfs(). The webrev was updated

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

April 2018 07:26 PM, Chris Hegarty wrote: On 23/04/18 13:34, Alan Bateman wrote: On 23/04/2018 13:05, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated  most of the review comments. This looks much better but

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.2/index.html) ... It would be better if the channel implementation didn't static import ExtendedSocketOptions.getInstance as that is a very generic method method name. As I ment

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

omplex nested "if-else" then linear ifs :)  fixed as well. Nit:  please place the equal sign at line 172 consistently with the other two inits above. fixed. With kind regards, Ivan On 5/11/18 7:43 PM, vyom tewari wrote: thanks all for review, please find the latest webrev(ht

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

ity and then make unmodifiable set with Set.copyOf(list). No further comments from my side :) if no further comment from others as well, i will change it to use default constructor at time of pushing. Thanks, Vyom With kind regards, Ivan On 5/12/18 2:21 AM, vyom tewari wrote: Hi Ivan,

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

dSocketOptions.java Thanks, Vyom On Sunday 13 May 2018 12:37 PM, Alan Bateman wrote: On 12/05/2018 10:21, vyom tewari wrote: : Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.4/index.html). I've skimmed through this webrev. The spec fo

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/2018 08:35, Langer, Christoph wrote: I’m asking because I’m planning to add some AIX options and will have to choose a name for this implementation eventually. @Alan: What do you think? Yes, I agree it should be renamed. Vyom

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.6/index.html). I renamed the macosx files to "MacOSXSocketOptions.java&MacOSXSocketOptions.c". Our internal tests are clean. Thanks, Vyom On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/201

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

On Friday 25 May 2018 11:19 AM, Ivan Gerasimov wrote: Hi Wiijun! On 5/24/18 10:13 PM, Weijun Wang wrote: On May 25, 2018, at 11:58 AM, Ivan Gerasimov wrote: I also wonder whether a smart compiler might not flag code where the errors do infact have the same value: if (errno == 11 || e

Re: RFR : 8205959 : Do not restart close if errno is EINTR

Hi Ivan, code changes looks good to me, although i am not the official reviewer. Thanks, Vyom On Thursday 28 June 2018 04:45 AM, Ivan Gerasimov wrote: Hello! When closing a socket via NET_SocketClose(int fd), a close(fd) is called. The later is wrapped in a retry-loop, which is wrong becaus

RFR: 8172346 sun.net.ftp.FtpDirEntry.setCreated(Date) may expose internal represent

Hi All, Please review below a trivial fix. Webrev : http://cr.openjdk.java.net/~vtewari/8172346/webrev0.0/index.html BugID: https://bugs.openjdk.java.net/browse/JDK-8172346 The above code change will avoid storing the externally mutable object reference into FtpDirEntry. Thanks, Vyom

Re: RFR: 8172346 sun.net.ftp.FtpDirEntry.setCreated(Date) may expose internal represent

Hi Chris, Thanks for review, please find my comment inline. Thanks, Vyom On Tuesday 24 July 2018 06:54 PM, Chris Hegarty wrote: On 24 Jul 2018, at 10:55, vyom tewari wrote: Hi All, Please review below a trivial fix. Webrev : http://cr.openjdk.java.net/~vtewari/8172346/webrev0.0

Re: [openjdk-x] Bind to a multicast address fails

On Monday 10 September 2018 12:28 PM, Andre Naujoks wrote: On 9/9/18 9:16 AM, Alan Bateman wrote: On 07/09/2018 13:22, Andre Naujoks wrote: : I have not tried joining IPv4 groups on an IPv6 socket through java, since we do not use IPv4 at all in this particular environment. I have tried sett

Re: [openjdk-x] Bind to a multicast address fails

Hi Alan,Chris, I imported the Andre's patch and our all existing internal tests are clean. Thanks, Vyom On Monday 10 September 2018 10:58 PM, Chris Hegarty wrote: On 10/09/18 15:35, Chris Hegarty wrote: ... Maybe the native implementation of these methods can be updated to accept a scope,

Re: RFR: 8189366: SocketInputStream.available() should check for eof

Hi All, Please provide your review comments on below fix. Thanks, Vyom On Friday 27 October 2017 11:31 AM, vyom tewari wrote: On Thursday 26 October 2017 03:14 PM, Bernd Eckenfels wrote: What is currently returned at the end of a stream? This looks like a dangerous thing to do, if a

Re: RFR: 8189366: SocketInputStream.available() should check for eof

Hi Chris, Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) where i included the test. Thanks, Vyom On Wednesday 10 October 2018 09:50 PM, Chris Hegarty wrote: Vyom, On 10/10/18 14:16, vyom tewari wrote: Hi All, Please

Re: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out

On Thursday 11 October 2018 02:15 PM, Chris Yin wrote: Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNot

Re: RFR: 8189366: SocketInputStream.available() should check for eof

s correct. While not intuitive, I don't propose that we change this. ( if this were a new implementation then I think it should throw IOE for this scenario, but we are where we are ). -Chris. best regards, -- daniel On 12/10/2018 09:55, Chris Hegarty wrote: On 12/10/18 08:29, Alan Batema

Re: RFR: 8189366: SocketInputStream.available() should check for eof

sure, i will send the webrev  soon. Vyom On Wednesday 17 October 2018 04:31 PM, Chris Hegarty wrote: On 12/10/18 12:58, Daniel Fuchs wrote: ... int available = impl.available(); return eof ? 0 : available; addresses the issue of available potentially returning garbage after EOF wh

RFR:8212114 Reconsider the affect on closed streams resulting from 8189366

Hi All, Please review the below fix. Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html bugId: https://bugs.openjdk.java.net/browse/JDK-8212114 this change the revert the effect of JDK-8189366,  restore the existing(SocketInputStream:available() will throw the socketExce

RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

Hi, Please review the below code change. Webrev: http://cr.openjdk.java.net/~vtewari/8046500/webrev0.0/index.html BugId:  https://bugs.openjdk.java.net/browse/JDK-8046500 This issue is specific to pure ipv6 environment, In pure ipv6 environment  if "enumInterface" fails,  i am clearing th

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

sites and we don't need to do any additional changes. Thanks, Vyom On 08/11/18 6:19 PM, Chris Hegarty wrote: Hi Vyom, On 08/11/18 09:22, vyom tewari wrote: Hi, Please review the below code change. Webrev: http://cr.openjdk.java.net/~vtewari/8046500/webrev0.0/index.html enumInterface

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

reseeding again,  looks like some problem with my email client. Vyom On 13/11/18 6:05 PM, vyom tewari wrote: Hi Chris, Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.1/index.html) where i incorporated your suggestion. Now i am returning

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

, vyom tewari wrote: Hi Chris, Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.1/index.html) where i incorporated your suggestion. Now i am returning the different error code(-2) if IP Helper Library function GetIfTable fails. I checked the all

RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

HttpsURLConnection, works with SunJSSE provider but does not work with other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as follows s = (SSLSocket)serverSocket; if (s instanceof SSLSocketImpl) { ((SSLSocketImpl)s).setHost(host); } But in case of oth

Re: RFR: 8252831: Correct "no comment" warnings in jdk.net module

On Tue, 2 Mar 2021 10:15:13 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changeset that fixes the "no comment" warnings > generated by `javadoc -Xdoclint` for `java.base/jdk.net`? > > Kind regards, > Patrick LGTM - Marked as reviewed by vtewari (Commit

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 12:43:27 GMT, Daniel Fuchs wrote: >> HttpsURLConnection, works with SunJSSE provider but does not work with other >> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as >> follows >> >> s = (SSLSocket)serverSocket; >>if (s instanceof SSLSocketImpl

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 15:03:47 GMT, Daniel Fuchs wrote: >> May be i am not sure, we may need this code change to review by security >> expert. I am setting "SNIHostName" only if "isDefaultHostnameVerifier" is >> true(If the HNV is the default from HttpsURLConnection) so there should not >> be pro

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 15:56:35 GMT, Daniel Fuchs wrote: >> i ran tests, it looks >> clean(https://github.com/vyommani/jdk/actions/runs/612949667) > > As far as I know this is only tier1 - so none of the network tests have been > run. I ran tier1 & tier2 tests locally on my linux vm, it was clear.

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Tue, 2 Mar 2021 20:17:25 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> used List.of instead of Collections.singletonList > > src/java.base/share/clas

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 04:38:47 GMT, Xue-Lei Andrew Fan wrote: > > HttpsURLConnection, works with SunJSSE provider but does not work with > > other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host > > name as follows > > s = (SSLSocket)serverSocket; > > if (s instanceof SSLSocket

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 05:01:13 GMT, Vyom Tewari wrote: >>> HttpsURLConnection, works with SunJSSE provider but does not work with >>> other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host >>> name as follows >>> >>> s =

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v3]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Wed, 3 Mar 2021 10:05:24 GMT, Daniel Fuchs wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> used List.of instead of Collections.singletonList > > src/java.base/share/clas

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Wed, 3 Mar 2021 11:36:19 GMT, Vyom Tewari wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line >> 454: >> >>> 452: s = (SSLSocket)factory.createSocket(serverSocket, >>> 453:

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v4]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 10:09:34 GMT, Daniel Fuchs wrote: > Vyom, can you provide, or point to a test that exercises the code paths that > have been changed? And also some new test that would fail before the fix and > pass after? > > best regards, > > -- daniel Hi Daniel, there are multiple test

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v5]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull requ

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v4]

On Wed, 3 Mar 2021 16:16:48 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reverted the overly deleted else block > > src/java.base/share/classes/sun/net/www/p

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v6]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 15:20:29 GMT, Vyom Tewari wrote: >> Vyom, can you provide, or point to a test that exercises the code paths that >> have been changed? And also some new test that would fail before the fix and >> pass after? >> >> best regards, >> >

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v5]

On Thu, 4 Mar 2021 00:27:52 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - resolve jcheck issue. >> - put if block which will prevent host being set twic

Integrated: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote: > HttpsURLConnection, works with SunJSSE provider but does not work with other > JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as > follows > > s = (SSLSocket)serverSocket; >if (s instan

Re: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v6]

On Fri, 5 Mar 2021 15:08:10 GMT, Michael McMahon wrote: >> Jayashree S Kumar has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Code Review: Incorporated Indention correction, added getIP and updated >> try-catch inside for loop > > Change

Re: RFR: 8263905: Remove finalize methods for SocketInput/OutputStream

On Mon, 22 Mar 2021 06:02:37 GMT, Kim Barrett wrote: > Please review this change to java.net.SocketInputStream and > java.net.SocketOutputStream, removing their "finalize" methods. These > methods are empty. Their purpose is to override and suppress the finalize > methods of their superclasses

Re: RFR: 8264824: java/net/Inet6Address/B6206527.java doesn't close ServerSocket properly [v2]

On Tue, 13 Apr 2021 10:30:18 GMT, Conor Cleary wrote: >> ### Description >> `Inet6Address/B6206527.java` test creates two instances of ServerSocket, >> both of which are explicity bound to a Link-Local address. Neither of the >> ServerSocket instances are explicitly closed meaning there is no g

Re: RFR: 8267938: (sctp) SCTP channel factory methods should check platform support

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty wrote: > The SCTP channel factory methods, namely SctpChannel::open, > SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw > UnsupportedOperationException, if the SCTP protocol is not supported. > Currently, underlying pla

Re: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"

On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs wrote: > Please find here a trivial fix for: > > 8269772: [macos-aarch64] test compilation failed with "SocketException: No > buffer space available" > > Running several of the websocket tests concurrently on some of the CI > machines is causing r

Re: RFR: 8269993: [Test]: java/net/httpclient/DigestEchoClientSSL.java contains redundant @run tags

On Wed, 7 Jul 2021 09:34:13 GMT, Thejasvi Voniadka wrote: > Hi, > > Please review this simple change to remove redundancy of @run tags. The test > "java/net/httpclient/DigestEchoClientSSL.java" contains a couple of redundant > @run tags: > > * @run main/othervm/timeout=300 > * DigestEchoCl

Re: RFR: 8263531: Remove unused buffer int

On Mon, 12 Jul 2021 20:39:53 GMT, Christoph Langer wrote: > The change for JDK-8257001 left an obsolete int field. Remove it. Marked as reviewed by vtewari (Committer). - PR: https://git.openjdk.java.net/jdk/pull/4759

Re: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString

On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates > `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear Looks good. - Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.n

Re: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check > if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to rea

Re: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

On Mon, 11 Oct 2021 09:42:12 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes (and CSR) to drop support for pre JDK > 1.4 `DatagramSocketImpl` implementations? > > These changes propose to drop support for `DatagramSocketImpls` that were > compiled with JDK 1.3

Re: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST [v4]

On Tue, 19 Oct 2021 13:48:24 GMT, Evan Whelan wrote: >> Hi, >> >> Please review my fix for JDK-8274779 which changes how HttpClient and >> HttpsClient checks for equality when comparing request methods. >> >> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` >> rather

Re: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations [v3]

On Thu, 21 Oct 2021 16:47:44 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my changes (and CSR) to drop support for pre JDK >> 1.4 `DatagramSocketImpl` implementations? >> >> These changes propose to drop support for `DatagramSocketImpls` that were >> compiled with J

Re: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v9]

On Wed, 10 Mar 2021 17:32:30 GMT, Jayashree S Kumar wrote: >> Issue >> >> https://bugs.openjdk.java.net/browse/JDK-8243376 >> >> Problem >> >> The scenario is: >> - Some specified target hostname resolves to two IP addresses (always the >> same address pair). >> - The DNS resolved order of

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

On Tue, 31 May 2022 18:29:30 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 (`#`). > > B

<    1   2