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
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=
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 &
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
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
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
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
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:
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:
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
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
>
> 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
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
> 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
> 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
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
> 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
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
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
>
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
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
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
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
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
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",
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
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
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
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
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
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
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
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",
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
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",
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.
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
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
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
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
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
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
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
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
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
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:
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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.
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
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
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
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
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
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
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:
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://
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
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
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
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
--
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
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.
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
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 !
-
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
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
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
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=
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
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
> 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
> 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
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
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
>
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
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
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
> 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
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
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
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
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 - 100 of 115 matches
Mail list logo