On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote:
>> This changes the timeout factor from 4 to 1. Most of the changes add
>> timeouts to individual test cases so that I am able to run them with a
>> timeout factor of 0.7 (some margin to the checked in factor of one)
>>
>> In addition to cha
On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote:
>> This changes the timeout factor from 4 to 1. Most of the changes add
>> timeouts to individual test cases so that I am able to run them with a
>> timeout factor of 0.7 (some margin to the checked in factor of one)
>>
>> In addition to cha
On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote:
> The whole idea of running with a timeout factor of `0.7` is to remove
> intermittent failures. (I had it close to 0.5 or maybe less to begin with
> until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on
> socket timeout
On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs wrote:
> Thank you. I have imported your PR locally and running some HTTP client tests
> in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` i
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote:
> This change tries to add timeout to individual testcases so that I am able to
> run them with a timeout factor of 1 in the future (JDK-8260555).
>
> The first commit changes the timeout factor to 0.7, so that I can run tests
> and test the
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote:
> This change tries to add timeout to individual testcases so that I am able to
> run them with a timeout factor of 1 in the future (JDK-8260555).
>
> The first commit changes the timeout factor to 0.7, so that I can run tests
> and test the
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 200 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Modify three RMI tests
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Change apiNote to d
On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Change apiNote t
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote:
>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>>
>>> 2428: @Deprecated(since="17", forRemoval=true)
>>> 2429: public void checkAccess() {
>>> 2430: throw new SecurityException();
>>
>> Though
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter wrote:
>> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded
>> by HttpURLConnection, which should have triggered the loading of libnet long
>> before it cares about NTLM.
>
> I would have to check. The failure I observe
On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter wrote:
>> Yes, there was an `UnsatisfiedLinkError` in the native method
>> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
>
>> [...] I'd expect that libnet would have been loaded before we reach
>> NTLMAuthentication.
>
> In the (as of no
On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs wrote:
>> @dfuch Would you please check whether the change at line 71 in the updated
>> version of `NTLMAuthentication` is the correct place for this load?
>
> hmm... I don't see any issue in adding the load call to `NTLMAut
On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter wrote:
>> Moved to `NTLMAuthentication` static initializer. 853d349
>
> @dfuch Would you please check whether the change at line 71 in the updated
> version of `NTLMAuthentication` is the correct place for this load?
hmm... I don't see any iss
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request inc
On Fri, 9 Aug 2024 15:09:08 GMT, Brian Burkhalter wrote:
>> OK, this test uses a private API to create an instance of Inet6AddressImpl;
>> This explain why in this test Inet6AddressImpl gets loaded before
>> InetAddress.
>>
>> var impl = new Inet6AddressImpl();
>>
>> It should nev
On Thu, 8 Aug 2024 21:23:58 GMT, Brian Burkhalter wrote:
>> Thanks for the suggestions. I will look into it.
>
> Without loading libnet in Inet6AddressImpl, the test
> java/net/InetAddress/NullCharInHostnameDriver.java fails with
> UnsatisfiedLinkError:
>
> java.lang.UnsatisfiedLinkError: 'jav
On Thu, 8 Aug 2024 16:21:30 GMT, Brian Burkhalter wrote:
>> I don't know - you added that code to Inet6AddressImpl - so presumably a
>> test was failing without that code?
>> Which test was that? It wasn't obvious to me that adding code to load the
>> "net" library would be required here.
>
> I
On Thu, 8 Aug 2024 16:09:55 GMT, Brian Burkhalter wrote:
>> It may be because we have no IPv4 only machine in the CI? It seems strange
>> that IPv6 is treated differently than IPv4 in that respect.
>
> How would you suggest testing this?
I don't know - you added that code to Inet6AddressImpl -
On Thu, 8 Aug 2024 14:32:25 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
>>
>>> 152: static {
>>> 153: jdk.internal.loader.BootLoader.loadLibrary("net");
>>> 154: }
>>
>> I am curious about this change - wouldn't it be need
On Wed, 7 Aug 2024 15:59:14 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request wit
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
>>
>>> 51: }
>>> 52:
>>> 53: @SuppressWarnings("this-escape")
>>
>> An alternative here could be to make the class final. AFAICS it's not
>> subclassed anywhere. If
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs wrote:
> Please review several fixes and improvements to the `this-escape` lint
> warning analyzer.
>
> The goal here is to apply some relatively simple logical fixes that improve
> the precision and accuracy of the analyzer, and capture the remai
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Thu, 9 Nov 2023 14:51:53 GMT, Alan Bateman wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> test update
>
> src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 221:
>
>> 219: * which case,
On Thu, 26 Oct 2023 19:38:55 GMT, Joe Darcy wrote:
>> Clarify the intention of tier 1 tests. I'll reflow the paragraph and
>> regenerate the HTML file once the wording is agreed upon.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Tue, 19 Sep 2023 20:51:41 GMT, Tim Prinzing wrote:
> The existing JFR tests TestSocketChannelEvents and TestSocketEvents in
> jdk.jfr.event.io verify the events are still emitted as expected.
Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?
-
PR Com
On Thu, 7 Sep 2023 21:50:17 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added stat
On Thu, 7 Sep 2023 21:54:44 GMT, Tim Prinzing wrote:
> No. I think it's a relic from the distant past though. I think the timeout
> field should be removed. It's not used on SocketChannel at all, and it
> doesn't seem useful on Socket.
Should we log an RFE to that effect?
-
PR Re
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote:
> The socket read/write JFR events currently use instrumentation of java.base
> code using templates in the jdk.jfr modules. This results in some java.base
> code residing in the jdk.jfr module which is undesirable.
>
> JDK19 added static su
On Fri, 14 Apr 2023 12:27:30 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
On Fri, 14 Apr 2023 12:09:48 GMT, Varada M wrote:
>> Hello Varada, so the Linux version uses `SO_PEERCRED` socket option and when
>> it fails, the error message says "get SO_PEERCRED failed". The AIX version
>> uses `SO_PEERID` and if it fails, the current proposed form in this PR will
>> repo
On Fri, 14 Apr 2023 07:59:49 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
On Fri, 14 Apr 2023 10:52:45 GMT, Varada M wrote:
>> src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 130:
>>
>>> 128:
>>> 129: if ((rv=getsockopt(fd, SOL_SOCKET, SO_PEERID, &cred_info, &len)) <
>>> 0) {
>>> 130: handleError(env, rv, "get failed");
>>
>> Is the double spa
On Fri, 14 Apr 2023 07:59:49 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
On Mon, 27 Mar 2023 14:31:14 GMT, Andrey Turbanov wrote:
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/action/GetPropertyAction.java#L104
>
> But it's not a deprecation of the method/class. It just suppression of the
> warning.
> `GetPropertyAction.privil
On Mon, 27 Mar 2023 14:16:12 GMT, Andrey Turbanov wrote:
>> As I can see it uses deprecated `SecurityManager`, but it's not deprecated
>> itself.
>> Do I miss something? Or javac generates warning even in such cases?
>
> As I can see it uses deprecated `SecurityManager`, but it's not deprecated
On Mon, 27 Mar 2023 09:26:03 GMT, Andrey Turbanov wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> clarify Linux
>
> src/java.base/unix/classes/java/lang/ProcessImpl.java line 97:
>
>> 95: * @throw Error if the
On Thu, 23 Mar 2023 13:56:52 GMT, Roger Riggs wrote:
>> Improvements to support OS specific customization for JDK internal use:
>> - To select values and code; allowing elimination of unused code and values
>> - Optionally evaluated by build processes, compilation, or archiving (i.e.
>> CDS)
>
On Thu, 23 Feb 2023 12:44:30 GMT, Daniel Jeliński wrote:
> I searched for other WinAPIs of interest;
> [GetIfStackTable](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getifstacktable)
> caught my attention.
> As far as I could see, the network interfaces are arranged
On Thu, 16 Feb 2023 20:22:17 GMT, Rich DiCroce wrote:
>> ok so here goes: your patch changes the order in which the interfaces are
>> returned; the original code returned them in order of increasing indexes,
>> the new code appears to sort interfaces by LUID.
>> The failing test uses the first
On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce wrote:
> Improves performance and correctness, as discussed on the net-dev mailing
> list.
Something between 80 and 100 is usually a good limit. We typically avoid to go
above that. So no hard limit at 80 but avoid having lines which are too long.
On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce wrote:
> Improves performance and correctness, as discussed on the net-dev mailing
> list.
FWIW - there is a perl script located in `make/scripts/normalizer.pl` that can
be run on modified sources to fix up whitespace and CRLF issues when jcheck
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increas
On Thu, 20 Oct 2022 10:28:55 GMT, Magnus Ihse Bursie wrote:
> In `libsctp`, there are a couple of `DISABLED_WARNINGS` that are no longer
> needed to build successfully. These should be removed.
If everything still builds then LGTM too.
-
Marked as reviewed by dfuchs (Reviewer).
P
On Thu, 29 Sep 2022 13:44:40 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/native/libfdlibm/e_asin.c line 102:
>>
>>> 100: } else
>>> 101: t = x*x;
>>> 102: p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5);
>>
>> should we add an opening brace
On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti
wrote:
> This fixes misleading indentations, which allows enabling the (currently
> disabled) `misleading-indentation` warning flag on two `.gmk` files.
src/java.base/share/native/libfdlibm/e_asin.c line 102:
> 100: } else
> 10
62 matches
Mail list logo
