h our testing still to see whether it'll resolve all
> of the test issues and does not introduce regressions.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains five commits:
- Merge branch 'master' into JDK
On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer wrote:
>> Severin Gehwolf 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 Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
h our testing still to see whether it'll resolve all
> of the test issues and does not introduce regressions.
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/reba
On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern wrote:
>> In the JDK launcher, there is a codepath which would set/modify the
>> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
>> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
>> contains
GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>>
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Review
On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Fri, 21 Mar 2025 09:46:02 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern wrote:
>> In the JDK launcher, there is a codepath which would set/modify the
>> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
>> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
>> contains
h our testing still to see whether it'll resolve all
> of the test issues and does not introduce regressions.
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/rebas
On Fri, 28 Mar 2025 17:04:03 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Fri, 28 Mar 2025 09:55:25 GMT, Matthias Baesken wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add !windows again and remove @compile
>
> test/jdk/tools/launcher/ExecutionEnvironment.java line 42:
>
>> 40: *
On Thu, 27 Mar 2025 13:28:13 GMT, Jaikiran Pai wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cleanup
>
> test/jdk/tools/launcher/ExecutionEnvironment.java line 28:
>
>> 26: * @bug 4780570 4731671 6354700 636707
On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Wed, 26 Mar 2025 17:47:07 GMT, Severin Gehwolf wrote:
> > Would it maybe make sense/be possible to offer some re-hash functionality
> > for using in 2nd step builds?
>
> What would that be? Right now linking from the run-time image doesn't allow
> for `jdk.jlink` to be included, which preve
On Wed, 26 Mar 2025 14:50:11 GMT, Alan Bateman wrote:
> > I'll keep looking into this specific case. However, it sounds a bit
> > orthogonal to the patch at hand which I do believe we still need for the
> > original reasons mentioned (RPM changing binaries after the JDK build is
> > long done
On Tue, 25 Mar 2025 17:43:07 GMT, Severin Gehwolf wrote:
>> Please review this enhancement which adds a hidden `jlink` option
>> `--sha-overrides` that can be used to provide alternative hash sums for
>> files in an image. Please see the bug for use-cases as to why this is
>> needed. This patc
On Mon, 24 Mar 2025 11:02:15 GMT, Severin Gehwolf wrote:
> Please review this enhancement which adds a hidden `jlink` option
> `--sha-overrides` that can be used to provide alternative hash sums for files
> in an image. Please see the bug for use-cases as to why this is needed. This
> patch al
On Fri, 21 Mar 2025 09:46:02 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Thu, 20 Mar 2025 17:28:54 GMT, Severin Gehwolf wrote:
>> After running this patch through our testing I can confirm that it at least
>> solves all existing test issues and does not create regressions.
>>
>> I, however, admit that the added code in JRTArchive.java is quite hacky and
>> is ac
On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote:
> Alternative approach to #24012
>
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
> be improved, e.g. make it m
On Fri, 14 Mar 2025 14:10:30 GMT, Severin Gehwolf wrote:
>> Alternative approach to #24012
>>
>> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
>> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
>> be improved, e.g. make it more conditional
Alternative approach to #24012
This keeps the current handling of *.pdb vs *.stripped.pdb which allows
debugging at the cost of a little hack in jlink.
-
Commit messages:
- JDK-8351842
Changes: https://git.openjdk.org/jdk/pull/24057/files
Webrev: https://webrevs.openjdk.org/?rep
On Tue, 11 Feb 2025 10:17:48 GMT, Christoph Langer wrote:
>> The change for JDK-8346434 added a new test case to
>> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
>> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
>>
On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer wrote:
> The change for JDK-8346434 added a new test case to
> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
> part of the
On Fri, 7 Feb 2025 17:43:15 GMT, Alexey Semenyuk wrote:
>> As far as my testing is concerned it's only `jdk.crypto.cryptoki` which is
>> different with `--bind-services` (as it provides a security provider as a
>> service and doesn't export API).
>
> This is the diff of modules between "jpackag
> The change for JDK-8346434 added a new test case to
> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
> part of the target image.
> This can be circumvented by limiting the modu
The change for JDK-8346434 added a new test case to
tools/jpackage/share/JLinkOptionsTest.java which does not respect the
constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
part of the target image.
This can be circumvented by limiting the modules.
-
Commi
On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
On Fri, 10 Jan 2025 11:22:31 GMT, Matthias Baesken wrote:
>> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
>> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
>> implementation that was shared between Solaris and AIX. Linux and MacOS
>> a
On Fri, 10 Jan 2025 10:43:24 GMT, Matthias Baesken wrote:
> Hi Christoph, I adjusted the COPYRIGHT info and removed unix_getChildren .
> Regarding 'Solaris' mentioning in this file , I removed that one too but a
> grep shows there are plenty of Solaris comments etc. in t
On Fri, 10 Jan 2025 10:43:35 GMT, Matthias Baesken wrote:
>> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
>> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
>> implementation that was shared between Solaris and AIX. Linux and MacOS
>> a
On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote:
> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
> implementation that was shared between Solaris and AIX. Linux and MacOS
> alread
On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote:
>> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on
>> AIX. The test exclusion was removed through
>> [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the
>> assumption the problem was gone. But it t
On Wed, 8 Jan 2025 14:14:29 GMT, Matthias Baesken wrote:
> I created https://bugs.openjdk.org/browse/JDK-8347270 8347270: Remove
> unix_getParentPidAndTimings after JDK-8346880
I massaged the bug a little bit. But I still think this could all be done in
this PR.
-
PR Comment: htt
On Wed, 8 Jan 2025 13:51:53 GMT, Joachim Kern wrote:
> > > Seems, that we were the only remainding users of
> > > unix_getParentPidAndTimings(). Should I remove the orphant?
> >
> >
> > I would be in favor of removing it (in this PR or separate).
>
> OK agree, but in a separate PR. Could you
On Tue, 1 Oct 2024 12:40:57 GMT, Matthias Baesken wrote:
>> src/java.base/macosx/native/libjli/java_md_macosx.m line 315:
>>
>>> 313: rc = pthread_create(&main_thr, NULL, &apple_main, &args);
>>> 314: if (rc != 0) {
>>> 315: JLI_ReportErrorMessageSys("Could not create main thread
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
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
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
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
> 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/f5213671f7b636b32bb93c78e43696a61cd69b
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 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&pr=19691&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8211847
Stats: 1
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 n
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 no
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 no
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 com
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 com
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 com
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 I
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 com
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 `JLI_TraceL
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.
src/ja
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,
>>> mos
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
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,
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
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
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 additi
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: https://g
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 addition
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 t
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
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 with
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 with
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
&
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 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 isNativeDebugSymbol
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
>> 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
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
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
>> compiler.rtm.locking.TestRTMTot
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 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 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 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.
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
1 - 100 of 166 matches
Mail list logo
