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
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
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
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
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:
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:
>
>
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
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
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
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
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
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`,
>
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
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
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
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
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:
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
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
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.
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
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+
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
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
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
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
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
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
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".
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
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".
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".
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
>
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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:
>
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:
>
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
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
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
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
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 about
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 =
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
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
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
>>
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
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
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();
>>>
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
>
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
>
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
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
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
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
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
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 ->
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
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.
>>
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.
>>
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
On Wed, 26 May 2021 03:54:14 GMT, Jie Fu wrote:
> Hi all,
>
> java/net/SctpSanity.java fails on some of our test machines due to Protocol
> not supported.
> The reason is that the test fails to detect all the cases when a machine
> doesn't support SCTP.
>
> The fix just follows what are done
On Wed, 26 May 2021 14:51:00 GMT, Jie Fu wrote:
> How can I get to know if the socket(IPPROTO_SCTP) or
> setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing?
`strace -f` should help, or just add trace message. If socket(IPPROTO_SCTP) is
failing then it suggests to me that we are missing the check
1 - 100 of 1271 matches
Mail list logo
