Re: RFR: 8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]

2020-11-17 Thread Matthias Baesken
On Tue, 17 Nov 2020 05:02:07 GMT, Christoph Langer wrote: >> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on >> AIX. >> >> It tests that when a DNS server is unreachable it fails quickly with a >> PortUnreachableException due to ICMP Destination Unreachable packets

RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile

2021-02-05 Thread Matthias Baesken
Hello, Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. See also the Sonar check result : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=

Re: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile [v2]

2021-02-09 Thread Matthias Baesken
mp;languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this &

Re: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile [v2]

2021-02-09 Thread Matthias Baesken
On Mon, 8 Feb 2021 16:41:44 GMT, Claes Redestad wrote: >> Seems you're right. My search for "isClassPathAttributePresent" also didn't >> yield anything. So why not remove it altogether...? > > Removing it sounds good. hi, I removed isClassPathAttributePresent . - PR: https://git.o

Integrated: JDK-8261237: remove isClassPathAttributePresent method

2021-02-09 Thread Matthias Baesken
On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a > related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://son

Re: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage

2021-02-09 Thread Matthias Baesken
On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in > jdk/internal/util/Preconditions.java outOfBoundsMessage The method outOfBoundsMessage has a few problematic calls to String.format. Those calls use "%d" however t

RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage

2021-02-09 Thread Matthias Baesken
JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage - Commit messages: - JDK-8261422 Changes: https://git.openjdk.java.net/jdk/pull/2483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2483&range=00 Issue: ht

Re: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage

2021-02-09 Thread Matthias Baesken
On Tue, 9 Feb 2021 15:38:29 GMT, Alan Bateman wrote: >> JDK-8261422: Adjust problematic String.format calls in >> jdk/internal/util/Preconditions.java outOfBoundsMessage > > src/java.base/share/classes/jdk/internal/util/Preconditions.java line 212: > >> 210:

Integrated: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage

2021-02-16 Thread Matthias Baesken
On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in > jdk/internal/util/Preconditions.java outOfBoundsMessage This pull request has now been integrated. Changeset: 219b115e Author:Matthias Baesken URL:

RFR: JDK-8262199: TOCTOU in jli args.c

2021-02-23 Thread Matthias Baesken
Sonar reports a finding in args.c, where a file check is done . Stat performs a check on file, and later fopen is called on the file : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CL0BBG2CXpcnhtM&resolved=false&types=VULNERABILITY The coding could be slightly rewritte

Re: RFR: JDK-8262199: TOCTOU in jli args.c

2021-02-23 Thread Matthias Baesken
On Tue, 23 Feb 2021 14:05:15 GMT, Christoph Langer wrote: > This looks good in general. Do you know whether there's a jtreg test that > stresses arg files? There are tests dealing with args files at test/jdk/tools/launcher/ , e.g. there is test/jdk/tools/launcher/ArgsFileTest.java . Best r

Re: RFR: JDK-8262199: TOCTOU in jli args.c [v2]

2021-02-23 Thread Matthias Baesken
> > The coding could be slightly rewritten so that the potential TOCTOU is > removed (however I do not think that it is such a big issue). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Small changes

Re: RFR: JDK-8262199: issue in jli args.c [v2]

2021-02-25 Thread Matthias Baesken
On Tue, 23 Feb 2021 19:24:31 GMT, Alan Bateman wrote: > This function is "optionally report, optionally fclose, and then exit". Have > you tried reducing it to reportAndExit and fclose inline in expandArgFile to > avoid it doing 3 things? hi Alan , thanks for your remark , I did not do that

Re: RFR: JDK-8262199: issue in jli args.c [v3]

2021-02-25 Thread Matthias Baesken
> Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed > (however I do not think that it is such a big issue). M

Re: RFR: JDK-8262199: issue in jli args.c [v4]

2021-02-25 Thread Matthias Baesken
> Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed > (however I do not think that it is such a big issue). M

Re: RFR: JDK-8262199: issue in jli args.c [v3]

2021-02-25 Thread Matthias Baesken
On Thu, 25 Feb 2021 16:07:36 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove fclose before exit > > src/java.base/share/native/libjli/args.c l

Re: RFR: JDK-8262199: issue in jli args.c [v5]

2021-02-26 Thread Matthias Baesken
> Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed > (however I do not think that it is such a big issue). M

Re: RFR: JDK-8262199: issue in jli args.c [v3]

2021-02-26 Thread Matthias Baesken
On Thu, 25 Feb 2021 17:46:42 GMT, Christoph Langer wrote: >> I think that did not work because it does not fit the param types of >> reportAndExit but I can simplify it otherwise. > > Ah, I see. > Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice > now, wouldn't it be le

Integrated: JDK-8262199: issue in jli args.c

2021-02-26 Thread Matthias Baesken
On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed >

RFR: JDK-8266918: merge_stack in check_code.c add NULL check

2021-05-11 Thread Matthias Baesken
Hello, please review this small Sonar finding. Sonar reports a potential NULL pointer dereference here : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG "Access to field 'item' results in a dereference of a null po

Re: RFR: JDK-8266918: merge_stack in check_code.c add NULL check [v2]

2021-06-04 Thread Matthias Baesken
ld 'item' results in a dereference of a null pointer (loaded > from variable 'new')" > It would be better to add a check . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Replace check by assertio

Integrated: JDK-8266918: merge_stack in check_code.c add NULL check

2021-06-08 Thread Matthias Baesken
On Tue, 11 May 2021 14:49:42 GMT, Matthias Baesken wrote: > Hello, please review this small Sonar finding. > Sonar reports a potential NULL pointer dereference here : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=f

RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups

2021-06-17 Thread Matthias Baesken
Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-06-23 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-06-23 Thread Matthias Baesken
On Wed, 23 Jun 2021 13:37:59 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset",

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-06-24 Thread Matthias Baesken
On Wed, 23 Jun 2021 14:48:22 GMT, Severin Gehwolf wrote: > > But I think that the testing needs to be enhanced (e.g. with some added > > docker tests?). Do you have some good suggestions > > where I could look at existing (docker?) tests and adjust those for the new > > pids.max ? > > Have a l

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v3]

2021-07-09 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-07-09 Thread Matthias Baesken
On Tue, 29 Jun 2021 08:21:51 GMT, Severin Gehwolf wrote: > This looks pretty good now. Looking forward to seeing container tests for > this new code. Hi Severin , I did some adjustments following your suggestions. I added docker based test coding for testing pids-limit (with limits and also wi

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-07-09 Thread Matthias Baesken
On Fri, 9 Jul 2021 13:42:15 GMT, Severin Gehwolf wrote: > OK. Please also add a test on the hotspot side. You may want to add relevant > parts to `TestMisc.java`. Thanks for the suggestion, I will look into TestMisc.java . - PR: https://git.openjdk.java.net/jdk/pull/4518

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v4]

2021-07-15 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-07-15 Thread Matthias Baesken
On Fri, 9 Jul 2021 13:53:27 GMT, Matthias Baesken wrote: > > OK. Please also add a test on the hotspot side. You may want to add > > relevant parts to `TestMisc.java`. > > Thanks for the suggestion, I will look into TestMisc.java . I added some HS testing code in the la

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v5]

2021-07-15 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v5]

2021-07-22 Thread Matthias Baesken
On Fri, 16 Jul 2021 06:14:07 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset",

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-22 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-22 Thread Matthias Baesken
On Thu, 22 Jul 2021 12:18:20 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset",

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-23 Thread Matthias Baesken
On Fri, 23 Jul 2021 08:39:37 GMT, Severin Gehwolf wrote: > > No, I don't know what to do about it. All I can see it comes back with a pids > limit of `38019` when set to `-1`. It does seem like a bug or an intentional > setting so as to avoid fork bombs. Very strange indeed, I have docker 20.

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-27 Thread Matthias Baesken
On Fri, 23 Jul 2021 12:32:04 GMT, Severin Gehwolf wrote: > > Could this be some setting configured on your box that is picked up as an > > additional limit ? > > Possibly. Not sure where to look, though. I ask some local experts about that issue. What do you think about accepting, when setting

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v7]

2021-08-05 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-08-05 Thread Matthias Baesken
On Mon, 2 Aug 2021 11:42:33 GMT, Severin Gehwolf wrote: > > What do you think about accepting, when setting -1/unlimited, a high limit > > number like 20.000+ as well (and and a comment that on some setups > > unlimited means just "high number" but not unlimited? > > This seems most reasonable

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8]

2021-08-05 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8]

2021-08-06 Thread Matthias Baesken
On Fri, 6 Aug 2021 08:29:50 GMT, Severin Gehwolf wrote: > This looks good to me now and passes tests on my cgroup v1 and cgroup v2 > setups. Thanks for the review and approval . Best regards, Matthias - PR: https://git.openjdk.java.net/jdk/pull/4518

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v9]

2021-08-09 Thread Matthias Baesken
LES 12.1, RHEL 7.1) the pids > controller might not be there (or not fully supported) so it was added as > optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); &g

Integrated: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups

2021-08-10 Thread Matthias Baesken
On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote: > Hello, please review this PR; it extend the OSContainer API in order to also > support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuac

RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022

2021-09-01 Thread Matthias Baesken
Hello, please review this small change. The OS detection code of the JDK/JVM should recognize the new Windows server 2022 : https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info The build nu

Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]

2021-09-02 Thread Matthias Baesken
erver-release-info > > The build number of Windows server 2022 according to the documentation in the > second link is 20348 . > Thanks, Matthias Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust comments

Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]

2021-09-02 Thread Matthias Baesken
On Thu, 2 Sep 2021 07:49:55 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Adjust comments > > src/hotspot/os/windows/os_windows.cpp line 1871: > >

Integrated: JDK-8273229: Update OS detection code to recognize Windows Server 2022

2021-09-02 Thread Matthias Baesken
On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 > https://doc

RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current

2021-09-09 Thread Matthias Baesken
https://bugs.openjdk.java.net/browse/JDK-8266490 extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490. There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.h

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current

2021-09-10 Thread Matthias Baesken
On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of > cgroups. However only pids.max output was added with 8266490. > There is a second parameter

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2]

2021-09-10 Thread Matthias Baesken
est/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3]

2021-09-14 Thread Matthias Baesken
est/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2]

2021-09-14 Thread Matthias Baesken
On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of >> cgroups. However only pids.max output was added with 8266490. >> The

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3]

2021-09-15 Thread Matthias Baesken
On Tue, 14 Sep 2021 18:23:49 GMT, Severin Gehwolf wrote: >> Oh, I misunderstood the test. "no_value_expected" was passed in from >> `testPids()` in this file, but that's confusing because you are expecting an >> integer value. Maybe it should be "any_integer"? > >> Maybe it should be "any_integ

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v4]

2021-09-15 Thread Matthias Baesken
est/admin-guide/cgroup-v2.html#pid > that would be helpful too and can be added to the OSContainer API . > pids.current : > A read-only single value file which exists on all cgroups. > The number of processes currently in the cgroup and its descendants. > > Best regards, Matthias

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2]

2021-09-15 Thread Matthias Baesken
On Fri, 10 Sep 2021 12:36:35 GMT, Severin Gehwolf wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Some simplifications and test adjustment suggested by Severin > > test/h

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3]

2021-09-15 Thread Matthias Baesken
On Wed, 15 Sep 2021 07:09:54 GMT, Matthias Baesken wrote: >>> Maybe it should be "any_integer"? >> >> +1 > >> Is "no_value_expected" generated by Docker? I searched the entire HotSpot >> source code and couldn't find it. I also

Integrated: JDK-8273526: Extend the OSContainer API pids controller with pids.current

2021-09-16 Thread Matthias Baesken
On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of > cgroups. However only pids.max output was added with 8266490. > There is a second parameter

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Matthias Baesken
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` > expects for the "unlimited" option of `--pids-limit` to be `0` whereas > `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk cont

RFR: JDK-8274840: Update OS detection code to recognize Windows 11

2021-10-07 Thread Matthias Baesken
The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information OS build number is : 22000.194 for 21H2 (original release) Please review the following small patch ! (patch comes ori

Integrated: JDK-8274840: Update OS detection code to recognize Windows 11

2021-10-07 Thread Matthias Baesken
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For > details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for

Re: RFR: JDK-8274840: Update OS detection code to recognize Windows 11

2021-10-07 Thread Matthias Baesken
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For > details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for

RFR: JDK-8280157: wrong texts Falied in a couple of tests

2022-01-19 Thread Matthias Baesken
Very small change fixing wrong strings "Falied" in a couple of tests. - Commit messages: - JDK-8280157 Changes: https://git.openjdk.java.net/jdk/pull/7142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-828

Integrated: JDK-8280157: wrong texts Falied in a couple of tests

2022-01-19 Thread Matthias Baesken
On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote: > Very small change fixing wrong strings "Falied" in a couple of tests. This pull request has now been integrated. Changeset: 8931c122 Author:Matthias Baesken URL: https://git.openjdk.java.n

RFR: JDK-8280373: adjust other SystemIDResolver.java after 8270492

2022-01-20 Thread Matthias Baesken
After 8270492 https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/c

Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v2]

2022-01-25 Thread Matthias Baesken
70492 to > src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add header - Changes: - all: https://git.openjdk.java.net/jdk/pull/

Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492

2022-01-25 Thread Matthias Baesken
On Thu, 20 Jan 2022 23:32:33 GMT, Joe Wang wrote: > Thanks Alan for the reminder. The change looks good. Please add a copyright > header and the LastModified tag as the other class did. Hi, I added the header and LastModified. Best regards, Matthias - PR: https://git.openjdk.java.

Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3]

2022-01-25 Thread Matthias Baesken
70492 to > src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add LastModified - Changes: - all: https://git.openjdk.java.net/j

Integrated: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492

2022-01-26 Thread Matthias Baesken
On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDR

RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-27 Thread Matthias Baesken
Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_w

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-28 Thread Matthias Baesken
On Wed, 27 Apr 2022 15:10:51 GMT, Alan Bateman wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winpro

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-28 Thread Matthias Baesken
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used > to target a minimum Windows version we want to support. See also for more > detailled information : > https://docs.microsoft.com/en-us/w

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings

2022-04-29 Thread Matthias Baesken
On Fri, 29 Apr 2022 05:09:35 GMT, David Holmes wrote: > That only seems to be half of the issue though. If we are defining > _WIN32_WINNT=0x0601 because the minimum required OS API support level is > Windows 7, then don't we need a check that the build platform is also at > least Windows 7? H

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2]

2022-05-03 Thread Matthias Baesken
ops_md.c > (so targeting older Windows versions at other places is most likely not > useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4 - Changes:

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]

2022-05-03 Thread Matthias Baesken
ops_md.c > (so targeting older Windows versions at other places is most likely not > useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in wepoll.c - Changes: - all: https://

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]

2022-05-03 Thread Matthias Baesken
On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote: >> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I >> missed that wepoll.c is 3rd party code as well). > > I assume you can revert the update to the copyright header in the latest > version as there aren't any chan

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]

2022-05-04 Thread Matthias Baesken
On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]

2022-05-04 Thread Matthias Baesken
On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote: > I agree with Erik - the source locations need to be modified to not define > it. If we want to keep a record perhaps add an assertion that the value is > what was expected? > > I still feel we have a disconnect between this and an actual c

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-04 Thread Matthias Baesken
ops_md.c > (so targeting older Windows versions at other places is most likely not > useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust API level to Windows 8 for security.cpp and do some cleanup --

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-04 Thread Matthias Baesken
On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote: > I'm confused. > `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set > _WIN32_WINNT so how is that later API being enabled? Does this mean that not > setting _WIN32_WINNT means :any API is allowed" ? I found this i

RFR: JDK-8286114: [test] show real exception in bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java

2022-05-04 Thread Matthias Baesken
There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved. - Commit messages: - JDK-8286114 Changes: https://git.openjdk.java.net/jdk/pull/8533/files Webrev: https://webrevs.openjdk.

RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux

2022-05-04 Thread Matthias Baesken
A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . Looks like this

Re: RFR: JDK-8286114: [test] show real exception in bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java

2022-05-04 Thread Matthias Baesken
On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken wrote: > There is one TestLibrary.bomb call in > sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the > exception to bomb, that should be improved. Hi Roger and Martin, thanks for the reviews ! -

Integrated: JDK-8286114: [test] show real exception in bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java

2022-05-04 Thread Matthias Baesken
On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken wrote: > There is one TestLibrary.bomb call in > sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the > exception to bomb, that should be improved. This pull request has now been integrated. Changeset: 7424f4

Re: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux

2022-05-05 Thread Matthias Baesken
On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and > jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small > shell scripts without #! at the first line of the script. This fails with

Integrated: JDK-8285987: executing shell scripts without #! fails on Alpine linux

2022-05-05 Thread Matthias Baesken
On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and > jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small > shell scripts without #! at the first line of the script. This fails with

Re: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux

2022-05-05 Thread Matthias Baesken
On Thu, 5 May 2022 13:43:30 GMT, Alan Bateman wrote: >> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and >> jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small >> shell scripts without #! at the first line of the script. This fails with >> error=

Re: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux

2022-05-05 Thread Matthias Baesken
On Thu, 5 May 2022 15:24:25 GMT, Martin Doerr wrote: > Strange. The pre-submit tests are all green. Yes sorry those seem not to cover these 2 findings. And I think I locally run by mistake only the jdk test instead of the jdk + langtools tests with my script , this will of course not show t

RFR: JDK-8286191: misc tests fail due to JDK-8286191

2022-05-05 Thread Matthias Baesken
The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java . Additionally, the vm.musl predicate seem not to be available in the langtools tests. - Commit messages: - remove from ProblemList - Merge remote-tracking branch 'origin

Re: RFR: 8286191: misc tests fail due to JDK-8285987 [v2]

2022-05-05 Thread Matthias Baesken
> The isMusl method had to be handled in > test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java . > Additionally, the vm.musl predicate seem not to be available in the langtools > tests. Matthias Baesken has updated the pull request with a new target base due to a

Re: RFR: 8286191: misc tests fail due to JDK-8285987 [v3]

2022-05-05 Thread Matthias Baesken
> The isMusl method had to be handled in > test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java . > Additionally, the vm.musl predicate seem not to be available in the langtools > tests. Matthias Baesken has updated the pull request incrementally with one additi

Re: RFR: 8286191: misc tests fail due to JDK-8285987

2022-05-05 Thread Matthias Baesken
On Thu, 5 May 2022 16:33:53 GMT, Daniel D. Daugherty wrote: > ... update the PR's synopsis. Done . - PR: https://git.openjdk.java.net/jdk/pull/8556

Re: RFR: 8286191: misc tests fail due to JDK-8285987 [v3]

2022-05-05 Thread Matthias Baesken
On Thu, 5 May 2022 16:14:32 GMT, Daniel D. Daugherty wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> restore year in ExternalEditorTest, remove test exclusion >

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-06 Thread Matthias Baesken
On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote: > Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT. My little test program #include #inclu

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-06 Thread Matthias Baesken
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft

Integrated: JDK-8285730: unify _WIN32_WINNT settings

2022-05-09 Thread Matthias Baesken
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used > to target a minimum Windows version we want to support. See also for more > detailled information : > https://docs.microsoft.com/en-us/w

Re: RFR: 8286191: misc tests fail due to JDK-8285987 [v4]

2022-05-10 Thread Matthias Baesken
> The isMusl method had to be handled in > test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java . > Additionally, the vm.musl predicate seem not to be available in the langtools > tests. Matthias Baesken has updated the pull request with a new target base due to a

Integrated: 8286191: misc tests fail due to JDK-8285987

2022-05-10 Thread Matthias Baesken
On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken wrote: > The isMusl method had to be handled in > test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java . > Additionally, the vm.musl predicate seem not to be available in the langtools > tests. This pull request

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-12 Thread Matthias Baesken
On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: > This change seem to have made this group of declarations obsolete: > `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow > the > [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368

RFR: JDK-8288094: cleanup old _MSC_VER handling

2022-06-09 Thread Matthias Baesken
We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800). This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust. Currently still supported ("valid") VS version are 2017+, se

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling

2022-06-10 Thread Matthias Baesken
On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr wrote: > LGTM and sounds feasible. Hi Martin, thanks for the review. - PR: https://git.openjdk.org/jdk/pull/9105

  1   2   >