From jlahoda at openjdk.org  Tue Jul  9 07:38:45 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Jul 2024 07:38:45 GMT
Subject: [jdk23] Integrated: 8334433: jshell.exe runs an executable test.exe on
 startup
In-Reply-To: <S54wN4nWPdKLbmJi1vNlciNeBUCoRGwrmTgDIMgy_hE=.f4c0f69b-085a-40c9-9e11-05c3fc753a3e@github.com>
References: <S54wN4nWPdKLbmJi1vNlciNeBUCoRGwrmTgDIMgy_hE=.f4c0f69b-085a-40c9-9e11-05c3fc753a3e@github.com>
Message-ID: <TUNqvaGwo1iXPn-kpc8gDCM5ISphs10Gu4x8fIpOxuE=.4d6583a6-ce74-45af-96b2-77a6967f58bb@github.com>

On Fri, 28 Jun 2024 12:20:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [99d2bbf7](https://github.com/openjdk/jdk/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 28 Jun 2024 and was reviewed by Jaikiran Pai.
> 
> Thanks!
> 
> Original description:
> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> 
>  -    disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>  -    make the "exec" provider ignore the PATH environment variable, and use hardcoded value.
> 
> I tested this on Windows with cmd, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

This pull request has now been integrated.

Changeset: 4e523209
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e5232097902b7d30f9bd6e21f3936d29462375f
Stats:     103 lines in 3 files changed: 101 ins; 0 del; 2 mod

8334433: jshell.exe runs an executable test.exe on startup

Reviewed-by: vromero
Backport-of: 99d2bbf767ac33e1a021c90ba12d95ef37ea4816

-------------

PR: https://git.openjdk.org/jdk/pull/19939

From davidalayachew at gmail.com  Mon Jul 15 02:57:26 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 14 Jul 2024 22:57:26 -0400
Subject: Fwd: JShell bug
In-Reply-To: <CAA9v-_NGqENZnucAArufL2SE1y=j92rpyarG95HRozGp7-Ji9A@mail.gmail.com>
References: <CAA9v-_NGqENZnucAArufL2SE1y=j92rpyarG95HRozGp7-Ji9A@mail.gmail.com>
Message-ID: <CAA9v-_OWMTKUXZ3E2amJjB2xdXbUf4WG-Z+XKOVqNFGvLeKVhA@mail.gmail.com>

Hello Kulla Dev Team,

I am forwarding the below email to match the correct mailing list.



---------- Forwarded message ---------
From: David Alayachew <davidalayachew at gmail.com>
Date: Sun, Jul 14, 2024 at 3:17?PM
Subject: JShell bug
To: <discuss at openjdk.org>


Terribly sorry to post this on discuss, but I could not find which mailing
list supports JShell.

Attached to this email is text that I had in my clipboard.

I started a fresh JShell session, then pasted the text into JShell. It
immediately threw the attached stacktrace -- an AssertionError.

Here is some relevant info.

david at David2 MINGW64 ~/_WORKSPACE/_PROGRAMMING/_JAVA (main)
$ jshell --version
jshell 23-ea

david at David2 MINGW64 ~/_WORKSPACE/_PROGRAMMING/_JAVA (main)
$ java --version
openjdk 23-ea 2024-09-17
OpenJDK Runtime Environment (build 23-ea+31-2337)
OpenJDK 64-Bit Server VM (build 23-ea+31-2337, mixed mode, sharing)

Also, it seems like the closing curly brace on the switch expression is the
real problem. I pasted everything up to and including the default line in
one shot, then I pasted the trailing empty line, then I pasted the curly
brace, and then jshell crashed with the same error.


If I remove all empty newlines and minify the closing curly brace, it seems
like JShell is happy. Just adding further detail in case it speeds up
anything.


Could someone please forward this email and its attachments to the correct
mailing list?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240714/bb487679/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the stacktrace that came out
Type: application/octet-stream
Size: 3247 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240714/bb487679/thestacktracethatcameout.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text that I copy-pasted
Type: application/octet-stream
Size: 854 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240714/bb487679/textthatIcopy-pasted.obj>

From jan.lahoda at oracle.com  Mon Jul 15 08:18:22 2024
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 15 Jul 2024 10:18:22 +0200
Subject: Fwd: JShell bug
In-Reply-To: <CAA9v-_OWMTKUXZ3E2amJjB2xdXbUf4WG-Z+XKOVqNFGvLeKVhA@mail.gmail.com>
References: <CAA9v-_NGqENZnucAArufL2SE1y=j92rpyarG95HRozGp7-Ji9A@mail.gmail.com>
 <CAA9v-_OWMTKUXZ3E2amJjB2xdXbUf4WG-Z+XKOVqNFGvLeKVhA@mail.gmail.com>
Message-ID: <1065c293-389c-4564-8d4b-7b633dad4400@oracle.com>

Hello David,


Thanks for the report. I've filled:
https://bugs.openjdk.org/browse/JDK-8336375


Thanks,

 ??? Jan


On 15. 07. 24 4:57, David Alayachew wrote:
> Hello Kulla Dev Team,
>
> I am forwarding the below email to match the correct mailing list.
>
>
>
> ---------- Forwarded message ---------
> From: *David Alayachew* <davidalayachew at gmail.com>
> Date: Sun, Jul 14, 2024 at 3:17?PM
> Subject: JShell bug
> To: <discuss at openjdk.org>
>
>
> Terribly sorry to post this on discuss, but I could not find which 
> mailing list supports JShell.
>
> Attached to this email is text that I had in my clipboard.
>
> I started a fresh JShell session, then pasted the text into JShell. It 
> immediately threw the attached stacktrace -- an AssertionError.
>
> Here is some relevant info.
>
> david at David2 MINGW64 ~/_WORKSPACE/_PROGRAMMING/_JAVA (main)
> $ jshell --version
> jshell 23-ea
>
> david at David2 MINGW64 ~/_WORKSPACE/_PROGRAMMING/_JAVA (main)
> $ java --version
> openjdk 23-ea 2024-09-17
> OpenJDK Runtime Environment (build 23-ea+31-2337)
> OpenJDK 64-Bit Server VM (build 23-ea+31-2337, mixed mode, sharing)
>
> Also, it seems like the closing curly brace on the switch expression 
> is the real problem. I pasted everything up to and including the 
> default line in one shot, then I pasted the trailing empty line, then 
> I pasted the curly brace, and then jshell crashed with the same error.
>
>
> If I remove all empty newlines and minify the closing curly brace, it 
> seems like JShell is happy. Just adding further detail in case it 
> speeds up anything.
>
>
> Could someone please forward this email and its attachments to the 
> correct mailing list?
>
> Thank you for your time and help!
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240715/472f76ad/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Jul 15 13:01:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 15 Jul 2024 13:01:23 GMT
Subject: RFR: 8336375: Crash on paste to JShell
Message-ID: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>

On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:

Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
        at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
        at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
        at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)


The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

-------------

Commit messages:
 - 8336375: Crash on paste to JShell

Changes: https://git.openjdk.org/jdk/pull/20182/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20182&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336375
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20182/head:pull/20182

PR: https://git.openjdk.org/jdk/pull/20182

From jvernee at openjdk.org  Mon Jul 15 13:45:50 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Jul 2024 13:45:50 GMT
Subject: RFR: 8336375: Crash on paste to JShell
In-Reply-To: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
References: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
Message-ID: <wIaxGlw_gkqB31P3PIkmmnxDJBH1JDxAsl1IEnjZJ5U=.0c12fba7-144f-49ba-863f-321731e86dea@github.com>

On Mon, 15 Jul 2024 12:56:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
> I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
> I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:
> 
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
>         at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)
> 
> 
> The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

Looks good from the FFM perspective

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20182#pullrequestreview-2177762381

From liach at openjdk.org  Tue Jul 16 03:50:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Jul 2024 03:50:54 GMT
Subject: RFR: 8336375: Crash on paste to JShell
In-Reply-To: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
References: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
Message-ID: <H7JUgenKab_PIZEYEb7k7e-ox3xF0-ulGnQAg9G0Dxo=.98e75eb3-fa75-4116-bfa7-144c8e5fb307@github.com>

On Mon, 15 Jul 2024 12:56:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
> I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
> I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:
> 
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
>         at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)
> 
> 
> The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

Is this a bug in the shipped library? If yes, is it already fixed there, or do we plan to report or fix in the upstream?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20182#issuecomment-2229953736

From jlahoda at openjdk.org  Tue Jul 16 06:39:51 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 16 Jul 2024 06:39:51 GMT
Subject: RFR: 8336375: Crash on paste to JShell
In-Reply-To: <H7JUgenKab_PIZEYEb7k7e-ox3xF0-ulGnQAg9G0Dxo=.98e75eb3-fa75-4116-bfa7-144c8e5fb307@github.com>
References: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
 <H7JUgenKab_PIZEYEb7k7e-ox3xF0-ulGnQAg9G0Dxo=.98e75eb3-fa75-4116-bfa7-144c8e5fb307@github.com>
Message-ID: <50wXHB4pyo34VlT1_BLC7rBKQkLwMt0IuPDueJIJ-8g=.dde73b67-06e9-419c-994c-235034dfe11a@github.com>

On Tue, 16 Jul 2024 03:48:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is this a bug in the shipped library? If yes, is it already fixed there, or do we plan to report or fix in the upstream?

It was definitely an intent to send to JLine as well, done here:
https://github.com/jline/jline3/pull/1038

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20182#issuecomment-2230132094

From jlahoda at openjdk.org  Wed Jul 17 06:49:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Jul 2024 06:49:02 GMT
Subject: Integrated: 8336375: Crash on paste to JShell
In-Reply-To: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
References: <Fr0Gx-EBYgzvusJuQmHxHkLfI46KvZ8A3ttlWKmpiew=.477fd691-9fe1-4a1c-83c8-68a7e28a4a3a@github.com>
Message-ID: <A1NZRXbRlwut8dS79ExL1WPdstvtspbtsznRv24qJko=.f2029911-18c3-4ae8-9298-877a2ea3055e@github.com>

On Mon, 15 Jul 2024 12:56:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
> I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
> I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:
> 
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
>         at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)
> 
> 
> The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

This pull request has now been integrated.

Changeset: b9b0b850
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8336375: Crash on paste to JShell

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/20182

From jlahoda at openjdk.org  Wed Jul 17 06:53:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Jul 2024 06:53:59 GMT
Subject: [jdk23] RFR: 8336375: Crash on paste to JShell
Message-ID: <i7VOmGwKiVFbJ2KD1AGRL60WkXGV0E8zLKwMSBm8BuM=.2a8f1aea-674d-4db6-8a2e-a1a9a2d164e4@github.com>

Hi all,

This pull request contains a backport of commit [b9b0b850](https://github.com/openjdk/jdk/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 17 Jul 2024 and was reviewed by Jorn Vernee.

Thanks!

Original description:
On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:

Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
        at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
        at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
        at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)


The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

-------------

Commit messages:
 - Backport b9b0b8504ec989ad0687188de4bccfe2c04e5d64

Changes: https://git.openjdk.org/jdk/pull/20213/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336375
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20213/head:pull/20213

PR: https://git.openjdk.org/jdk/pull/20213

From jvernee at openjdk.org  Wed Jul 17 12:02:55 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 17 Jul 2024 12:02:55 GMT
Subject: [jdk23] RFR: 8336375: Crash on paste to JShell
In-Reply-To: <i7VOmGwKiVFbJ2KD1AGRL60WkXGV0E8zLKwMSBm8BuM=.2a8f1aea-674d-4db6-8a2e-a1a9a2d164e4@github.com>
References: <i7VOmGwKiVFbJ2KD1AGRL60WkXGV0E8zLKwMSBm8BuM=.2a8f1aea-674d-4db6-8a2e-a1a9a2d164e4@github.com>
Message-ID: <myv8atMPVQbwRHFv2w7Jdow0yahpw_CVEy0dPr7WgGQ=.64f15581-a9e2-406c-9043-9dfee4e3934a@github.com>

On Wed, 17 Jul 2024 06:48:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b9b0b850](https://github.com/openjdk/jdk/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 17 Jul 2024 and was reviewed by Jorn Vernee.
> 
> Thanks!
> 
> Original description:
> On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
> I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
> I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:
> 
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
>         at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)
> 
> 
> The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20213#pullrequestreview-2182720694

From jlahoda at openjdk.org  Thu Jul 18 04:49:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Jul 2024 04:49:37 GMT
Subject: [jdk23] Integrated: 8336375: Crash on paste to JShell
In-Reply-To: <i7VOmGwKiVFbJ2KD1AGRL60WkXGV0E8zLKwMSBm8BuM=.2a8f1aea-674d-4db6-8a2e-a1a9a2d164e4@github.com>
References: <i7VOmGwKiVFbJ2KD1AGRL60WkXGV0E8zLKwMSBm8BuM=.2a8f1aea-674d-4db6-8a2e-a1a9a2d164e4@github.com>
Message-ID: <pUPZhIL838Q5Y4z91jpu-clgWQEKdDVfePfX0R4yWqQ=.98302097-ee3e-4f79-a826-d29763c5da78@github.com>

On Wed, 17 Jul 2024 06:48:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b9b0b850](https://github.com/openjdk/jdk/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 17 Jul 2024 and was reviewed by Jorn Vernee.
> 
> Thanks!
> 
> Original description:
> On Windows, the `ScrollConsoleScreenBufferW` function is being looked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L406
> I.e. the parameters are `MemorySegment`s/pointers. But, it is being invoked like this:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L239
> I.e. with values rather than with pointers. This then fails at runtime when the function is called with an exception like:
> 
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type (MemorySegment,MemorySegment,MemorySegment,MemorySegment,MemorySegment)int but found (MemorySegment,SMALL_RECT,SMALL_RECT,COORD,CHAR_INFO)int
>         at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at jdk.internal.le/jdk.internal.org.jline.terminal.impl.ffm.Kernel32.ScrollConsoleScreenBuffer(Kernel32.java:239)
> 
> 
> The proposal here is to use MemorySegments embedded in the provided parameters. This is consistent with the rest of the file, see for example here:
> https://github.com/openjdk/jdk/blob/a253e0ff4b88541d01596b0e73ede4b96a258fca/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java#L173

This pull request has now been integrated.

Changeset: 0c82e4bf
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c82e4bf19ab608406190429b6b55c54b299d962
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8336375: Crash on paste to JShell

Reviewed-by: jvernee
Backport-of: b9b0b8504ec989ad0687188de4bccfe2c04e5d64

-------------

PR: https://git.openjdk.org/jdk/pull/20213

From dholmes at openjdk.org  Fri Jul 19 05:53:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jul 2024 05:53:02 GMT
Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC
In-Reply-To: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
References: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
Message-ID: <LaLgWsRWb2ET8P0met4qJsaNCUaLY50WAEWBqQUJsWE=.c056c21a-5067-4bb3-80bc-71cb43d12692@github.com>

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.
> 
> This also picks up the unpublished changes to java.1 from:
> 
> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC
> 
> And a typo crept in to java.1 from:
> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
> 
> This also picks up the unpublished change to keytool.1 from:
> 
> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints
> 
> This also picks up the unpublished change to javadoc.1 from:
> 
> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class
> 
> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:
> 
> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments
> 
> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).
> 
> Thanks.

Note this is simply a re-generation of the troff files from their sources. If there are any problems that need fixing then a new JBS issue has to be filed to update the source file and regenerate the troff file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238248354

From dholmes at openjdk.org  Fri Jul 19 05:53:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jul 2024 05:53:01 GMT
Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC
Message-ID: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>

Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.

This also picks up the unpublished changes to java.1 from:

- [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
- [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC

And a typo crept in to java.1 from:
- [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

This also picks up the unpublished change to keytool.1 from:

- [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints

This also picks up the unpublished change to javadoc.1 from:

- [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class

and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:

- [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
- [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments

The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).

Thanks.

-------------

Commit messages:
 - 8325280: Update troff manpages in JDK 23 before RC

Changes: https://git.openjdk.org/jdk/pull/20248/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325280
  Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/20248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20248/head:pull/20248

PR: https://git.openjdk.org/jdk/pull/20248

From alanb at openjdk.org  Fri Jul 19 08:29:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Jul 2024 08:29:36 GMT
Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC
In-Reply-To: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
References: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
Message-ID: <zOBG9uS30VKu_wYx1Stm4UxuJkHtY0T_yeGKZq9n6j8=.5abf4fdc-3458-4ff7-ad78-6c504f58267b@github.com>

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.
> 
> This also picks up the unpublished changes to java.1 from:
> 
> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC
> 
> And a typo crept in to java.1 from:
> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
> 
> This also picks up the unpublished change to keytool.1 from:
> 
> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints
> 
> This also picks up the unpublished change to javadoc.1 from:
> 
> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class
> 
> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:
> 
> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments
> 
> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).
> 
> Thanks.

Marked as reviewed by alanb (Reviewer).

Thanks for the tireless effort to update the man pages at the end of each release.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2187669729
PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238647463

From iris at openjdk.org  Fri Jul 19 17:21:32 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 19 Jul 2024 17:21:32 GMT
Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC
In-Reply-To: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
References: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
Message-ID: <I-IAFzVCOoEvnU1JfIxdVPcuw5Johb2S_doXUC5WKzQ=.bf70674f-6122-4afc-b7c6-3cb219b91c71@github.com>

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.
> 
> This also picks up the unpublished changes to java.1 from:
> 
> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC
> 
> And a typo crept in to java.1 from:
> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
> 
> This also picks up the unpublished change to keytool.1 from:
> 
> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints
> 
> This also picks up the unpublished change to javadoc.1 from:
> 
> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class
> 
> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:
> 
> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments
> 
> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).
> 
> Thanks.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2188754909

From dholmes at openjdk.org  Sun Jul 21 23:09:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 21 Jul 2024 23:09:34 GMT
Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC
In-Reply-To: <zOBG9uS30VKu_wYx1Stm4UxuJkHtY0T_yeGKZq9n6j8=.5abf4fdc-3458-4ff7-ad78-6c504f58267b@github.com>
References: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
 <zOBG9uS30VKu_wYx1Stm4UxuJkHtY0T_yeGKZq9n6j8=.5abf4fdc-3458-4ff7-ad78-6c504f58267b@github.com>
Message-ID: <PKHjdaSrlt2oi0T3loqJAZtxuN4B88hkb58kaJT5law=.065ca39f-3120-47e1-9100-12469b092e77@github.com>

On Fri, 19 Jul 2024 08:26:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.
>> 
>> This also picks up the unpublished changes to java.1 from:
>> 
>> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
>> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC
>> 
>> And a typo crept in to java.1 from:
>> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
>> 
>> This also picks up the unpublished change to keytool.1 from:
>> 
>> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints
>> 
>> This also picks up the unpublished change to javadoc.1 from:
>> 
>> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class
>> 
>> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:
>> 
>> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
>> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments
>> 
>> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).
>> 
>> Thanks.
>
> Thanks for the tireless effort to update the man pages at the end of each release.

Thanks for the reviews @AlanBateman  and @irisclark !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2241805932

From dholmes at openjdk.org  Sun Jul 21 23:09:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 21 Jul 2024 23:09:35 GMT
Subject: [jdk23] Integrated: 8325280: Update troff manpages in JDK 23 before RC
In-Reply-To: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
References: <DeB-4YRsbH0dQ8M6eixjBGhQ0gz7fW7aSsSkkllIU4k=.f8be0160-182d-44b0-a87e-b7e14c34c7d5@github.com>
Message-ID: <eP7iF2Z05Xi0C3oYSygXe2niCyNuEiWvCegselkeQKA=.645770f8-d30e-427e-ab86-80786cf93079@github.com>

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed.
> 
> This also picks up the unpublished changes to java.1 from:
> 
> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags
> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC
> 
> And a typo crept in to java.1 from:
> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
> 
> This also picks up the unpublished change to keytool.1 from:
> 
> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints
> 
> This also picks up the unpublished change to javadoc.1 from:
> 
> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class
> 
> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for:
> 
> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments
> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments
> 
> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't).
> 
> Thanks.

This pull request has now been integrated.

Changeset: 5473e9e4
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5473e9e488c8fc7d99ea9d97fd0e7dd212636546
Stats:     142 lines in 28 files changed: 51 ins; 52 del; 39 mod

8325280: Update troff manpages in JDK 23 before RC

Reviewed-by: alanb, iris

-------------

PR: https://git.openjdk.org/jdk/pull/20248

From vromero at openjdk.org  Wed Jul 24 17:38:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jul 2024 17:38:57 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash
Message-ID: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>

There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,

TIA

-------------

Commit messages:
 - 8337037: compiler internal options are not printing the stacktrace after a compiler crash

Changes: https://git.openjdk.org/jdk/pull/20314/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337037
  Stats: 75 lines in 8 files changed: 45 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/20314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314

PR: https://git.openjdk.org/jdk/pull/20314

From vromero at openjdk.org  Wed Jul 24 17:46:44 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Jul 2024 17:46:44 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v2]
In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
Message-ID: <bd986CycdoSUrd4_J9JBfYUIUJRwHdm5mHHJos0zBdU=.deb9ef3f-ae00-4b85-9353-6058b148bd9f@github.com>

> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20314/files
  - new: https://git.openjdk.org/jdk/pull/20314/files/e59796c5..2bc5cc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=00-01

  Stats: 27 lines in 3 files changed: 7 ins; 20 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314

PR: https://git.openjdk.org/jdk/pull/20314

From mcimadamore at openjdk.org  Thu Jul 25 09:57:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jul 2024 09:57:34 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v2]
In-Reply-To: <bd986CycdoSUrd4_J9JBfYUIUJRwHdm5mHHJos0zBdU=.deb9ef3f-ae00-4b85-9353-6058b148bd9f@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
 <bd986CycdoSUrd4_J9JBfYUIUJRwHdm5mHHJos0zBdU=.deb9ef3f-ae00-4b85-9353-6058b148bd9f@github.com>
Message-ID: <hssdg16OHmhZe6-8RwhJDHkZXbJKOLh2Yy2aDyjogpE=.00acae81-3017-4303-bc5c-3781d5c0f2d0@github.com>

On Wed, 24 Jul 2024 17:46:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Looks good. Two observation (no need to do anything, mostly for your consideration):
* Given that the new exception type is used across different types (e.g. Types and Resolve), it would perhaps make sense to put it in the `util` package?
* I noticed that the changes to Type.SignatureGenerator have caused a cascade effect on all the subclasses. I wonder: perhaps SignatureGenerator should be an member inner class, so that it can read its "doe" bit from `Types` directly? After all, clients all have a `types` instance available when creating a subclass of the signature generator, so that would work for them too, but would avoid a bit of repetition.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2198849601
PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2198849889

From vromero at openjdk.org  Thu Jul 25 15:53:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 25 Jul 2024 15:53:11 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v3]
In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
Message-ID: <67aL-_uglJIWeqILraOM8SMsZElQRbHXf2hE0Twkg3c=.0688a6da-e7aa-4961-9c0d-4aadd713acb6@github.com>

> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20314/files
  - new: https://git.openjdk.org/jdk/pull/20314/files/2bc5cc32..c5bb19cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=01-02

  Stats: 109 lines in 9 files changed: 58 ins; 36 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314

PR: https://git.openjdk.org/jdk/pull/20314

From vromero at openjdk.org  Thu Jul 25 16:06:01 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 25 Jul 2024 16:06:01 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v4]
In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
Message-ID: <2ZT6n0HemLAL6xup6asFZIz-NKa4oO3iyzeriB_IWU8=.5c75eb5b-ba86-48e8-baea-d4eceac40def@github.com>

> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  clean-up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20314/files
  - new: https://git.openjdk.org/jdk/pull/20314/files/c5bb19cb..51fada43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=02-03

  Stats: 5 lines in 4 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314

PR: https://git.openjdk.org/jdk/pull/20314

From vromero at openjdk.org  Thu Jul 25 16:10:49 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 25 Jul 2024 16:10:49 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v5]
In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
Message-ID: <U4a6_V6wpdRbhm0LJY_IlCA962Sq8anx3jEeoMPBC40=.71407dbc-6961-4d1a-8a0a-e08a855d9a3d@github.com>

> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  removing unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20314/files
  - new: https://git.openjdk.org/jdk/pull/20314/files/51fada43..3407774f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20314&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20314/head:pull/20314

PR: https://git.openjdk.org/jdk/pull/20314

From vromero at openjdk.org  Thu Jul 25 16:13:45 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 25 Jul 2024 16:13:45 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v2]
In-Reply-To: <hssdg16OHmhZe6-8RwhJDHkZXbJKOLh2Yy2aDyjogpE=.00acae81-3017-4303-bc5c-3781d5c0f2d0@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
 <bd986CycdoSUrd4_J9JBfYUIUJRwHdm5mHHJos0zBdU=.deb9ef3f-ae00-4b85-9353-6058b148bd9f@github.com>
 <hssdg16OHmhZe6-8RwhJDHkZXbJKOLh2Yy2aDyjogpE=.00acae81-3017-4303-bc5c-3781d5c0f2d0@github.com>
Message-ID: <ocbEJULyaE4wBZUHsK9MGFL5bfRGyem7xUa-OkkUyaQ=.2971e6be-5612-4f53-8098-75c4a54fc6bd@github.com>

On Thu, 25 Jul 2024 09:54:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good. Two observation (no need to do anything, mostly for your consideration):
> 
>     * Given that the new exception type is used across different types (e.g. Types and Resolve), it would perhaps make sense to put it in the `util` package?
> 
>     * I noticed that the changes to Type.SignatureGenerator have caused a cascade effect on all the subclasses. I wonder: perhaps SignatureGenerator should be an member inner class, so that it can read its "doe" bit from `Types` directly? After all, clients all have a `types` instance available when creating a subclass of the signature generator, so that would work for them too, but would avoid a bit of repetition.

thanks for your comments, I have made the proposed modifications plus a few other minor changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20314#issuecomment-2250839730

From mcimadamore at openjdk.org  Thu Jul 25 16:26:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 Jul 2024 16:26:33 GMT
Subject: RFR: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash [v5]
In-Reply-To: <U4a6_V6wpdRbhm0LJY_IlCA962Sq8anx3jEeoMPBC40=.71407dbc-6961-4d1a-8a0a-e08a855d9a3d@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
 <U4a6_V6wpdRbhm0LJY_IlCA962Sq8anx3jEeoMPBC40=.71407dbc-6961-4d1a-8a0a-e08a855d9a3d@github.com>
Message-ID: <mYKHeIAQIOOPOWvEUjuj_JyJNAqsPDy7yqWwSUrj2YI=.f5509d6b-dc00-4053-a061-b5713623f08b@github.com>

On Thu, 25 Jul 2024 16:10:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unused import

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20314#pullrequestreview-2199807865

From vromero at openjdk.org  Thu Jul 25 17:06:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 25 Jul 2024 17:06:38 GMT
Subject: Integrated: 8337037: compiler internal options are not printing the
 stacktrace after a compiler crash
In-Reply-To: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
References: <7DgzrsDcw2vbWHjLX7v6pyI0nfOumLLqA3_5voRLM7w=.57a2b170-420e-4679-9b42-ffeb5262037e@github.com>
Message-ID: <1fVwA9V3jpCPownWfuCNZ7Ybp-NAD4uBwvf3VLmRCR0=.77a9e946-d5e9-40cb-a53e-3b8f872216b5@github.com>

On Wed, 24 Jul 2024 17:33:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> There are two internal javac options: `doe` and `dev` that we use to indicate the compiler to printout the stacktrace of any error issued and or exception thrown. There are a number of internal exceptions for which the stacktrace was not being produced due to performance issues. This patch is restoring the previous compiler behavior, printing out stacktraces if the internal options are passed, while keeping the most performant approach when none of the mentioned internal options is passed,
> 
> TIA

This pull request has now been integrated.

Changeset: cf0d9e0e
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf0d9e0e521b495a96a3de7775b1b3ae14d20d80
Stats:     138 lines in 9 files changed: 75 ins; 30 del; 33 mod

8337037: compiler internal options are not printing the stacktrace after a compiler crash

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/20314