Re: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Alan Bateman
On Sat, 22 May 2021 06:45:33 GMT, Alan Bateman wrote: >> yes, thanks for that ... updated as requested > > Thanks, and if you want to keep it consistent with the existing code then you > could rename "Socket newUdpSocket" and "biEx", or just change it to "return > new Socket(...)". BTW: Is on

Re: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Alan Bateman
On Fri, 21 May 2021 17:00:11 GMT, Mark Sheppard wrote: >> test/jdk/java/net/Socket/UdpSocket.java line 151: >> >>> 149: } >>> 150: } >>> 151: return newUdpSocket; >> >> I added this test in advance of JEP 353 as we didn't have much coverage for >> this deprecated co

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Maurizio Cimadamore
On Fri, 21 May 2021 14:22:47 GMT, Daniel Fuchs wrote: >> The usage of `LinkedList` is senseless and can be replaced with either >> `ArrayList` or `ArrayDeque` which are both more compact and effective. >> >> jdk:tier1 and jdk:tier2 are both ok > > I don't remember all the comments you have rece

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote: > I haven't seen any response to this comment I made a couple of days ago and I > suspect it got missed > > > Weijun Wang has updated the pull request incrementally with one additional > > commit since the last revision: > > fixing awt/datatra

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-21 Thread Phil Race
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3]

2021-05-21 Thread Weijun Wang
> The code change refactors classes that have a `SuppressWarnings("removal")` > annotation that covers more than 50KB of code. The big annotation is often > quite faraway from the actual deprecated API usage it is suppressing, and > with the annotation covering too big a portion it's easy to cal

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550: > >> 548: * @throws IOEx

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120: > >> 118:

Re: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v3]

2021-05-21 Thread Weijun Wang
> Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need > `-Djava.security.manager=allow` when launched. This PR covers such

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2]

2021-05-21 Thread Weijun Wang
On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adjust order of VM options > > test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3: > >> 1: /* >> 2: *

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2]

2021-05-21 Thread Phil Race
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote: >> Please review the test changes for [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming >> `disallow`, tests calling `System.setSecurityManager()` need >> `-Djav

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-21 Thread Phil Race
On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote: >> The JEP isn't PTT for 17 so there's plenty of time isn't there ? > > There are 827 files in this patch. Phil is right that adding SW at the class > level is introducing technical debt but if addressing that requires > refactoring and re-t

Re: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Daniel Fuchs
On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard wrote: > The test java/net/Socket/UdpSocket.java has been seen to fail with a > BindException, in the testMaxSockets test, on a regular basis on > macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP > Sockets that may be create

RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Mark Sheppard
The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It

Re: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Mark Sheppard
On Wed, 19 May 2021 05:56:07 GMT, Alan Bateman wrote: >> The test java/net/Socket/UdpSocket.java has been seen to fail with a >> BindException, in the testMaxSockets test, on a regular basis on >> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP >> Sockets that may be cre

Re: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

2021-05-21 Thread Alan Bateman
On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard wrote: > The test java/net/Socket/UdpSocket.java has been seen to fail with a > BindException, in the testMaxSockets test, on a regular basis on > macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP > Sockets that may be create

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Daniel Fuchs
On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` >> annotation that covers more than 50KB of code. The big annotation is often >> quite faraway from the actual deprecated API usage it is suppressing, and >> with

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-21 Thread Daniel Fuchs
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Thiago Henrique Hüpner
On Fri, 21 May 2021 15:00:15 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154: >> >>> 152: * @param fileName the key of the mapping >>> 153: */ >>> 154: public List get(String fileName) { >> >> IcedTea-Web seems to be using this

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Alan Bateman
On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique Hüpner wrote: > IcedTea-Web seems to be using this method reflectively: > https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80 I assume this doesn't work wit

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Thiago Henrique Hüpner
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов wrote: > The usage of `LinkedList` is senseless and can be replaced with either > `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok src/java.base/share/classes/jdk/internal/util/jar/J

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Daniel Fuchs
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов wrote: > The usage of `LinkedList` is senseless and can be replaced with either > `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok I don't remember all the comments you have received

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Alan Bateman
On Fri, 21 May 2021 13:13:04 GMT, Сергей Цыпанов wrote: > Hi guys, any more comments here? Please ping me if I've missed something I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments ne

Re: RFR: 8263561: Re-examine uses of LinkedList

2021-05-21 Thread Сергей Цыпанов
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов wrote: > The usage of `LinkedList` is senseless and can be replaced with either > `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok Hi guys, any more comments here? Please ping me if

Re: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2]

2021-05-21 Thread Weijun Wang
> The code change refactors classes that have a `SuppressWarnings("removal")` > annotation that covers more than 50KB of code. The big annotation is often > quite faraway from the actual deprecated API usage it is suppressing, and > with the annotation covering too big a portion it's easy to cal

Re: Accessing 'system' header fields implicitly added by HttpClient

2021-05-21 Thread Daniel Fuchs
Hi Moataz, This sounds like a reasonable request, with a concrete use case. I have logged https://bugs.openjdk.java.net/browse/JDK-8267510 best regards, -- daniel On 20/05/2021 15:58, Moataz Abdelnasser wrote: Hi! I've recently released an HTTP cache (https://mizosoft.github.io/methanol/cac