From asotona at openjdk.org  Tue Apr  2 15:34:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Apr 2024 15:34:09 GMT
Subject: RFR: 8328627: JShell documentation should be clearer about
 "remote runtime system" [v3]
In-Reply-To: <hDmN99oKHzNA7mex3RqSUkKwrY6b9LrkuhWWgNkzWj4=.425e1385-c1a0-4aa9-a278-b7ae1259c8fb@github.com>
References: <GIGGkIFLIhWNK7qAOJqnrg3VJSl6l3-CStxCypQS8_c=.f33d094e-9b6a-46ae-98a5-cb3e2d9ccc5b@github.com>
 <hDmN99oKHzNA7mex3RqSUkKwrY6b9LrkuhWWgNkzWj4=.425e1385-c1a0-4aa9-a278-b7ae1259c8fb@github.com>
Message-ID: <p-m850KH7YlvhCDtLQ2moR4sB4eEJ3dGSACehPVttTI=.62a0ffd8-a3d8-4f8f-ae42-1eb94f66db8b@github.com>

On Fri, 22 Mar 2024 19:38:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This change attempts to more clearly explain the difference between `-J` and `-R` for JShell.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as suggested.

Looks good to me ?

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18450#pullrequestreview-1974204150

From darcy at openjdk.org  Wed Apr  3 06:02:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 06:02:04 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record Creation
 (Preview)
Message-ID: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>

Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

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

Commit messages:
 - Add more support for component local variables.
 - Add uses of new visitor types.
 - JDK-8329556: javax.lang.model suppor for Derived Record Creation (Preview)
 - Baseline on 04 version of the webrev.

Changes: https://git.openjdk.org/jdk/pull/18590/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329556
  Stats: 1640 lines in 49 files changed: 1550 ins; 20 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/18590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18590/head:pull/18590

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

From ihse at openjdk.org  Wed Apr  3 10:04:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 10:04:01 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

The build changes look okay. 

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1976255818

From jlahoda at openjdk.org  Thu Apr  4 07:35:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 07:35:33 GMT
Subject: RFR: 8328935: Implement Module Imports.
Message-ID: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>

This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
https://bugs.openjdk.org/browse/JDK-8315129

It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
There is a few notable aspects, however:
- the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
- JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

Commit messages:
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - Merge branch 'module-imports' of github.com:lahodaj/jdk into module-imports
 - ... and 5 more: https://git.openjdk.org/jdk/compare/f26e4308...9cab0ae8

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328935
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From duke at openjdk.org  Thu Apr  4 11:46:10 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 4 Apr 2024 11:46:10 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>

On Thu, 4 Apr 2024 07:30:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036941814

From jlahoda at openjdk.org  Thu Apr  4 11:52:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 11:52:59 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
Message-ID: <PkEjwtAGwGv4mLh5mGGtGVBIPSHTF0738uNTmcQryzw=.830b4b46-94ba-40b0-bb89-9a1b50c8833a@github.com>

On Thu, 4 Apr 2024 11:43:07 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

Given we need to keep the existing code (as `import module java.se` would only work when preview is enabled), and given the outcomes for the user should be (I think, at least) the same, it does not seem necessary to me to complicate things by having two ways to achieve the same outcome.

When the feature goes final, then maybe we could consider replacing the hardcoded JAVASE with a script. But, even then, the user might use `-C--release=21`, and `import module java.se` would not work then, so it may be easier to keep the current code even then.

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036957025

From jlahoda at openjdk.org  Thu Apr  4 14:13:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 14:13:27 GMT
Subject: RFR: 8328481: Implement Module Imports [v2]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <JO0h7iNpNt6eGqBfRUboq8R6AKfKJ4yvAps-kGdKD8Y=.23754f67-5b3b-4505-8aaa-e19b10751f80@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda 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 contains 16 additional commits since the last revision:

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c0131b...3f2deab9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/9cab0ae8..3f2deab9

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

  Stats: 318 lines in 18 files changed: 46 ins; 198 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <oxGgm-e1ERf84KUzrd4CNGYKE8uw1JVPyS5XnYAxqOk=.f277b54e-4f47-45ff-9c51-94d1d5be5282@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

The changes in this PR are being incorporated into the larger PR for derived record creation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18590#issuecomment-2040316977

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: Withdrawn: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <hgxJOeKQkdCfyi7oJ4s3lbCyeg9k2_oE_vcUUJR13ko=.e7b82340-1d47-4720-9608-b6e7b67527aa@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Mon Apr  8 12:17:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Apr 2024 12:17:14 GMT
Subject: Integrated: 8328627: JShell documentation should be clearer about
 "remote runtime system"
In-Reply-To: <GIGGkIFLIhWNK7qAOJqnrg3VJSl6l3-CStxCypQS8_c=.f33d094e-9b6a-46ae-98a5-cb3e2d9ccc5b@github.com>
References: <GIGGkIFLIhWNK7qAOJqnrg3VJSl6l3-CStxCypQS8_c=.f33d094e-9b6a-46ae-98a5-cb3e2d9ccc5b@github.com>
Message-ID: <91qAc4mW9XvV0hHj4nYY8kzrp_sZBMvneUh46SxzWno=.e4d09865-d0d5-46f9-92dc-2b1a388ce782@github.com>

On Fri, 22 Mar 2024 11:17:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This change attempts to more clearly explain the difference between `-J` and `-R` for JShell.

This pull request has now been integrated.

Changeset: be45de1f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be45de1f93e918f928c6bb8bebc3697487adf602
Stats:     28 lines in 2 files changed: 14 ins; 0 del; 14 mod

8328627: JShell documentation should be clearer about "remote runtime system"

Co-authored-by: Alex Buckley <abuckley at openjdk.org>
Reviewed-by: asotona

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

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

From jlahoda at openjdk.org  Tue Apr  9 11:17:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 11:17:35 GMT
Subject: RFR: 8328481: Implement Module Imports [v3]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <jHYFkwh0r6Lfk31t4etDX0ZZv_5coHwTmFn7yNODlzk=.ec718d90-5b0f-4ca1-b6f2-36fdea20cd7c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/b9331cd2...c44031ed

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=02
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From mcimadamore at openjdk.org  Tue Apr  9 11:49:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Apr 2024 11:49:32 GMT
Subject: RFR: 8329948: Remove string template feature
Message-ID: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>

This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:

https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

Commit messages:
 - Drop spurious changes
 - Merge branch 'master' into template_removal
 - Drop string templates

Changes: https://git.openjdk.org/jdk/pull/18688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329948
  Stats: 7402 lines in 67 files changed: 135 ins; 7208 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18688/head:pull/18688

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

From jlahoda at openjdk.org  Tue Apr  9 13:38:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 13:38:29 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding more tests for ambiguities.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c44031ed..0ca05b7d

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

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

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

From cstein at openjdk.org  Wed Apr 10 08:44:11 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 10 Apr 2024 08:44:11 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:

> 3551: # 0: symbol
> 3552: compiler.err.import.module.does.not.read=\
> 3553:     current modules does not read: {0}

Suggestion:

    current module does not read: {0}


It would even be better to print the name of the "current" module, so that the user-facing message reads:
`current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559074245

From mcimadamore at openjdk.org  Wed Apr 10 11:55:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 11:55:10 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:

> 717:     public static class JCModuleImport extends JCImportBase {
> 718:         /** The module name. */
> 719:         public JCExpression module;

Does it need to be an expression? Or is a name enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559303562

From jlahoda at openjdk.org  Wed Apr 10 13:32:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 13:32:00 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
Message-ID: <dykimHLkPTQ3DOlg_958nShX_C6jg2R8LyYiYty9dvo=.8e80a4d4-50d4-476b-9c99-7caabe850c93@github.com>

On Wed, 10 Apr 2024 11:52:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:
> 
>> 717:     public static class JCModuleImport extends JCImportBase {
>> 718:         /** The module name. */
>> 719:         public JCExpression module;
> 
> Does it need to be an expression? Or is a name enough?

Expression is more consistent with e.g. the module directives (`JCRequires` has `JCExpression moduleName`). Also allows us to keep positions for the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559440577

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v5]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Uaz4XY4xMPhWtROJwJZXvj3xTpaLM9PkENBv2I7a5v0=.05e6dd91-b210-44b5-bdf9-55956ddb02d3@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Including current module name as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/0ca05b7d..7cfaff80

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

  Stats: 76 lines in 4 files changed: 73 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
Message-ID: <ppdqge1epw5D3i0ClDI94dSJEhzgUcnGhSxGYGZoiWU=.8f834464-b2c7-441b-85f0-520ba637c8ef@github.com>

On Wed, 10 Apr 2024 08:41:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:
> 
>> 3551: # 0: symbol
>> 3552: compiler.err.import.module.does.not.read=\
>> 3553:     current modules does not read: {0}
> 
> Suggestion:
> 
>     current module does not read: {0}
> 
> 
> It would even be better to print the name of the "current" module, so that the user-facing message reads:
> `current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

Thanks. I've tweaked the error to include the module name here:
https://github.com/openjdk/jdk/pull/18614/commits/7cfaff80eac6261b62c5cdb9614a0e708bce7e33

Regarding possible fix(es) - it may be better to introduce some framework for that, and convert the most typical errors, separately. (As I don't think we do that for other errors.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559616761

From jjg at openjdk.org  Thu Apr 11 20:55:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 20:55:24 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <au6_FZORG1xVh5VnfoMMR60a_2oa1qny0ElKeIGpvFI=.94ed31a5-a875-4bc6-927b-da0f512ad43e@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  adjust call for `saveDanglingDocComments` for enum members

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3d6f1f95..56d6dcac

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

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Fri Apr 12 17:24:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 17:24:43 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
Message-ID: <yoXk0XJ1mo_6lFPzenTjynOJmM2R8GNROFOTwN4p00g=.dcedceac-6d2a-4b1f-99ee-57d060b8a69b@github.com>

On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay. 
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

@magicus 
> The build changes look okay.
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up `java.base`, to keep that one free of any warnings, and I can see that the lang tools modules will get cleaner up as well. It will be up to other component teams to decide if and when to clean up other parts of the system.  Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like `this-escape`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2052174696

From jjg at openjdk.org  Fri Apr 12 21:04:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 21:04:06 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v3]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <3Ynu_D2CcFh3usjCkWQVk7VFhTlxVzD4f2nVhvZrP50=.f1c29740-ff73-4a0c-a63b-3e00ece05bbf@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  call `saveDanglingDocComments` for local variable declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/56d6dcac..3f745431

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

  Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jlahoda at openjdk.org  Wed Apr 17 14:45:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 14:45:13 GMT
Subject: RFR: 8328481: Implement Module Imports [v6]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Pzfi6LRqRSvUmAhqepfBUhXdEQfahOOHhadOqRvQndY=.b1f3db3d-8d9e-414e-9a13-f256072a1642@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into module-imports
 - Including current module name as suggested.
 - Adding more tests for ambiguities.
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - ... and 10 more: https://git.openjdk.org/jdk/compare/03e84178...c75b8b7a

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=05
  Stats: 1198 lines in 29 files changed: 1130 ins; 9 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From jlahoda at openjdk.org  Wed Apr 17 15:36:01 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 15:36:01 GMT
Subject: RFR: 8328481: Implement Module Imports [v7]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <4Vd-LkZgxXvfoTGWJrlYVbIW-k1NCU3-HgCoa_y5MTU=.480aeb7e-e73e-4ab1-bdc4-4b5fb8ae9b5e@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c75b8b7a..27f9cfb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=05-06

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

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

From jlahoda at openjdk.org  Wed Apr 17 19:33:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 19:33:09 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing ListModuleDeps test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/27f9cfb5..7fa0ad51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=06-07

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

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

From alanb at openjdk.org  Thu Apr 18 05:45:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 05:45:58 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
Message-ID: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>

On Wed, 17 Apr 2024 19:33:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing ListModuleDeps test.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:

> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
> 83:         STREAM_GATHERERS,
> 84:         @JEP(number=0, title="Module Imports", status="Preview")

I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570018046

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating JEP number and caption.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/7fa0ad51..432393ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=07-08

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

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

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
 <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
Message-ID: <G-3sx5-oNAcuWzF5Y26QXZuX_DvmgPJRqfMV6uF7ufI=.1fc21a6a-fa90-4f9f-baab-ba800a46a9e0@github.com>

On Thu, 18 Apr 2024 05:43:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing ListModuleDeps test.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:
> 
>> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
>> 83:         STREAM_GATHERERS,
>> 84:         @JEP(number=0, title="Module Imports", status="Preview")
> 
> I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

Done, thanks:
https://github.com/openjdk/jdk/pull/18614/commits/432393abb4ac1f5c4730d982a3911284fe866318

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570071215

From mcimadamore at openjdk.org  Thu Apr 18 10:50:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 10:50:04 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
Message-ID: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>

On Thu, 18 Apr 2024 06:34:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating JEP number and caption.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:

> 3539: # 0: symbol, 1: symbol
> 3540: compiler.err.import.module.does.not.read=\
> 3541:     {1} module does not read: {0}

shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

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

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2008496026
PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570474076

From jlahoda at openjdk.org  Thu Apr 18 12:11:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:19 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - improving the 'module (current) does not read (target).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/432393ab..846b038e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=08-09

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

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

From jlahoda at openjdk.org  Thu Apr 18 12:11:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:20 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
 <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
Message-ID: <w6eHmke7hUSdWcDyIABENw8qivz2txDkTEPDgq8uycw=.b0705162-0183-4840-89c0-259347ef83f8@github.com>

On Thu, 18 Apr 2024 10:47:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating JEP number and caption.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:
> 
>> 3539: # 0: symbol, 1: symbol
>> 3540: compiler.err.import.module.does.not.read=\
>> 3541:     {1} module does not read: {0}
> 
> shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

Thanks! Fixed:
https://github.com/openjdk/jdk/pull/18614/commits/846b038ed8145ede9c419daddedb794a429dafac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570597292

From vromero at openjdk.org  Thu Apr 18 16:57:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Apr 2024 16:57:06 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
Message-ID: <EyeV6PzOrKSObimFKpPpHvzFyg14LXpQAnguXscbuNQ=.38261d09-3c7d-4652-a4e7-c83a758ce8a3@github.com>

On Thu, 18 Apr 2024 12:11:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - improving the 'module (current) does not read (target).

src/jdk.compiler/share/classes/com/sun/source/tree/ImportTree.java line 57:

> 55:      */
> 56:     @PreviewFeature(feature=PreviewFeature.Feature.MODULE_IMPORTS, reflective=true)
> 57:     boolean isModule();

we are not including any test that stresses this new method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1571091780

From jjg at openjdk.org  Thu Apr 18 20:52:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:52:29 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v4]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <p1Ldsyr_hNrd7LEhoThBxZzXEtMZk3siO_ZLFZp43vY=.c61e1870-2db1-4ee8-b157-f6f2b0be1715@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 contains five additional commits since the last revision:

 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3f745431..f3670e7a

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

  Stats: 42074 lines in 1058 files changed: 18282 ins; 15937 del; 7855 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 18 21:34:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:34:13 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v5]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <Pw-vAt9fBf-s7YcdBbtzbYdcM49PkNcmvIfbSmYdjYI=.a94e6477-30de-463b-b509-d4cd38f26cd7@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/f3670e7a..8ad8b818

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

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

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

From jjg at openjdk.org  Thu Apr 18 21:56:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:56:16 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v6]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <_EMQ8vgc0hQdgeWdnqirLLAN8Cj6jcxP0belwJffD8A=.2c536c2b-f0e1-49b4-8fc7-e3a9252e20e2@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=05
  Stats: 488 lines in 61 files changed: 389 ins; 3 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jlahoda at openjdk.org  Fri Apr 19 13:17:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:17:18 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding test for ImportTree.isModule, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/846b038e..cbc363ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=09-10

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

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

From vromero at openjdk.org  Fri Apr 19 17:20:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Apr 2024 17:20:59 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
Message-ID: <ep0BYQNQSPvUeV-zPB0MGvuIWrdSc3huoK0IXhuU3Uc=.e531e4bf-d2f5-4956-b07f-51f292308600@github.com>

On Fri, 19 Apr 2024 13:17:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test for ImportTree.isModule, as suggested.

lgtm, thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2011974781

From hgreule at openjdk.org  Sun Apr 21 08:22:38 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 21 Apr 2024 08:22:38 GMT
Subject: Withdrawn: 8325936: jshell - crash on 'new Object().""'
In-Reply-To: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
References: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
Message-ID: <qcGLtgDOR-Ni65WoPDOXTQ-guTXkl-EXFTV7BrE7e10=.aa944f61-9ffa-44f9-9bd6-330073401471@github.com>

On Thu, 15 Feb 2024 16:55:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This fixes a crash in jshell when the target of a StringTemplate is not a processor. We only look up the `process` method if the type is actually a processor. The added test case fails without that fix.
> 
> Please let me know what you think of this fix, and if there are things that should be changed.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Mon Apr 22 18:07:51 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 18:07:51 GMT
Subject: RFR: 8330704: Clean up non-standard use of /** comments in some
 langtools tests
Message-ID: <QVSIksEb5NnF7BXfNZU26MZYFqVf0NdSgTgkKuCLF8g=.980c0320-a902-4c3f-8659-fde95fda90f6@github.com>

Please review a simple change to clean up inappropriate use of `/**` comments in test code -- most notably to enclose the `jtreg` test description.

There is no change to the functionality of any test, and (obviously) all tests continue to pass.

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

Commit messages:
 - JDK-8330704: Clean up non-standard use of /** comments in some langtools tests

Changes: https://git.openjdk.org/jdk/pull/18896/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18896&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330704
  Stats: 44 lines in 22 files changed: 0 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/18896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18896/head:pull/18896

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

From iris at openjdk.org  Mon Apr 22 18:20:28 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 22 Apr 2024 18:20:28 GMT
Subject: RFR: 8330704: Clean up non-standard use of /** comments in some
 langtools tests
In-Reply-To: <QVSIksEb5NnF7BXfNZU26MZYFqVf0NdSgTgkKuCLF8g=.980c0320-a902-4c3f-8659-fde95fda90f6@github.com>
References: <QVSIksEb5NnF7BXfNZU26MZYFqVf0NdSgTgkKuCLF8g=.980c0320-a902-4c3f-8659-fde95fda90f6@github.com>
Message-ID: <ww1vp04Xj8tCX53losUt-iPpbWt3vjzYuzqfd5b-9ig=.78d727a0-4d39-43f2-9c6b-09bcea72af2b@github.com>

On Mon, 22 Apr 2024 18:02:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change to clean up inappropriate use of `/**` comments in test code -- most notably to enclose the `jtreg` test description.
> 
> There is no change to the functionality of any test, and (obviously) all tests continue to pass.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18896#pullrequestreview-2015514289

From jjg at openjdk.org  Mon Apr 22 21:55:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 21:55:31 GMT
Subject: Integrated: 8330704: Clean up non-standard use of /** comments in some
 langtools tests
In-Reply-To: <QVSIksEb5NnF7BXfNZU26MZYFqVf0NdSgTgkKuCLF8g=.980c0320-a902-4c3f-8659-fde95fda90f6@github.com>
References: <QVSIksEb5NnF7BXfNZU26MZYFqVf0NdSgTgkKuCLF8g=.980c0320-a902-4c3f-8659-fde95fda90f6@github.com>
Message-ID: <BTXIgZcCGETmeCoV-jF2o9MN8cLRTDNQhONCNgHOvhk=.7c4e047f-362b-4e7a-9c4b-2ffe970f36bf@github.com>

On Mon, 22 Apr 2024 18:02:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change to clean up inappropriate use of `/**` comments in test code -- most notably to enclose the `jtreg` test description.
> 
> There is no change to the functionality of any test, and (obviously) all tests continue to pass.

This pull request has now been integrated.

Changeset: 1d52234e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d52234e199c7a38c059c0aa88aea2910f749d48
Stats:     44 lines in 22 files changed: 0 ins; 0 del; 44 mod

8330704: Clean up non-standard use of /** comments in some langtools tests

Reviewed-by: iris

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

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

From asotona at openjdk.org  Tue Apr 23 09:23:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 09:23:49 GMT
Subject: RFR: 8326150: Typo in the documentation for jdk.jshell
Message-ID: <7Se15gzVgEJWzaQOy09JDhtGKKUBSbJWX9iq1vC5-OA=.0bb23733-d69c-476f-90fa-2b17d7f3c9c5@github.com>

This patch fixes typo in the jdk.jshell module-info.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8326150: Typo in the documentation for jdk.jshell

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

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

From jlahoda at openjdk.org  Tue Apr 23 09:51:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Apr 2024 09:51:27 GMT
Subject: RFR: 8326150: Typo in the documentation for jdk.jshell
In-Reply-To: <7Se15gzVgEJWzaQOy09JDhtGKKUBSbJWX9iq1vC5-OA=.0bb23733-d69c-476f-90fa-2b17d7f3c9c5@github.com>
References: <7Se15gzVgEJWzaQOy09JDhtGKKUBSbJWX9iq1vC5-OA=.0bb23733-d69c-476f-90fa-2b17d7f3c9c5@github.com>
Message-ID: <7UQkYeYSwwjDlvTf93zo0aDstWRNX6NHwL9eEP56n38=.22a1d925-562c-4ed6-b980-9ad3285d43fc@github.com>

On Tue, 23 Apr 2024 09:19:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch fixes typo in the jdk.jshell module-info.
> 
> Please review.
> 
> Thank you,
> Adam

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18909#pullrequestreview-2016774729

From jlahoda at openjdk.org  Tue Apr 23 09:52:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Apr 2024 09:52:37 GMT
Subject: RFR: 8328703: Illegal accesses in
 Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
Message-ID: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>

There is a structure called `winsize`, that is read on Linux and Mac to get the size of the terminal. This is part of JLine, which we use. This structure has fields of type `short`. But, our native counterpart (which is not from JLine, because JLine uses JNA to retrieve the values) uses `GetIntField`/`SetIntField` to access the data.

This patch fixes that to use `GetShortField`/`SetShortField`.

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

Commit messages:
 - Adjusting MacOSX code as well.
 - 8328703: Illegal accesses in Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0

Changes: https://git.openjdk.org/jdk/pull/18910/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328703
  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18910/head:pull/18910

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

From asotona at openjdk.org  Tue Apr 23 11:00:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 11:00:29 GMT
Subject: RFR: 8328703: Illegal accesses in
 Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
In-Reply-To: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
References: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
Message-ID: <Fr1yA3RKFboCcCDrcrKMcmv0OQBTa_-qcOEGGqNQAtQ=.bf5bac9b-6b8a-401f-895e-2864aa9e8c3c@github.com>

On Tue, 23 Apr 2024 09:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a structure called `winsize`, that is read on Linux and Mac to get the size of the terminal. This is part of JLine, which we use. This structure has fields of type `short`. But, our native counterpart (which is not from JLine, because JLine uses JNA to retrieve the values) uses `GetIntField`/`SetIntField` to access the data.
> 
> This patch fixes that to use `GetShortField`/`SetShortField`.

Looks good to me

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18910#pullrequestreview-2016911795

From asotona at openjdk.org  Tue Apr 23 11:09:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 11:09:32 GMT
Subject: RFR: 8327512: JShell does not work correctly when a class named
 Object or Throwable is defined
In-Reply-To: <jck9GjGrtUoS_RXDGhyXr6msyMolMUK9SXbQ28Dxkl0=.8d96a71c-4efb-4883-ab79-21024e1dd9a8@github.com>
References: <jck9GjGrtUoS_RXDGhyXr6msyMolMUK9SXbQ28Dxkl0=.8d96a71c-4efb-4883-ab79-21024e1dd9a8@github.com>
Message-ID: <yyLfaVMqEBmDKD1Km0X930_QkS_uNsmAEoUfmU1nZOk=.b7d0fe63-2543-4124-b461-dda7ff11a961@github.com>

On Thu, 14 Mar 2024 10:22:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell wraps the user's snippets with additional code to make the standalone compilable units, it uses simple names to refer to `Object`, `Throwable` or `SuppressWarnings` in some cases. These may interact with user-defined class of the same names, leading to error while running the next snippet. E.g.:
> 
> jshell> class Object{}
> |  created class Object
> 
> jshell> 1
> |  Error:
> |  incompatible types: int cannot be converted to Object
> |  1
> |  ^
> 
> 
> The proposal here is to use qualified names when creating the snippet wrappers, and to more carefully produce simple names when analyzing expressions (fully qualified names should be used when a class with the same simple name has been introduced in a snippet).

Looks good to me

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18295#pullrequestreview-2016928472

From asotona at openjdk.org  Tue Apr 23 11:10:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 11:10:35 GMT
Subject: Integrated: 8326150: Typo in the documentation for jdk.jshell
In-Reply-To: <7Se15gzVgEJWzaQOy09JDhtGKKUBSbJWX9iq1vC5-OA=.0bb23733-d69c-476f-90fa-2b17d7f3c9c5@github.com>
References: <7Se15gzVgEJWzaQOy09JDhtGKKUBSbJWX9iq1vC5-OA=.0bb23733-d69c-476f-90fa-2b17d7f3c9c5@github.com>
Message-ID: <rhV0BpQDHA3JQjY8cHSvWt3Kb5YTBhrQOKH0uSxjRh8=.51d62e74-9beb-48c2-8c6c-11682cdce19d@github.com>

On Tue, 23 Apr 2024 09:19:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch fixes typo in the jdk.jshell module-info.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 3bd6982e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bd6982ec3dd48970450cc0da9c25d755924f449
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8326150: Typo in the documentation for jdk.jshell

Reviewed-by: jlahoda

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

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

From shade at openjdk.org  Tue Apr 23 11:45:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Apr 2024 11:45:31 GMT
Subject: RFR: 8328703: Illegal accesses in
 Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
In-Reply-To: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
References: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
Message-ID: <XgScnNngwHzryjW4HtyiPC1PJXTlzyXCxuzJACL_t0E=.d596fb6b-999e-467b-ab42-548d3dfcff95@github.com>

On Tue, 23 Apr 2024 09:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a structure called `winsize`, that is read on Linux and Mac to get the size of the terminal. This is part of JLine, which we use. This structure has fields of type `short`. But, our native counterpart (which is not from JLine, because JLine uses JNA to retrieve the values) uses `GetIntField`/`SetIntField` to access the data.
> 
> This patch fixes that to use `GetShortField`/`SetShortField`.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18910#pullrequestreview-2016998679

From jlahoda at openjdk.org  Tue Apr 23 20:06:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Apr 2024 20:06:43 GMT
Subject: RFR: 8328481: Implement Module Imports [v12]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <-ouD9nIv2qwF1P1KJmrFi8K-WKx3wdrzx4qcT5BxN6M=.19abc97e-05b9-47ac-8620-aa0121bbb27c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing Imports test on Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/cbc363ab..1a621447

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=10-11

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

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

From jjg at openjdk.org  Tue Apr 23 20:26:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 20:26:57 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v7]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <RHregxT5ye-XTQEWzPqLPVZXgm2Id82FV--QqNLAJMc=.4c5c4e64-3a6c-438f-a877-e6f9689986fd@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=06
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Tue Apr 23 23:25:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 23:25:38 GMT
Subject: RFR: 8331018: Clean up non-standard use of /** comments in
 `jdk.jshell`
Message-ID: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>

Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new javac lint warning to detect documentation comments in unusual places.

The comments here are all one-line comments of the form `/***** message ****/`.

Following the style of an existing similar comment, the comments are changed to the form `//***** message *****`
That existing comment is in Snippet.java:648

    //**** internal access ****
    String name() {
        return unitName;
    }

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

Commit messages:
 - JDK-8331018: Clean up non-standard use of /** comments in `jdk.jshell`

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

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

From iris at openjdk.org  Wed Apr 24 01:37:35 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 24 Apr 2024 01:37:35 GMT
Subject: RFR: 8331018: Clean up non-standard use of /** comments in
 `jdk.jshell`
In-Reply-To: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
References: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
Message-ID: <VCKax_KgaUSyVAIz5vMIzdb62KJlRLhfn0qFHK4L3yw=.dbe09abf-4913-4ca6-a870-b9cf9e926a1f@github.com>

On Tue, 23 Apr 2024 23:19:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new javac lint warning to detect documentation comments in unusual places.
> 
> The comments here are all one-line comments of the form `/***** message ****/`.
> 
> Following the style of an existing similar comment, the comments are changed to the form `//***** message *****`
> That existing comment is in Snippet.java:648
> 
>     //**** internal access ****
>     String name() {
>         return unitName;
>     }

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18926#pullrequestreview-2018615207

From darcy at openjdk.org  Wed Apr 24 03:01:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Apr 2024 03:01:31 GMT
Subject: RFR: 8331018: Clean up non-standard use of /** comments in
 `jdk.jshell`
In-Reply-To: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
References: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
Message-ID: <Ir731zEpJ1794xNUhY-MiWjsmR9i4N4lxHvla60K96I=.7c422d76-541a-4389-82f7-6bb8929c9f07@github.com>

On Tue, 23 Apr 2024 23:19:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new javac lint warning to detect documentation comments in unusual places.
> 
> The comments here are all one-line comments of the form `/***** message ****/`.
> 
> Following the style of an existing similar comment, the comments are changed to the form `//***** message *****`
> That existing comment is in Snippet.java:648
> 
>     //**** internal access ****
>     String name() {
>         return unitName;
>     }

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18926#pullrequestreview-2018718567

From jlahoda at openjdk.org  Wed Apr 24 06:07:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Apr 2024 06:07:28 GMT
Subject: RFR: 8331018: Clean up non-standard use of /** comments in
 `jdk.jshell`
In-Reply-To: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
References: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
Message-ID: <9_QEf8_BPOhW274hq_MtT3RhsoCo9I8C0nHIHkuK-Eg=.9d10af79-1efa-4cc7-816f-69f62693f450@github.com>

On Tue, 23 Apr 2024 23:19:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new javac lint warning to detect documentation comments in unusual places.
> 
> The comments here are all one-line comments of the form `/***** message ****/`.
> 
> Following the style of an existing similar comment, the comments are changed to the form `//***** message *****`
> That existing comment is in Snippet.java:648
> 
>     //**** internal access ****
>     String name() {
>         return unitName;
>     }

Look OK to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18926#pullrequestreview-2018921702

From naoto at openjdk.org  Wed Apr 24 17:20:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 Apr 2024 17:20:42 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
Message-ID: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>

Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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

Commit messages:
 - Not using System.err
 - spacing
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/18923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330276
  Stats: 370 lines in 7 files changed: 289 ins; 0 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From jjg at openjdk.org  Wed Apr 24 20:48:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Apr 2024 20:48:34 GMT
Subject: Integrated: 8331018: Clean up non-standard use of /** comments in
 `jdk.jshell`
In-Reply-To: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
References: <yK8BNbPzEFMVD9ZuhcVm5IEPMChIDrBDfh6vCj60MCg=.9b5ff3f3-6935-4e44-b3f3-572992940c56@github.com>
Message-ID: <D-c7CYYR-EV-tyYR3v--MV9aO5egLWBknFuhZkmDQds=.dd58bb21-3cd7-4ce1-80aa-d0bd80c0e5c4@github.com>

On Tue, 23 Apr 2024 23:19:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new javac lint warning to detect documentation comments in unusual places.
> 
> The comments here are all one-line comments of the form `/***** message ****/`.
> 
> Following the style of an existing similar comment, the comments are changed to the form `//***** message *****`
> That existing comment is in Snippet.java:648
> 
>     //**** internal access ****
>     String name() {
>         return unitName;
>     }

This pull request has now been integrated.

Changeset: e6118ce7
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6118ce784342e1f1996f1569cf636a6b435145d
Stats:     7 lines in 7 files changed: 0 ins; 0 del; 7 mod

8331018: Clean up non-standard use of /** comments in `jdk.jshell`

Reviewed-by: iris, darcy, jlahoda

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

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

From jlahoda at openjdk.org  Thu Apr 25 08:14:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 25 Apr 2024 08:14:34 GMT
Subject: Integrated: 8328703: Illegal accesses in
 Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
In-Reply-To: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
References: <dU-ggTOPOmE5kmMNMLSa8sMs4LRMNF7g_s9OP4YK3do=.73ddda47-2cf2-48d0-ab83-647c16af8f11@github.com>
Message-ID: <PDf9qnkhnanBIDKnjReLNzEVsoOfx7k-eGN03JeeGPQ=.d82aad06-cad4-47c4-8e15-80d1e3b5a98b@github.com>

On Tue, 23 Apr 2024 09:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a structure called `winsize`, that is read on Linux and Mac to get the size of the terminal. This is part of JLine, which we use. This structure has fields of type `short`. But, our native counterpart (which is not from JLine, because JLine uses JNA to retrieve the values) uses `GetIntField`/`SetIntField` to access the data.
> 
> This patch fixes that to use `GetShortField`/`SetShortField`.

This pull request has now been integrated.

Changeset: 87e864bf
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87e864bf21d71daae4e001ec4edbb4ef1f60c36d
Stats:     16 lines in 2 files changed: 0 ins; 0 del; 16 mod

8328703: Illegal accesses in Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0

Reviewed-by: asotona, shade

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

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

From jjg at openjdk.org  Thu Apr 25 22:53:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 22:53:04 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v8]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <l0Wf7Ng-zjDRAZwhsOY9wf2dytL6ctdsMmLCL3tkgdc=.670a964c-af86-4c75-9d5a-4f6e479ac598@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1c238d43...16a265a2

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 25 23:24:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 23:24:07 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert need to disable warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/16a265a2..39689a52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07-08

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

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

From vromero at openjdk.org  Fri Apr 26 00:23:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 00:23:33 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
Message-ID: <txquEDIJ7YBKTZ6-EggzWEHSYzFxMXIBbwTuexdYXro=.af5bb232-dbd4-4099-9fc7-3bc22aacdd07@github.com>

On Thu, 25 Apr 2024 23:24:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert need to disable warning

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 583:

> 581:      *     dangling comments are also attached to the tree node
> 582:      *     by registering them using the {@link #deferredLintHandler}.
> 583:      *  5. (Later) Warnings may be genereated for the dangling

typo: generated

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2023792395
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1580263826

From jlahoda at openjdk.org  Fri Apr 26 07:26:40 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 26 Apr 2024 07:26:40 GMT
Subject: Integrated: 8327512: JShell does not work correctly when a class named
 Object or Throwable is defined
In-Reply-To: <jck9GjGrtUoS_RXDGhyXr6msyMolMUK9SXbQ28Dxkl0=.8d96a71c-4efb-4883-ab79-21024e1dd9a8@github.com>
References: <jck9GjGrtUoS_RXDGhyXr6msyMolMUK9SXbQ28Dxkl0=.8d96a71c-4efb-4883-ab79-21024e1dd9a8@github.com>
Message-ID: <ZsnpnK3RPfdG64skXhF6GFnspuZt9ZimjITxQSYiVRY=.0ff7dada-887c-4dac-bc87-f082b93946b0@github.com>

On Thu, 14 Mar 2024 10:22:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell wraps the user's snippets with additional code to make the standalone compilable units, it uses simple names to refer to `Object`, `Throwable` or `SuppressWarnings` in some cases. These may interact with user-defined class of the same names, leading to error while running the next snippet. E.g.:
> 
> jshell> class Object{}
> |  created class Object
> 
> jshell> 1
> |  Error:
> |  incompatible types: int cannot be converted to Object
> |  1
> |  ^
> 
> 
> The proposal here is to use qualified names when creating the snippet wrappers, and to more carefully produce simple names when analyzing expressions (fully qualified names should be used when a class with the same simple name has been introduced in a snippet).

This pull request has now been integrated.

Changeset: a407dc9c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a407dc9cbb48c4f66af51433067925605d3bc39d
Stats:     82 lines in 6 files changed: 74 ins; 0 del; 8 mod

8327512: JShell does not work correctly when a class named Object or Throwable is defined

Reviewed-by: asotona

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

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

From jjg at openjdk.org  Fri Apr 26 16:04:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 16:04:09 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/39689a52..48e8b0a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=08-09

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

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

From prr at openjdk.org  Fri Apr 26 19:34:00 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:34:00 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
Message-ID: <SD0S716mdRSViTfaViQgFYEkmR7WmBalQQe3_FI7VQc=.b83407a8-0c84-4ed9-8b56-adf6db1a2e0c@github.com>

On Fri, 26 Apr 2024 16:04:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2025744069

From jjg at openjdk.org  Fri Apr 26 19:49:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 19:49:56 GMT
Subject: Integrated: 8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <jz5iSs8rS6B9ZP2l3HbT7UR9gdQiXvxyQFGqikRLN7U=.584799e9-55c0-4a22-b62f-e30406cfe8ea@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

This pull request has now been integrated.

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a920af233a11592af113f456f7608cb59dd1617e
Stats:     482 lines in 58 files changed: 385 ins; 3 del; 94 mod

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

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

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

From jlahoda at openjdk.org  Mon Apr 29 11:49:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 11:49:30 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected
Message-ID: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>

Consider code like:

public class ConsoleTest {
    public static void main(String... args) {
        System.console().printf("Hello!");
    }
}


When run as:

$ java ConsoleTest.java >/dev/null


it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).

The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.

The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

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

Commit messages:
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

Changes: https://git.openjdk.org/jdk/pull/18996/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330998
  Stats: 212 lines in 3 files changed: 209 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

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

From jlahoda at openjdk.org  Mon Apr 29 14:56:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 14:56:23 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

Jan Lahoda 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 contains six additional commits since the last revision:

 - Merge branch 'master' into JDK-8330998
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18996/files
  - new: https://git.openjdk.org/jdk/pull/18996/files/9090e4c7..8a918e3f

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

  Stats: 22740 lines in 1516 files changed: 8365 ins; 10464 del; 3911 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

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

From naoto at openjdk.org  Mon Apr 29 18:44:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 18:44:09 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
Message-ID: <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>

On Mon, 29 Apr 2024 14:56:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda 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 contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8330998
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

Looks good to me. Left some minor suggestions.
BTW, should we file an issue at the `JLine` project, not to redirect to stderr, or suggest a new config (sorry if it has already been taken care of)?

test/jdk/jdk/internal/jline/RedirectedStdOut.java line 29:

> 27:  * @summary Verify that even if the stdout is redirected java.io.Console will
> 28:  *          use it for writing.
> 29:  * @run main RedirectedStdOut runRedirectAllTest

`@modules jdk.internal.le` is needed, as the test relies on it.

test/jdk/jdk/internal/jline/RedirectedStdOut.java line 59:

> 57:     void runRedirectAllTest() throws Exception {
> 58:         String testJDK = System.getProperty("test.jdk");
> 59:         Path javaLauncher = Path.of(testJDK, "bin", "java");

Could utilize `ProcessTools` test library to start the test jdk process (applies to the other location as well)

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

PR Review: https://git.openjdk.org/jdk/pull/18996#pullrequestreview-2029297831
PR Review Comment: https://git.openjdk.org/jdk/pull/18996#discussion_r1583564260
PR Review Comment: https://git.openjdk.org/jdk/pull/18996#discussion_r1583565422

From duke at openjdk.org  Mon Apr 29 19:55:07 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 29 Apr 2024 19:55:07 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
Message-ID: <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>

On Mon, 29 Apr 2024 14:56:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda 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 contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8330998
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

I think it's a feature when System.console() actually writes to the tty if stdout is redirected. After all it's not System.out. Of course the question is if it should write to stderr or /dev/tty like mechanism..

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2083542510

From acobbs at openjdk.org  Mon Apr 29 20:24:06 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 29 Apr 2024 20:24:06 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
Message-ID: <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>

On Mon, 29 Apr 2024 19:52:17 GMT, Bernd <duke at openjdk.org> wrote:

> Of course the question is if it should write to stderr or /dev/tty like mechanism..

I was wondering the same thing. My understanding of the definition of "console" is a bidirectional byte channel with a keyboard & screen on the other end. It has no concept of stdout vs. stderr. It just has a display (or in the old days, a printer).

The function of a "shell" is to intermediate between one or more executing programs and the console. It figures out how & when to actually display on the console any stuff written to stdout and/or stderr by one of the programs it has launched.

A program can also access its console (if any) directly by opening /dev/tty or whatever, thereby bypassing the shell.

So I would think writing to something called "System.console()" from Java (which is a program) would have nothing to do with Java's stderr or stdout, except for a possible downstream interleaving with what the shell may also be writing to the console at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2083593864

From joehw at openjdk.org  Mon Apr 29 22:03:07 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 29 Apr 2024 22:03:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

src/java.base/share/classes/java/io/Console.java line 193:

> 191:      * {@code locale}.
> 192:      *
> 193:      * @param  locale locale used for formatting

Specify the behavior when locale is null?

src/java.base/share/classes/java/io/Console.java line 202:

> 200:      *         string.  If there are more arguments than format specifiers, the
> 201:      *         extra arguments are ignored.  The number of arguments is
> 202:      *         variable and may be zero.  The maximum number of arguments is

readLine and readPassword don't have this statement (The number of arguments is variable and may be zero). Is this statement helpful for those methods as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583826762
PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583828717

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/f3f879ea..7884cfe3

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

  Stats: 59 lines in 2 files changed: 43 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <z29kSvrHkMxIcvuVn1oAno8jbaYgNKrZn3YD1pGsiU4=.002368f8-3e6d-424e-9a6c-66093e53b664@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Thanks, Joe. Addressed your points (and updated the test case accordingly)

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

PR Comment: https://git.openjdk.org/jdk/pull/18923#issuecomment-2083846171

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>
Message-ID: <ZEI5YcUW4cDIO8n2JSsN29Hb3i0KuojmubOtZfAp7Z0=.51ab0d1d-e17c-4e7e-8b8e-32207ec2980a@github.com>

On Mon, 29 Apr 2024 21:54:55 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> src/java.base/share/classes/java/io/Console.java line 193:
> 
>> 191:      * {@code locale}.
>> 192:      *
>> 193:      * @param  locale locale used for formatting
> 
> Specify the behavior when locale is null?

Good point. Brought the same wording from `String.format`

> src/java.base/share/classes/java/io/Console.java line 202:
> 
>> 200:      *         string.  If there are more arguments than format specifiers, the
>> 201:      *         extra arguments are ignored.  The number of arguments is
>> 202:      *         variable and may be zero.  The maximum number of arguments is
> 
> readLine and readPassword don't have this statement (The number of arguments is variable and may be zero). Is this statement helpful for those methods as well?

Modified each description for `args` consistently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583891641
PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583892038

From joehw at openjdk.org  Tue Apr 30 02:00:05 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 30 Apr 2024 02:00:05 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <6Nbii0WAObqlOoZUOLRmt6fujcqMO3OXbuBgMuUPX9Y=.2b690e57-d92b-449a-9ea9-a5637034ba9c@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Thanks for the update. Changes look good to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2030033024

From jlahoda at openjdk.org  Tue Apr 30 14:04:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Apr 2024 14:04:05 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
 <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
Message-ID: <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>

On Mon, 29 Apr 2024 20:21:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Of course the question is if it should write to stderr or /dev/tty like mechanism..
> 
> I was wondering the same thing. My understanding of the definition of "console" is a bidirectional byte channel with a keyboard & screen on the other end. It has no concept of stdout vs. stderr. It just has a display (or in the old days, a printer).
> 
> The function of a "shell" is to intermediate between one or more executing programs and the console. It figures out how & when to actually display on the console any stuff written to stdout and/or stderr by one of the programs it has launched.
> 
> A program can also access its console (if any) directly by opening /dev/tty or whatever, thereby bypassing the shell.
> 
> So I would think writing to something called "System.console()" from Java (which is a program) would have nothing to do with Java's stderr or stdout, except for a possible downstream interleaving with what the shell may also be writing to the console at the same time.

I tried a few programs, like `mc`, `top` and `htop`. When I redirect the stdout for them, they still write into it (and there's obviously nothing on the terminal, and there are escape sequences in the target file of the redirect). The only program I know from the top of my head that (AFAIK) bypasses stdin/stdout and reaches directly to the controlling terminal is `ssh` when reading passwords (for quite obvious very special reasons).

I.e. not trying to be too smart about output, and simply using stdout as other programs do seems consistent, and most useful - the output can then be used in pipes, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2085419986

From acobbs at openjdk.org  Tue Apr 30 14:56:04 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 Apr 2024 14:56:04 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
 <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
 <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>
Message-ID: <y8sfYX4NzjvsKtgosTxwJByWwjjf20ftFxIxCkRy2GM=.230fcdd7-677d-43d2-96c6-e0e9759d827f@github.com>

On Tue, 30 Apr 2024 14:01:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I.e. not trying to be too smart about output, and simply using stdout as other programs do seems consistent, and most useful - the output can then be used in pipes, etc.

Totally reasonable. But the ssh example is telling - suppose for example someone wanted to implement something like ssh in Java. Would that person expect to be able to do what ssh does (accepting non-echoed passwords) by using `System.console()` ?

In other words, what exactly is `System.console()` supposed to represent? Maybe that question pinpoints the source of the ambiguity here. Of course, it will differ by O/S which adds to the challenge.

These questions are probably beyond the scope of this PR but you've got me curious :)

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2085559962

From jlahoda at openjdk.org  Tue Apr 30 15:02:21 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Apr 2024 15:02:21 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v3]
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting test, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18996/files
  - new: https://git.openjdk.org/jdk/pull/18996/files/8a918e3f..76599ac9

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

  Stats: 57 lines in 1 file changed: 6 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

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