Moving to the nio-dev list.
Registration is not an atomic operation. The channel is registered (this
creates the selection key) and then the key's interest set is changed.
If I read your test case correctly, it is cancelling the key before the
key's interest set is changed and this leads to
On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated copyrights
>> Fixed cast style to add a space after cast, (where consistent with file
>> style)
>> Improved cod
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
On Tue, 10 May 2022 23:01:33 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
On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote:
> I did wonder why it has security-libs as the sub-category and if the intent
> was not what we see here.
I suspect the JBS issue was initially created to to look at the usages of
getProperty in the security code but it has been extended. The i
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote:
> JDK-6725221 Standardize obtaining boolean properties with defaults
src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) {
> 776: printSt
On Mon, 25 Apr 2022 17:40:13 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8285504
>
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
> a single code review, so it was decided to split into smaller chunks. This is
> one such chunk:
>
> open/
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in c
On Fri, 8 Apr 2022 07:52:55 GMT, KIRIYAMA Takuya wrote:
> I fixed sun.net.www.ParseUtil.decode().
>
> ParseUtil.decode() always tries to decode after parsing '%', so if '%' is
> located at the end of the String, IndexOutOfBoundsException is thrown. Also,
> if '%' is shown after decodable strin
On Fri, 11 Mar 2022 10:33:29 GMT, Alan Bateman wrote:
>> Another trivial cleanup to fix the last parameter of `GetStringXXXChars`
>> calls, should be a `jboolean*` instead of a `jboolean`.
>
> The changes to the usages in src/java.base look okay.
> Thanks, @AlanBateman @df
On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu wrote:
> Another trivial cleanup to fix the last parameter of `GetStringXXXChars`
> calls, should be a `jboolean*` instead of a `jboolean`.
The changes to the usages in src/java.base look okay.
-
Marked as reviewed by alanb (Reviewer).
On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy wrote:
>> Please review this small API enhancement to add the usual constructors
>> taking a cause to SocketException and then update uses of initiCause on
>> creating SocketException to instead pass the cause via the constructor.
>>
>> Please also re
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking
> a cause to SocketException and then update uses of initiCause on creating
> SocketException to instead pass the cause via the constructor.
>
> Please also review
On Sun, 27 Feb 2022 14:11:28 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psu
On 03/02/2022 00:07, Josh Long wrote:
hello,
I'm very interested in JEP 418: Internet-Address Resolution SPI, and I
was wondering: if I plugged in my own implementation via service
loader, would it be possible to obtain a reference to the default
implementation (the one that my implementation
On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote:
> I added socket connection check same as IPv6_supported().
> Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4
> uninstall`), and set property `-Djava.net.preferIPv4Stack=true`,
> java.net.InetAddress.PLATFORM_LOOKUP_P
On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote:
> with IP "0.0.0.0"
>
> - it either does nothing and ping fails, or, in some virtual environments
> is treated as the default route address.
> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
> as a vaild psuedo IP
On Tue, 25 Jan 2022 21:01:42 GMT, Florent Guillaume
wrote:
> In theory a subclass overloading using a non-synchronized `openConnection(URL
> u, Proxy p)` could have relied on `openConnection(URL u)` delegating to it
> and having been synchronized. So maybe this requires a small CSR?
The chang
On Fri, 21 Jan 2022 14:38:08 GMT, Julia Boes wrote:
> This change adds the classpath exception to the copyright header of the files
> in question. As source files, they should have both the GPL and the classpath
> exception.
P1–P5 doc bugs are okay to integrate in JDK 18 RDP2, I think fixes co
On Tue, 7 Dec 2021 12:29:09 GMT, Alan Bateman wrote:
> JDK-8278270 introduces a small regression. If a ServerSocket is closed while
> another thread is blocked in the accept method then the other thread may
> observe isClosed returning false, i.e. code may catch IOException
JDK-8278270 introduces a small regression. If a ServerSocket is closed while
another thread is blocked in the accept method then the other thread may
observe isClosed returning false, i.e. code may catch IOException and check
isClosed before the "closed" flag gets to true.
I've changed the clos
On Sun, 5 Dec 2021 16:44:05 GMT, Alan Bateman wrote:
> There are several thread safety issues in java.net.ServerSocket, issues that
> go back to at least JDK 1.4.
>
> The issue of most concern is async close of a ServerSocket that is initially
> created unbound and where clos
On Fri, 12 Nov 2021 19:11:36 GMT, Andrey Turbanov wrote:
> All this manually written code actually can be replaced with single
> String.isBlank() call.
> `file` variable is guaranteed to be non-null.
src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java line 125:
> 123:
On Mon, 15 Nov 2021 13:20:30 GMT, Daniel Fuchs wrote:
>> I propose to replace usages of !Optional.isPresent() with Optional.isEmpty
>> method.
>> It's makes code a bit easier to read.
>
> LGTM
I suspect @dfuch will sponsor this once he's had a chance to run the tests.
-
PR: https:
On Wed, 6 Oct 2021 20:37:29 GMT, Andrey Turbanov wrote:
>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8274809: Update java.base classes to use try-with-res
On Mon, 6 Dec 2021 15:55:52 GMT, Aleksei Efimov wrote:
> The following fix clarifies spec for
> `InetAddressResolverProvider.get(Configuration)` method to state that an
> error or exception thrown by this method will be propagated to to the caller
> of the method that triggered the lookup oper
On Mon, 6 Dec 2021 13:39:11 GMT, Florian Weimer wrote:
> To what extent is `ServerSocket` required to be thread-safe? I don't think
> it's part of the specification.
A ServerSocket is required by the spec to be asynchronously closable, that is
the motivation for the changes here.
java.net.Soc
On Mon, 6 Dec 2021 11:28:16 GMT, Aleksey Shipilev wrote:
>> There are several thread safety issues in java.net.ServerSocket, issues that
>> go back to at least JDK 1.4.
>>
>> The issue of most concern is async close of a ServerSocket that is initially
>> created unbound and where close may be
On Mon, 6 Dec 2021 11:30:12 GMT, Aleksey Shipilev wrote:
>> There are several thread safety issues in java.net.ServerSocket, issues that
>> go back to at least JDK 1.4.
>>
>> The issue of most concern is async close of a ServerSocket that is initially
>> created unbound and where close may be
On Mon, 6 Dec 2021 11:29:20 GMT, Aleksey Shipilev wrote:
>> There are several thread safety issues in java.net.ServerSocket, issues that
>> go back to at least JDK 1.4.
>>
>> The issue of most concern is async close of a ServerSocket that is initially
>> created unbound and where close may be
There are several thread safety issues in java.net.ServerSocket, issues that go
back to at least JDK 1.4.
The issue of most concern is async close of a ServerSocket that is initially
created unbound and where close may be called at or around the time the
underlying SocketImpl is created or the
On Fri, 3 Dec 2021 20:26:46 GMT, Ivan Šipka wrote:
>> Adding test group for IPv6 exclusive testing.
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added comment for adding the ipv6_only testgroup
This looks okay to me.
--
Vote: yes
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API spec
On Mon, 15 Nov 2021 13:26:30 GMT, Jaikiran Pai wrote:
> Hello Daniel, The issue is still reproducible (only) if the jar indexing is
> enabled by setting the `-Djdk.net.URLClassPath.enableJarIndex=true`
Just to add to Daniel's comment. JAR indexing has several issues, most going
back 20+ years.
On 09/11/2021 08:03, pierre.vi...@postfinance.ch wrote:
Hi
I have some questions about the com.sun.net.httpserver.HttpServer
provided in the openjdk: is it the correct mailing list for
discussions about it ? I have searched a bit but found no other
appropriate list.
Yes, this is the righ
On Thu, 4 Nov 2021 17:09:16 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by net libs. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they are
On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote:
> In comments, I think the 'synchronized static 'reads better, the conventional
> order is for the code.
I think Roger is right and maybe the change to the javadoc could be dropped
from this patch.
-
PR: https://git.openjdk.java
On 29/10/2021 14:44, Richard Gibson wrote:
The OCI DNS team are fielding an increasing amount of usage by
customers relying upon Java, and the lack of detail associated with
java.net.UnknownHostException for differentiating e.g. timeout vs.
NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost
On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change InetAddressResolver method names
>
> src/java.b
On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeliński wrote:
>> Per Java documentation,
>> "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30)
>> [..] indicates serious problems that a reasonable application should not
>> try to catch". Failure
On Tue, 19 Oct 2021 07:53:47 GMT, Daniel Jeliński wrote:
>> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 123:
>>
>>> 121: // not an error
>>> 122: *adapters = NULL;
>>> 123: return ERROR_SUCCESS;
>>
>> Mapping ERROR_NO_DATA to
On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeliński wrote:
>> Per Java documentation,
>> "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30)
>> [..] indicates serious problems that a reasonable application should not
>> try to catch". Failure
On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeliński wrote:
>> Per Java documentation,
>> "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30)
>> [..] indicates serious problems that a reasonable application should not
>> try to catch". Failure
On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman wrote:
>> It’s a good idea to ask the Microsoft folks about that, but I don't know the
>> way to ask. Could you tell me how to do it?
>>
>> As you say, CreateFile function is used in other parts of the JDK, but it
&g
On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote:
> * `InetAddressResolverProvider.Configuration` interface API might evolve,
> e.g. there might be a need to pass additional configuration items.
> * local hostname is a dynamic information, therefore it cannot be passed as
> string paramet
On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeliński wrote:
> Per Java documentation,
> "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30)
> [..] indicates serious problems that a reasonable application should not try
> to catch". Failure to
On Fri, 15 Oct 2021 11:22:23 GMT, Daniel Fuchs wrote:
> It happens occasionally, as evidenced by JDK-8217298, JDK-8046500 (fixed),
> JDK-8165665, JDK-8066931, JDK-8057900, JDK-8065559(closed), JDK-8040229,
> JDK-8065078(fixed), JDK-8068597(fixed), numerous reports on Google (search
> for "erro
On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeliński wrote:
> Per Java documentation,
> "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30)
> [..] indicates serious problems that a reasonable application should not try
> to catch". Failure to
On Tue, 12 Oct 2021 15:41:30 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
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
On Tue, 5 Oct 2021 18:55:09 GMT, Joe Darcy wrote:
> Augmentations to javac's Xlint:serial checking are out for review (#5709) and
> the sun.net classes in this PR would need some changes to pass under the
> expanded checks.
>
> The changes are to suppress warnings where non-transient fields in
On Wed, 29 Sep 2021 15:41:06 GMT, Aleksei Efimov wrote:
> The following fix proposes to remove usages of `"impl.prefix"` JDK system
> property from the `java.net.InetAddress` class.
> This system property is used to locate concrete implementations of the
> package private "java.net.InetAddress
On Wed, 29 Sep 2021 15:05:21 GMT, Aleksey Shipilev wrote:
> Ok, thanks. @AlanBateman, want to ack?
I don't have anything to add except to say that close and async close
implementations in the SCTP classes needs to be re-written and brought into
line with the implementation in NIO. Also I'm not
On Mon, 27 Sep 2021 07:40:26 GMT, Masanori Yano wrote:
> It’s a good idea to ask the Microsoft folks about that, but I don't know the
> way to ask. Could you tell me how to do it?
>
> As you say, CreateFile function is used in other parts of the JDK, but it
> have a significant impact to fix a
On Fri, 17 Sep 2021 08:46:52 GMT, Masanori Yano wrote:
> Thank you for your comment. According to Microsoft KB316609, CreateFile()
> should be tried again a short time later. I think JarURLConnection should
> also be retried when antivirus software holds some files.
> https://www.betaarchive.co
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote:
> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short
> time, so CreateFile() should be retried.
This will need discussion as to whether the JDK should put in retry
On 03/09/2021 22:38, mark.reinh...@oracle.com wrote:
A suggestion, if I may ...
Consider using the term “resolver” instead of “name service,” especially
in the names of the SPI classes and interfaces.
That would avoid confusing the service of looking up names and addresses
with the service of p
On Fri, 27 Aug 2021 08:37:46 GMT, Masanori Yano wrote:
> Please review this change to the Unix implementations of
> sun.nio.ch.sctp.Sctp*ChannelImpl#implCloseSelectableChannel()
> to be same as SocketChannelImpl at JDK-7118373. (The preClose is missing a
> check for the ST_KILLED state.)
As t
On Fri, 27 Aug 2021 23:14:58 GMT, Naoto Sato wrote:
>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
>> the changes is `Charset.defaultCharset()` returning `UTF-8` and
>> `file.encoding` system property being added in the spec, but another notable
>> modification i
Vote: yes
On 24/08/2021 04:09, Jaikiran Pai wrote:
Do you connections to the Apache HTTP client library and the retry
code that is looking for specific exceptions? From a distance it
seems very fragile and depending on very implementation specific
behavior. I wonder if it has ever been tested on W
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20
On 21/08/2021 12:40, Jaikiran Pai wrote:
I was able to reproduce this on a MacOS. However, the continuous
integration setup project for Quarkus projects runs these tests
against Linux and Windows setups and they have run into this issue at
least on the Linux OS jobs (I will need to go and check
On 21/08/2021 08:17, Jaikiran Pai wrote:
JEP-353[1] which got implemented and released in JDK13, states:
"The java.net package defines many sub-classes of SocketException. The
new implementation will attempt to throw the same specific
SocketException as the old implementation but there may be
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
Marked as reviewed by alanb (Reviewer).
---
On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote:
> Yes, while I don't know exactly which changes resolved JDK-6764325, it's
> clear from the microbenchmarks added for #2102 that it's no longer an issue -
> at least not in the mainline.
Thanks for checking and for closing that issue.
--
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("U
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("U
On Tue, 27 Jul 2021 08:09:13 GMT, Aleksey Shipilev wrote:
> But this rabbit hole excursion makes me think it would be better to just use
> the local loopback in these tests.
The test already attempts to connect to a server on the loopback address with
setup that leads to the "no suitable proxy
On Wed, 21 Jul 2021 17:34:15 GMT, Naoto Sato wrote:
>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
>> the changes is `Charset.defaultCharset()` returning `UTF-8` and
>> `file.encoding` system property being added in the spec, but another notable
>> modification i
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 pull request incrementally with
On Thu, 1 Jul 2021 18:09:39 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 pull request incrementally with
On 01/07/2021 16:47, Brian Burkhalter wrote:
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 a
On Tue, 29 Jun 2021 16:06:52 GMT, Brian Burkhalter wrote:
>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 643:
>>
>>> 641: if (state == ChannelState.UNINITIALIZED) {
>>> 642: SctpNet.close(fdVal);
>>> 643: state = ChannelState.KI
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`.
src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 6
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote:
>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>>
>> Sometimes I introduce new methods. Please feel free to suggest method names
>> you like to use.
>
> Weijun Wang has updated the pull request incrementally with o
On Fri, 25 Jun 2021 11:48:52 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my changes for the removal of the legacy
>> `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>>
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy
>> `PlainSoc
On Fri, 25 Jun 2021 10:25:52 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my changes for the removal of the legacy
>> `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>>
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy
>> `PlainSoc
On Thu, 24 Jun 2021 11:39:02 GMT, Patrick Concannon
wrote:
> I've created an issue to track this:
> https://bugs.openjdk.java.net/browse/JDK-8269288
Thanks. So are you keeping the Objects.requireNonNull here? If so then it
should probably be the 2-arg version so that the message is clear that
On Wed, 23 Jun 2021 15:01:45 GMT, Daniel Fuchs wrote:
>> This is probably a case where the spec needs say that an error (maybe an
>> unspecified error) is thrown if the custom factory's
>> createDatagramSocketImpl returns null. We can create a separate issue for
>> that as it's probably existe
On Wed, 23 Jun 2021 14:19:59 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/DatagramSocket.java line 1405:
>>
>>> 1403: // create legacy DatagramSocket delegate
>>> 1404: DatagramSocketImpl impl =
>>> factory.createDatagramSocketImpl();
>>> 1405
On Wed, 23 Jun 2021 12:06:41 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my changes for the removal of the legacy
> `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>
> In JDK 13, JEP 353 provided a drop in replacement for the legacy
> `PlainSocketImpl
On Wed, 23 Jun 2021 12:06:41 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my changes for the removal of the legacy
> `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>
> In JDK 13, JEP 353 provided a drop in replacement for the legacy
> `PlainSocketImpl
On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote:
>>> I thought about that but not sure of performance impact. Is the worst
>>> problem that more than one warnings will be printed for a single caller?
>>> It's not really harmless.
>>>
>>> As for the frame, if the warning message only contain
On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote:
> I thought about that but not sure of performance impact. Is the worst problem
> that more than one warnings will be printed for a single caller? It's not
> really harmless.
>
> As for the frame, if the warning message only contain the calle
On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote:
> You might want to make your "WARNING" consistent with the VM's "Warning" so
> that OutputAnalyzer's logic to ignore warnings will automatically ignore
> these too.
The uppercase "WARNING" is intentional here, it was the same with illegal
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
Changes requested by alanb (Reviewer).
src/java.base/share/classes/java/lang/System.java line 331:
> 329:
> 330:
On Thu, 3 Jun 2021 10:12:03 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 switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull reques
On Wed, 2 Jun 2021 15:23:01 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 switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull reques
On Wed, 2 Jun 2021 17:52:34 GMT, Daniel Fuchs wrote:
>> Please find below a fix that will make
>> `java/net/DatagramSocket/DatagramSocketMulticasting.java` more resilient to
>> the rare case where addresses bound to a network interfaces are updated
>> while the test is running.
>>
>> Instead
On Wed, 2 Jun 2021 15:54:26 GMT, Daniel Fuchs wrote:
> Please find below a fix that will make
> `java/net/DatagramSocket/DatagramSocketMulticasting.java` more resilient to
> the rare case where addresses bound to a network interfaces are updated while
> the test is running.
>
> Instead of usi
On Tue, 1 Jun 2021 17:16:59 GMT, Patrick Concannon
wrote:
>> src/java.base/share/classes/java/nio/file/attribute/FileTime.java line 256:
>>
>>> 254: nanos = (int) Math.floorMod(value,
>>> NANOS_PER_SECOND);
>>> 255: }
>>> 256: default -> thro
On Tue, 1 Jun 2021 16:44:38 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 switch expressions?
>
> Kind regards,
> Patrick
src/java.base/share/classes/java/nio/file/attribute/Fil
On Tue, 1 Jun 2021 15:21:33 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/576161d15423f58281e384
On Mon, 31 May 2021 15:02:57 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
1 - 100 of 1542 matches
Mail list logo
