On Wed, 15 May 2024 11:40:38 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Fri, 3 May 2024 15:25:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Tue, 16 Apr 2024 10:20:23 GMT, Alan Bateman wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> I think this is way too ad hoc and looks like lefts over from a debugging
> session. So
On Thu, 18 Apr 2024 06:57:05 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Mon, 15 Apr 2024 12:47:08 GMT, Matthias Baesken wrote:
> > If we expand the tracing then I think it should be consistent with the
> > existing tracing.
>
> What exactly do you see as inconsistent ?
Maybe the output of the tracing should look similar to other traces done
through
On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken wrote:
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
To me this looks useful, although maybe the overall JLI tracing could be
revisited.
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov wrote:
>>> As for the test, I had a closer look now and I find it hard to separate
>>> testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from
>>> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore,
>>>
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
> com.sun.jndi.lda
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Tue, 19 Mar 2024 16:09:18 GMT, Aleksei Efimov wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Tue, 19 Mar 2024 16:01:34 GMT, Aleksei Efimov wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer wrote:
> 4f336085d1098e7fba7b58f0a73c028179a2a13d
> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
> cases to test java/util/Formatter/Padding.java with huge Strings as
> arguments. Since all possi
On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti
wrote:
>> Christoph Langer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Generate large strings in parameter generator methods
>
> I wa
On Thu, 7 Mar 2024 17:37:59 GMT, Christoph Langer wrote:
> > > Thanks for exploring the possibility of improving tracebility of test
> > > invocations to reported bugs.
> > > >
> >
> >
> > I've given this test change a second thought, mayb
On Thu, 7 Mar 2024 17:38:24 GMT, Christoph Langer wrote:
>> src/java.naming/share/classes/module-info.java line 42:
>>
>>> 40: * The value of this environment property specifies the
>>> fully
>>> 41: * qualified class name of the socket
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
the one large @ParameterizedTest into
> multiple ones. With that, I could run the test successfully in a test VM with
> 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm
> -Xmx96m Padding`
Christoph Langer has updated the pull request incrementally with one additional
On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti
wrote:
> Can you please add the bug id to `@bug` and correct the typo, as suggested
> [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?
Done.
I kept the tenMillion... handling.
-
PR Comment:
the one large @ParameterizedTest into
> multiple ones. With that, I could run the test successfully in a test VM with
> 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm
> -Xmx96m Padding`
Christoph Langer has updated the pull request incrementally with one additional
c
On Wed, 13 Mar 2024 09:42:34 GMT, Raffaello Giulietti
wrote:
> What about factoring out the 4 invocations of `tenMillionBlanks()` in each
> source method in a local var?
OK, I inlined the generation of the ten million character strings into the
parameter generator methods. I looked a bit at
4f336085d1098e7fba7b58f0a73c028179a2a13d
([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases
to test java/util/Formatter/Padding.java with huge Strings as arguments. Since
all possible argument combinations for the test are stored in one array,
nothing can be garbage
On Wed, 6 Mar 2024 14:42:09 GMT, Aleksei Efimov wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov wrote:
> > Thanks for exploring the possibility of improving tracebility of test
> > invocations to reported bugs.
> > >
>
> I've given this test change a second thought, maybe you can try to separate
> the test into two separate test classes?
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Wed, 28 Feb 2024 12:32:17 GMT, Matthias Baesken wrote:
> Looks okay to me, but could we print here `RuntimeException(jmodFile + " is
> expected not to include native debug symbols` not only the jmod but also the
> unwanted file(s) ?
This information is already printed in
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
On Tue, 27 Feb 2024 16:48:05 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Sat, 24 Feb 2024 11:45:46 GMT, Jaikiran Pai wrote:
> This is similar to what other test libraries usually report for such failures.
But in the case of a non-empty `msg` you would not see the actual values any
more which I think could be helpful in a lot of cases...
-
PR
The new test JmodExcludedFiles.java checks that no debug symbol files are
contained in the jmod files. It does not take into account that with configure
option --with-external-symbols-in-bundles=public we want to have stripped pdb
files, also in jmods, to get native callstacks with line number.
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Thu, 22 Feb 2024 14:57:05 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Wed, 21 Feb 2024 18:26:18 GMT, Aleksei Efimov wrote:
>>> Currently, it is hard to distinguish what part of the test responsible for
>>> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and
>>> which part is for
>>>
On Mon, 19 Feb 2024 16:46:18 GMT, Aleksei Efimov wrote:
> Currently, it is hard to distinguish what part of the test responsible for
> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which
> part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). I
>
On Mon, 19 Feb 2024 16:57:23 GMT, Aleksei Efimov wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
On Mon, 19 Feb 2024 13:17:48 GMT, Goetz Lindenmaier wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
On Fri, 16 Feb 2024 16:39:33 GMT, Daniel Fuchs wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
On Tue, 20 Feb 2024 09:45:22 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Thu, 15 Feb 2024 15:11:15 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
es not support unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
> com.sun.jndi.lda
During analysing a customer case I figured out that we have an inconsistency
between documentation and actual behavior in class
com.sun.jndi.ldap.Connection. The [method documentation of
On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber wrote:
>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for
>> correct (Dekker scheme) synchronization with concurrent execution of
>>
On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bjørsnøs wrote:
>> This PR suggests that `Files.setPosixPermissions`as implemented by
>> `ZipFileSystem` should preserve the leading seven bits of the 'external file
>> attributes' field. These bits contain the 'file type', 'setuid', 'setgid',
>> and
On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer wrote:
> In the review of the PR for JDK-8322417 it was noted that a fully qualified
> class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
> up prior to integration.
Integrating under trivial rule.
On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer wrote:
> In the review of the PR for JDK-8322417 it was noted that a fully qualified
> class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
> up prior to integration.
This pull request has
In the review of the PR for JDK-8322417 it was noted that a fully qualified
class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
up prior to integration.
-
Commit messages:
- JDK-8322417
Changes: https://git.openjdk.org/jdk/pull/17203/files
Webrev:
On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken wrote:
> On Windows we recently run into this error rather often in the test
> LdapPoolTimeoutTest.java :
>
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root
> exception is java.net.ConnectException: Connection timed out:
On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote:
> java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already
> problem listed on linux-x64. However, the issue is not processor specific. We
> see the failure on linux on other architectures as well.
This pull re
java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem
listed on linux-x64. However, the issue is not processor specific. We see the
failure on linux on other architectures as well.
-
Commit messages:
- Update ProblemList.txt
Changes:
On Tue, 5 Sep 2023 13:52:09 GMT, Roger Riggs wrote:
> A bit late due to a US holiday. Looks good.
Thanks
-
PR Comment: https://git.openjdk.org/jdk/pull/15222#issuecomment-1706695064
On Thu, 10 Aug 2023 09:54:43 GMT, Christoph Langer wrote:
> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run
> as user that is member of the Administrators group. In that case new files
> are not owned by the user but instead by BUILTIN\ADMINISTRATORS. Th
On Fri, 1 Sep 2023 08:32:20 GMT, Christoph Langer wrote:
>> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run
>> as user that is member of the Administrators group. In that case new files
>> are not owned by the user but instead by BUILTIN\ADMINISTR
y suggestion is to cater for
> this case and don't fail the test but write a warning message to stdout that
> a whoami check is not correctly possible.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the
On Thu, 31 Aug 2023 15:08:34 GMT, Roger Riggs wrote:
>> The problem with the environment variables is, that jtreg only passes very
>> few of them down to the testee process - USERDOMAIN and USERNAME are not
>> part of these as far as I know.
>
> ok, more overhead than value in the
On Mon, 28 Aug 2023 05:24:09 GMT, Arno Zeller wrote:
>> I think you might use System.getProperty("user.name"). But I am not sure
>> about domain names of users on Windows.
>> I am also not sure why the user name is currently determined by creating a
>> file - there might be a reason for this
On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as
user that is member of the Administrators group. In that case new files are not
owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the
assumptions of the test's whoami check. My suggestion is to
On Tue, 1 Aug 2023 21:57:17 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit
> [d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e8
Hi all,
This pull request contains a backport of
[JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit
[d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being
On Fri, 28 Jul 2023 09:10:20 GMT, Alan Bateman wrote:
> JDK-8308609
I added a comment on https://bugs.openjdk.org/browse/JDK-8303498, cc
@offamitkumar
-
PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655513822
On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov wrote:
> This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
> problem list for linux-x86 where it intermittently fails on a GA, ex:
> https://github.com/openjdk/jdk21/pull/148
>
> This is only for JDK 21, test passes on
On Wed, 5 Jul 2023 15:01:52 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
>> line 196:
>>
>>> 194:
>>> 195: /**
>>> 196: * Set whether or not to use ct.sym as an alternate
>>
>> As an alternate to what? This needs
On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode
On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode
On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken wrote:
>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>at
>> java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>at
On Wed, 11 Jan 2023 09:21:18 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
> [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4
On Wed, 11 Jan 2023 17:01:26 GMT, Naoto Sato wrote:
>> Hi all,
>>
>> This pull request contains a backport of
>> [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
>> [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2)
>> from the
Hi all,
This pull request contains a backport of
[JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
[3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being
On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms wher
On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote:
> This patch removes the use of std::thread from the `java.lang.foreign` tests,
> and switches to the OS specific thread APIs, in order to change things such
> as the stack size on some platforms where this is required in the future (see
>
On Fri, 22 Jul 2022 07:04:29 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8290460](https://bugs.openjdk.org/browse/JDK-8290460), commit
> [d7f0de27](https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b61
Hi all,
This pull request contains a backport of
[JDK-8290460](https://bugs.openjdk.org/browse/JDK-8290460), commit
[d7f0de27](https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
It is a testfix, so
On Mon, 11 Jul 2022 15:07:28 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8287902](https://bugs.openjdk.org/browse/JDK-8287902), commit
> [975316e3](https://github.com/openjdk/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15
Hi all,
This pull request contains a backport of
[JDK-8287902](https://bugs.openjdk.org/browse/JDK-8287902), commit
[975316e3](https://github.com/openjdk/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15554647)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being
On Mon, 4 Jul 2022 10:39:20 GMT, Matthias Baesken wrote:
> 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl
Thanks for bringing it to jdk19.
-
Marked as reviewed by clanger (Reviewer).
PR: https://git.openjdk.org/jdk19/pull/106
On Fri, 1 Jul 2022 09:10:07 GMT, Christoph Langer wrote:
> This pull request contains a backport of
> [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit
> [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e)
> from the [openjd
On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote:
> Currently the ProcessBuilder/Basic.java test fails on musl.
> We run into
>>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at
This pull request contains a backport of
[JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit
[7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was
94 matches
Mail list logo
