On Thu, 8 Dec 2022 07:41:22 GMT, Oliver Kopp wrote:
>> Would it be possible to paste in a summary on the VerifyError with the
>> previous iteration? If I read the latest update then the limit per helper
>> method has been bump to avoid it, is that right?
>
>> Would it be possible to paste in a
On Tue, 3 Jan 2023 16:17:41 GMT, Alan Bateman wrote:
>>> Would it be possible to paste in a summary on the VerifyError with the
>>> previous iteration?
>>
>> Isn't this https://github.com/openjdk/jdk/pull/10704#issuecomment-1286106503?
>>
>> Type top (current frame, locals[15]) is not assi
On Thu, 26 Jan 2023 19:18:52 GMT, Oliver Kopp wrote:
>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
>> "MethodTooLargeException thrown while creating a jlink image".
>>
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
>> of the fix is to sp
On Sun, 11 Jun 2023 21:01:54 GMT, Oliver Kopp wrote:
> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
> "MethodTooLargeException thrown while creating a jlink image".
>
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
> of the fix is to split u
On Mon, 12 Jun 2023 05:41:08 GMT, Oliver Kopp wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
>> line 754:
>>
>>> 752: // Restore all (!) sets from parameter to
>>> local variables
>>> 753:
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 messa
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 mod
> 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 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 simply
> 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 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/
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.
>
>
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 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 JLinkDedupTest
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Sat, 3 May 2025 20:56:00 GMT, Alexey Semenyuk wrote:
> jpackage doesn't produce a notarizable app image if --app-content is used.
> Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117)
Actually, this is a regression as it worked in JDK23 where we just used it
recently
https://g
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&pr=19691&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8211847
Stats: 1
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
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.
This pull request has now been integrated.
Changeset: f5213671
Author: Christoph Langer
URL:
https://git.openjdk.org/jdk/com
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&pr=1
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/f5213671f7b636b32bb93c78e43696a61cd69b
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
> 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
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 backpo
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/bd046d9b9e79e4eea89c72af358961ef6e98e6
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
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 backpo
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 [openjd
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/3b374c0153950ab193f3a188b57d3404b4ce2f
Hi Chris,
SapMachine has all the ea builds in its GitHub Repo:
https://github.com/SAP/SapMachine/releases. Should be fine enough for chasing
G1 GC behaviour changes.
Cheers
Christoph
> -Original Message-
> From: core-libs-dev On Behalf Of Chris
> Hegarty
> Sent: Freit
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 java.ba
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
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 java.ba
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 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
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 backpo
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/975316e3e5f1208e4e15eadc2493d25c155546
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 sho
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/d7f0de272c85ee8d0890c9d61e10065b618b69
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
> t
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 where this is r
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 codes
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 c
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 c
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 rev
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 somet
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 revi
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 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
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 backpo
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/d1cc2782606e8a3cfead9055aa845e48e851ed
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 cat
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 th
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 suggestion.
ck. My 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 ex
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
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 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
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: https://git.openjdk.o
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
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: n
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: https:
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
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 'sti
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
>> [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402
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.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c
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
ort 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
ort 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.
ort 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
ort 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
ort 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, 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.
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 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 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
> wou
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
>>> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579
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
>> compiler.rtm.locking.TestRTMTot
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
>> compiler.rtm.locking.TestRTMTot
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 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 Comment
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
>> compiler.rtm.locking.TestRTMTot
1 - 100 of 179 matches
Mail list logo
