On 24/07/2020 18:42, Joe Darcy wrote:
At least from a few minutes thinking, I don't see a meaningful
compatibility issue in replacing
1) a public constructor in an abstract class
with
2) a protected constructor in an abstract class
It is source compatible, subclasses would have access t
Hi Alan,
On 7/24/2020 3:34 AM, Alan Bateman wrote:
On 24/07/2020 01:33, Joe Darcy wrote:
Hello,
Please review the replacement of default constructors in various
abstract classes in java.net with explicit constructors:
webrev: http://cr.openjdk.java.net/~darcy/8250244.0/
CSR: https:/
Daniel,
That's all fine. Concerning the test, I think the approach looks good,
but I wonder if instead of just synchronizing on the CFs to make
the cancel happen at the same time always, would it be useful to have a
test mode
where the cancel occurs after different lengths of time to try and ex
Thanks Alan, yes I'll need a sponsor for the patch.
I had David on our team open a JIRA for me:
https://bugs.openjdk.java.net/browse/JDK-8250521
I apologize in advance if we didn't fill-in something right,
I'm very new to the OpenJDK community.
Best,
Nikola
-Original Message-
From: Al
On 24/07/2020 01:33, Joe Darcy wrote:
Hello,
Please review the replacement of default constructors in various
abstract classes in java.net with explicit constructors:
webrev: http://cr.openjdk.java.net/~darcy/8250244.0/
CSR: https://bugs.openjdk.java.net/browse/JDK-8250245
(This is p
On 23/07/2020 14:06, Nikola Grcevski wrote:
That's a great idea Alan. If we are OK to merge this improvement with support
for 127.0.0.1 only,
I'll follow up with another patch for the full range of the loopback adapter
and some tests
for the macro in all 3 modes.
Yes, that approach is okay. Do
