From nbenalla at openjdk.org  Tue Jul  1 11:35:42 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 1 Jul 2025 11:35:42 GMT
Subject: RFR: 8346884: Add since checker test to jdk.editpad
In-Reply-To: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <oAVD1Fs3cbeNnwB7JZLuA8bdwxLOrz5TPJt5dHexbJ0=.02f18eca-0b56-43e5-bb3b-d192651295f6@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module.
> 
> TIA

keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/25613#issuecomment-3023556036

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after
 attribution
Message-ID: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>

This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.

A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.

In addition, several other factors complicate things:
* Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
* Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
* Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
* Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
* Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
* Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
* Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.

Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".

The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

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

Commit messages:
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Merge branch 'master' into MandatoryWarningCleanup
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - Apply some review suggestions.
 - ... and 76 more: https://git.openjdk.org/jdk/compare/25ed36f3...ec02990a

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348611
  Stats: 1999 lines in 57 files changed: 1065 ins; 587 del; 347 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <DjwL7B3A49wsthxqPnQUB-JrtEy15CpEzRDYZOE6AgQ=.62dbff04-cb76-4049-97d9-03fb8e7bbb51@github.com>

On Thu, 10 Apr 2025 20:23:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Goals:

* Eliminate `DeferredLintHandler` and the requirement for code to configure and use it in order to log warnings
* Allow all warnings to be logged via `log.warning()` without having to know if/how `@SuppressWarnings` might apply
* Eliminate (mostly) the need for manual `Lint` instance manipulation

Design overview:

* Maintain mappings from source code position to `Lint` configuration in the `LintMapper` class
* Notify `LintMapper` when attribution completes so `Lint` configurations can be updated
* Hold/defer lint warnings in `Log.DiagnosticHandler` if the `Lint` configuration is not yet known
* Notify `Log` when held/deferred warnings should be reconsidered and flushed

Patch overview:
* `LintMapper.java`, `Log.java` - Replacing the functionality of `DeferredLintHandler` as described above
* `JavacTrees.java` - Add a couple of missing calls to `Log.useSource()`
* Other `src` classes - Derivative changes and cleanups/code removal
* `test` classes - Warning/error reorderings, plus a few new tests

Recommend ignoring whitespace when viewing the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-2835563690

From cstein at openjdk.org  Fri Jul  4 11:05:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Jul 2025 11:05:19 GMT
Subject: RFR: 8358552: EndOfFileException in System.in.read() and
 IO.readln() etc. in JShell [v2]
In-Reply-To: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
References: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
Message-ID: <QfM_y5UjGHopMDyqJ6MUZYH9Ilpd-SlJxGM5EQ8rhro=.0bf245ca-b4c0-4ee2-9bee-aaeaf8846f02@github.com>

> Please review this change to handle an `EndOfFileException` while reading input from a user console in such a way, that no stacktrace is emitted. The handling of the `Ctrl+D` command is left as-is; here the following underlying core-libs should stay in control:
> 
>  - `System.in.read()`
>  - `System.console().reader().read()`
>  - `System.console().readLine()`
>  - `System.console().readPassword()`
>  - `System.in.readAllBytes()`
>  - `IO.readln()`

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Attempting to tweak behavior
 - 8358552: EndOfFileException in System.in.read() and IO.readln() etc. in JShell

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

Changes: https://git.openjdk.org/jdk/pull/25713/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25713&range=01
  Stats: 96 lines in 6 files changed: 64 ins; 5 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25713/head:pull/25713

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

From cstein at openjdk.org  Fri Jul  4 13:27:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 4 Jul 2025 13:27:41 GMT
Subject: RFR: 8358552: EndOfFileException in System.in.read() and
 IO.readln() etc. in JShell [v2]
In-Reply-To: <41KLHstELyXrWp7ErJU59UIzTb2MyiKmlf0dr9mUs0U=.0d6ed7ce-9330-4a77-bf03-94515240f530@github.com>
References: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
 <41KLHstELyXrWp7ErJU59UIzTb2MyiKmlf0dr9mUs0U=.0d6ed7ce-9330-4a77-bf03-94515240f530@github.com>
Message-ID: <CZBW_BmmPp1By6q65a1gELYwEZdLWnASjr1TwYNxkAI=.632786cb-569d-4e97-8faa-984c57086d1c@github.com>

On Mon, 30 Jun 2025 07:22:34 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Attempting to tweak behavior
>>  - 8358552: EndOfFileException in System.in.read() and IO.readln() etc. in JShell
>
> test/langtools/jdk/jshell/InputUITest.java line 78:
> 
>> 76:                 "System.console().readPassword()",  " ==> null",
>> 77:                 "IO.readln()",                      " ==> \"null\""
>> 78:                 // TODO , "System.in.readAllBytes()", " ==> " // ... hangs forever
> 
> Manual testing in a JShell session with this change set applied shows the watend behaviour: breaks with Ctrl+C and no exception is printed for Ctrl+D

Now also works as expected after @lahodaj's tweaks. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25713#discussion_r2185374317

From jlahoda at openjdk.org  Fri Jul  4 15:30:39 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 15:30:39 GMT
Subject: RFR: 8358552: EndOfFileException in System.in.read() and
 IO.readln() etc. in JShell [v2]
In-Reply-To: <QfM_y5UjGHopMDyqJ6MUZYH9Ilpd-SlJxGM5EQ8rhro=.0bf245ca-b4c0-4ee2-9bee-aaeaf8846f02@github.com>
References: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
 <QfM_y5UjGHopMDyqJ6MUZYH9Ilpd-SlJxGM5EQ8rhro=.0bf245ca-b4c0-4ee2-9bee-aaeaf8846f02@github.com>
Message-ID: <R2P-4HoZ_cF5jU1XgfDF-LCMc58fMv5hQhtuyezR8MI=.219efebf-f56f-4497-b015-f40eebf43fa5@github.com>

On Fri, 4 Jul 2025 11:05:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to handle an `EndOfFileException` while reading input from a user console in such a way, that no stacktrace is emitted. The handling of the `Ctrl+D` command is left as-is; here the following underlying core-libs should stay in control:
>> 
>>  - `System.in.read()`
>>  - `System.console().reader().read()`
>>  - `System.console().readLine()`
>>  - `System.console().readPassword()`
>>  - `System.in.readAllBytes()`
>>  - `IO.readln()`
>
> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Attempting to tweak behavior
>  - 8358552: EndOfFileException in System.in.read() and IO.readln() etc. in JShell

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25713#pullrequestreview-2987687147

From jlahoda at openjdk.org  Fri Jul  4 17:37:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 17:37:58 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions
Message-ID: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>

JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.

There are two problems with this background task:
- the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
- the module path is not included in the list of paths to paths to search

This PR proposes to:
- use FileManager configured by passing the compile options through javac
- include the module path in the search path

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

Commit messages:
 - Correcting handling of modular paths.
 - Improving test reliability.
 - 8177650: JShell tool: packages in classpath don't appear in completions

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

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

From cstein at openjdk.org  Mon Jul  7 09:02:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Jul 2025 09:02:44 GMT
Subject: Integrated: 8358552: EndOfFileException in System.in.read() and
 IO.readln() etc. in JShell
In-Reply-To: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
References: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
Message-ID: <1xdtYBf8RH0PkrVmMCy4OiUzJobC4sDCMT7p43tUvyM=.ecd8019b-7e80-4ee7-b41b-a1fd1d753310@github.com>

On Tue, 10 Jun 2025 08:29:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to handle an `EndOfFileException` while reading input from a user console in such a way, that no stacktrace is emitted. The handling of the `Ctrl+D` command is left as-is; here the following underlying core-libs should stay in control:
> 
>  - `System.in.read()`
>  - `System.console().reader().read()`
>  - `System.console().readLine()`
>  - `System.console().readPassword()`
>  - `System.in.readAllBytes()`
>  - `IO.readln()`

This pull request has now been integrated.

Changeset: 9449fea2
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9449fea2cd7aa7375f1b127e5f0d2a36ffaa1814
Stats:     96 lines in 6 files changed: 64 ins; 5 del; 27 mod

8358552: EndOfFileException in System.in.read() and IO.readln() etc. in JShell

Reviewed-by: jlahoda

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

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

From cstein at openjdk.org  Mon Jul  7 12:38:41 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Jul 2025 12:38:41 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions
In-Reply-To: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
Message-ID: <3W44S8GgYXgsMYUkySDQc7o5hUtiOA019iRvkaQ5R4g=.ac616bb4-16e3-4740-9d56-9e7f5e90905c@github.com>

On Fri, 4 Jul 2025 17:32:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
> 
> There are two problems with this background task:
> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
> - the module path is not included in the list of paths to paths to search
> 
> This PR proposes to:
> - use FileManager configured by passing the compile options through javac
> - include the module path in the search path

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26137#pullrequestreview-2993653306

From cstein at openjdk.org  Mon Jul  7 12:46:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Jul 2025 12:46:56 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions
In-Reply-To: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
Message-ID: <ORLVDbsSbPrqsoUxG5k1rvU8e7HBB8BoAQ28tF-vugQ=.e02a14da-0834-459b-a08e-df76ded1fbf3@github.com>

On Fri, 4 Jul 2025 17:32:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
> 
> There are two problems with this background task:
> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
> - the module path is not included in the list of paths to paths to search
> 
> This PR proposes to:
> - use FileManager configured by passing the compile options through javac
> - include the module path in the search path

Changes requested by cstein (Committer).

test/langtools/jdk/jshell/ToolCompletionTest.java line 196:

> 194:         Files.createDirectories(lib);
> 195:         compiler.jar(p1, jarName, "p1/p2/Test.class", "p1/p3/Test.class");
> 196:         Files.move(compiler.getPath(p1.resolve(jarName)), lib.resolve(jarName));

Suggestion:

        Files.copy(compiler.getPath(p1.resolve(jarName)), lib.resolve(jarName));


Prevent `java.nio.file.FileSystemException` on Windows:


ToolCompletionTest.d\\tool_completion_test\\dir1\\test.jar -> tool_completion_test\\lib\\test.jar: The process cannot access the file because it is being used by another process


Seems like `compiler.jar(p1, jarName, "p1/p2/Test.class", "p1/p3/Test.class");` keeps an open file handle to the created `JAR` file.

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

PR Review: https://git.openjdk.org/jdk/pull/26137#pullrequestreview-2993683578
PR Review Comment: https://git.openjdk.org/jdk/pull/26137#discussion_r2189970293

From jlahoda at openjdk.org  Mon Jul  7 13:05:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Jul 2025 13:05:28 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v2]
In-Reply-To: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
Message-ID: <mmpaUfANdsNA7aAEhRD60pGMonEDxKxcAGlByNOW9us=.c447420e-8f21-4d55-8b8c-fda1e6ba6fb7@github.com>

> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
> 
> There are two problems with this background task:
> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
> - the module path is not included in the list of paths to paths to search
> 
> This PR proposes to:
> - use FileManager configured by passing the compile options through javac
> - include the module path in the search path

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

  Avoiding problems with locked files on Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26137/files
  - new: https://git.openjdk.org/jdk/pull/26137/files/ec2dcb89..54eed125

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

  Stats: 10 lines in 2 files changed: 7 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26137/head:pull/26137

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

From cstein at openjdk.org  Mon Jul  7 13:09:43 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Jul 2025 13:09:43 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v2]
In-Reply-To: <ORLVDbsSbPrqsoUxG5k1rvU8e7HBB8BoAQ28tF-vugQ=.e02a14da-0834-459b-a08e-df76ded1fbf3@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
 <ORLVDbsSbPrqsoUxG5k1rvU8e7HBB8BoAQ28tF-vugQ=.e02a14da-0834-459b-a08e-df76ded1fbf3@github.com>
Message-ID: <boBCx3SeiZSyqRy8_2IsPZ01qXMhUUF-1uzDSLsLxx8=.c912b3ca-7413-40a6-a45c-813225b330de@github.com>

On Mon, 7 Jul 2025 12:43:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoiding problems with locked files on Windows.
>
> test/langtools/jdk/jshell/ToolCompletionTest.java line 196:
> 
>> 194:         Files.createDirectories(lib);
>> 195:         compiler.jar(p1, jarName, "p1/p2/Test.class", "p1/p3/Test.class");
>> 196:         Files.move(compiler.getPath(p1.resolve(jarName)), lib.resolve(jarName));
> 
> Suggestion:
> 
>         Files.copy(compiler.getPath(p1.resolve(jarName)), lib.resolve(jarName));
> 
> 
> Prevent `java.nio.file.FileSystemException` on Windows:
> 
> 
> ToolCompletionTest.d\\tool_completion_test\\dir1\\test.jar -> tool_completion_test\\lib\\test.jar: The process cannot access the file because it is being used by another process
> 
> 
> Seems like `compiler.jar(p1, jarName, "p1/p2/Test.class", "p1/p3/Test.class");` keeps an open file handle to the created `JAR` file.

Superseded by https://github.com/openjdk/jdk/pull/26137/commits/54eed125f92aeb016502a8c06b2f284d4e4d4ded

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26137#discussion_r2190028046

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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