Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias method

2020-10-28 Thread Thomas Fox
Hello, I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authenticat

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Igor Ignatyev
On Wed, 28 Oct 2020 18:07:28 GMT, Daniel Fuchs wrote: >> Igor Ignatyev has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - use UTC TZ for RFC3659_DATETIME_FORMAT >> - run TestFtpTimeValue with different user.timezone > > Marked as reviewe

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v2]

2020-10-28 Thread Igor Ignatyev
On Wed, 28 Oct 2020 12:52:41 GMT, Rahul Yadav wrote: >> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1770: >> >>> 1768: try { >>> 1769: var d = LocalDateTime.parse(s, RFC3659_DATETIME_FORMAT); >>> 1770: result = >>> Date.from(d.atZone(ZoneOffs

Integrated: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner

2020-10-28 Thread Igor Ignatyev
On Mon, 26 Oct 2020 16:51:25 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial fix? > > `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` > which are shared among all instances of `FtpClient`. the fact that > `SimpleDateFormat` isn

Integrated: 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java

2020-10-28 Thread Michael McMahon
On Wed, 28 Oct 2020 18:48:51 GMT, Michael McMahon wrote: > …nnelConnectionSetup.java UnixSocketChannelReadWrite.java This pull request has now been integrated. Changeset: 3f20612e Author:Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/3f20612e Stats: 3 lines in 3 fil

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

2020-10-28 Thread Brian Burkhalter
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: 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java

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

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

2020-10-28 Thread Michael McMahon
…nnelConnectionSetup.java UnixSocketChannelReadWrite.java - Commit messages: - 825: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java Changes: https://git.openjdk.java.net/jdk/pull/912/files Webrev: https://web

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Daniel Fuchs
On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small and trivial fix? >> >> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` >> which are shared among all instances of `FtpClient`. the fact that >> `SimpleDateForm

Integrated: 8245194: Unix domain socket channel implementation

2020-10-28 Thread Michael McMahon
On Mon, 7 Sep 2020 12:05:07 GMT, Michael McMahon wrote: > Continuing this review as a PR on github with the comments below > incorporated. I expect there will be a few more iterations before integrating. > > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote:

Re: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c

2020-10-28 Thread Mark Sheppard
On Tue, 27 Oct 2020 12:12:47 GMT, Michael McMahon wrote: >> A small improvement to avoid extra string copy. >> >> [Tests] >> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. > > LGTM In the original the copy would appear to be a way of enforcing t

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Rahul Yadav
On Wed, 28 Oct 2020 17:07:04 GMT, Chris Hegarty wrote: >> Igor Ignatyev has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - use UTC TZ for RFC3659_DATETIME_FORMAT >> - run TestFtpTimeValue with different user.timezone > > Marked as review

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Chris Hegarty
On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small and trivial fix? >> >> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` >> which are shared among all instances of `FtpClient`. the fact that >> `SimpleDateForm

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Rahul Yadav
On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small and trivial fix? >> >> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` >> which are shared among all instances of `FtpClient`. the fact that >> `SimpleDateForm

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v3]

2020-10-28 Thread Igor Ignatyev
> Hi all, > > could you please review this small and trivial fix? > > `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` > which are shared among all instances of `FtpClient`. the fact that > `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe

Re: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

2020-10-28 Thread Daniel Fuchs
On Thu, 22 Oct 2020 14:33:11 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean > up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ? > > This fix is set of formatting changes intended to clean up the javado

Re: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

2020-10-28 Thread Daniel Fuchs
On Wed, 28 Oct 2020 14:31:22 GMT, Daniel Fuchs wrote: >> Hi, >> >> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean >> up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ? >> >> This fix is set of formatting changes intended to clean up the javado

Re: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

2020-10-28 Thread Daniel Fuchs
On Thu, 22 Oct 2020 14:33:11 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean > up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ? > > This fix is set of formatting changes intended to clean up the javado

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v2]

2020-10-28 Thread Rahul Yadav
On Wed, 28 Oct 2020 11:10:33 GMT, Daniel Fuchs wrote: >> Igor Ignatyev has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - remove \n from MDTM response before parsing >> - added leading 0 to the test >> - use DateTimeFormatter instead

Integrated: 8255299: Drop explicit zeroing at instantiation of Atomic* objects

2020-10-28 Thread Сергей Цыпанов
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов wrote: > As discussed in https://github.com/openjdk/jdk/pull/510 there is never a > reason to explicitly instantiate any instance of `Atomic*` class with its > default value, i.e. `new AtomicInteger(0)` could be replaced with `new > AtomicInteg

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Daniel Fuchs
On Wed, 28 Oct 2020 08:56:05 GMT, Сергей Цыпанов wrote: >> FYI it is better to use merge, instead of rebase+force push. Rebase breaks >> history and all existed code comments. > > @mrserb thanks for pointing this out! Thanks for updating with latest master changes Sergey! My tests were all gre

Re: RFR: 8245194: Unix domain socket channel implementation [v35]

2020-10-28 Thread Michael McMahon
On Sat, 24 Oct 2020 08:12:57 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> - fixed 32 bit Linux build error >> - test updates from Chris > > src/java.base/windows/classes/sun/nio/ch/Windows

Re: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner [v2]

2020-10-28 Thread Daniel Fuchs
On Tue, 27 Oct 2020 18:54:30 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small and trivial fix? >> >> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` >> which are shared among all instances of `FtpClient`. the fact that >> `SimpleDateForm

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Сергей Цыпанов
On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov wrote: >> Rebased onto master to have the fix introduced in >> https://github.com/openjdk/jdk/pull/778 > > FYI it is better to use merge, instead of rebase+force push. Rebase breaks > history and all existed code comments. @mrserb thanks for po

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Sergey Bylokhov
On Wed, 28 Oct 2020 08:40:02 GMT, Сергей Цыпанов wrote: >> client changes are fine > > Rebased onto master to have the fix introduced in > https://github.com/openjdk/jdk/pull/778 FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Сергей Цыпанов
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a > reason to explicitly instantiate any instance of `Atomic*` class with its > default value, i.e. `new AtomicInteger(0)` could be replaced with `new > AtomicInteger()` which is faster: > @State(Scope.Thread) > @OutputTime

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

2020-10-28 Thread Сергей Цыпанов
On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race wrote: >> Сергей Цыпанов has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains one additional >> commit si