On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
> [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e
Hi all,
This pull request contains a backport of
[JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
[bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and
> was reviewed by Christoph Langer and Sean Mullan.
>
> Thanks!
Thanks for doing the backport.
-
Marked as reviewed by clanger (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19841#pullrequestreview-2133855195
On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade wrote:
> Updated all the tests that depend on external infrastructure services as
> manual. These tests may fail with external reasons, for instance - change in
> CA test portal, certificate status updates, or network issues.
Looks good, although
On Mon, 17 Jun 2024 08:19:18 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847), commit
> [f5213671](https://github.com/openjdk/jdk/commit/f5213671f7b636b32bb93c78e43696a61c
backported was authored by Christoph Langer on 13 Jun 2024 and
was reviewed by Thomas Stuefe.
Thanks!
-
Commit messages:
- Backport f5213671f7b636b32bb93c78e43696a61cd69bae
Changes: https://git.openjdk.org/jdk/pull/19742/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19742=00
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
This pull request has now been integrated.
Changeset: f5213671
Author: Christoph Langer
URL:
https://git.openjdk.org/jdk/com
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Trivial fix of test listing, so
-
PR Comment: https://git.openjdk.org/jdk/pull/19691#issuecomment-2165639694
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Maybe [this
one](https://github.com/openjdk/jdk/commit/4d9042043ecade75d50c25574a445e6b8ef43618)?
But just guessing...
-
PR Comment: ht
It seems the error is gone meanwhile. So we can reenable the test.
-
Commit messages:
- JDK-8211847
Changes: https://git.openjdk.org/jdk/pull/19691/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19691=00
Issue: https://bugs.openjdk.org/browse/JDK-8211847
Stats: 1 line in
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 Wed, 30 Aug 2023 19:30:37 GMT, Mandy Chung wrote:
>> Oliver Kopp has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove obsolete imports
>
> Looks good. Thanks for catching this.
>
> There are a few unused imports in
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 Tue, 15 Aug 2023 20:41:13 GMT, Mandy Chung wrote:
>> Christoph has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove obsolete jimage and decompile methods
>
> Marked as reviewed by mchung (Reviewer).
On Thu, 10 Aug 2023 21:42:41 GMT, Christoph wrote:
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
>
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
On Tue, 15 Aug 2023 20:41:03 GMT, Mandy Chung wrote:
>> Christoph has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove obsolete jimage and decompile methods
>
> test/jdk/tools/jlink/dedup/src/m4/p4/Main.
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
On Tue, 15 Aug 2023 19:51:44 GMT, Christoph wrote:
>> Add new test case with sample modules that contains some
>> requires/exports/uses/provides.
>>
>> We are just unsure if and how we should add some last step of verificaiton
>> with the extracted and decompile
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
On Mon, 14 Aug 2023 22:07:32 GMT, Mandy Chung wrote:
> Since the batch size is 1, I would suggest that `p4.Main` can also load
> `jdk.internal.module.SystemModules$all` and verify the expected numbers of
> `subX` methods (one per each module). To find all modules in the image, you
> can
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
> Add new test case with sample modules that contains some
> requires/exports/uses/provides.
>
> We are just unsure if and how we should add some last step of verificaiton
> with the extracted and decompiled class.
>
> Follow up task from https://github.com/openjdk/jdk/
On Fri, 14 Jul 2023 16:08:12 GMT, Mandy Chung wrote:
>>> It's looking pretty good.
>>
>> Thank you!
>>
>>> About the test, I don't see `ArrayList::add` in the generated bytecode of
>>> `sub2-13`. The dedup string set is used for the targets of qualified
>>> exports and opens and uses. The
Add new test case with sample modules that contains some
requires/exports/uses/provides.
We are just unsure if and how we should add some last step of verificaiton with
the extracted and decompiled class.
Follow up task from https://github.com/openjdk/jdk/pull/14408
-
Commit
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
1 - 100 of 126 matches
Mail list logo
