From jlu at openjdk.org  Tue Aug  1 23:19:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Aug 2023 23:19:58 GMT
Subject: Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <J-7QWUZ9dqBcFUe2nYIM8YKFKqgzot9vDiiIAzuwmoo=.08144cb7-7a84-4b68-9d66-e89b87682b88@github.com>

On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
> 
> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
> 
> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
> 
> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
> 
> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

This pull request has now been integrated.

Changeset: 9b55e9a7
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Wed Aug  2 17:11:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Aug 2023 17:11:07 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
Message-ID: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>

Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This change is required to keep the localized translations up to date with the English source resource files.

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

Commit messages:
 - Backport 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

Changes: https://git.openjdk.org/jdk21/pull/160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312572
  Stats: 223 lines in 32 files changed: 36 ins; 15 del; 172 mod
  Patch: https://git.openjdk.org/jdk21/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/160/head:pull/160

PR: https://git.openjdk.org/jdk21/pull/160

From naoto at openjdk.org  Wed Aug  2 17:46:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Aug 2023 17:46:53 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <0qmatseGr9WvMxmSIZhofWEmd4usRDuDVJqqsKl2pI0=.56d1c812-a9ab-4b22-88cf-9183fca693ba@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559541428

From iris at openjdk.org  Wed Aug  2 18:23:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 2 Aug 2023 18:23:57 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <O9s7CY1Q5EhtKtkkRGQVZWjNzLIBmk9Qh0k-4AS9BC0=.90c29ca1-8fdf-4501-846a-3c24a5b3cd83@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559601318

From jlu at openjdk.org  Thu Aug  3 20:52:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Aug 2023 20:52:41 GMT
Subject: [jdk21] Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <xtjzSrMie_mGi87AdfSi6ZDaEzsx4XmfSJLA3JoMTJc=.ee4f76c2-305f-4e0c-91fd-155583f69915@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

This pull request has now been integrated.

Changeset: fd789db5
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/fd789db510181886ffd3aa36ab06389a76d53e0b
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto, iris
Backport-of: 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

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

PR: https://git.openjdk.org/jdk21/pull/160

From jlahoda at openjdk.org  Mon Aug  7 10:59:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Aug 2023 10:59:18 GMT
Subject: RFR: 8313792: Verify 4th party information in
 src/jdk.internal.le/share/legal/jline.md
Message-ID: <VeGVSAhpOjrQfjjlodPdJqwF9ArhHfTzXaRYBz6f8Sc=.c838e600-b0c2-4f44-8211-1cb4fa6b924f@github.com>

The license file for JLine should only include 4-th party dependencies that we really use, and we don't use any of the mentioned, so I propose to remove the 4-th party dependencies listed.

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

Commit messages:
 - 8313792: Verify 4th party information in src/jdk.internal.le/share/legal/jline.md

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

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

From vromero at openjdk.org  Mon Aug  7 15:15:30 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Aug 2023 15:15:30 GMT
Subject: RFR: 8313792: Verify 4th party information in
 src/jdk.internal.le/share/legal/jline.md
In-Reply-To: <VeGVSAhpOjrQfjjlodPdJqwF9ArhHfTzXaRYBz6f8Sc=.c838e600-b0c2-4f44-8211-1cb4fa6b924f@github.com>
References: <VeGVSAhpOjrQfjjlodPdJqwF9ArhHfTzXaRYBz6f8Sc=.c838e600-b0c2-4f44-8211-1cb4fa6b924f@github.com>
Message-ID: <q-G31yX1Kd07TZYWOy7MPFIwuCYT8AnujaMHtZsEOyU=.b7c69c4e-99bc-4be7-80ac-6d33fb585872@github.com>

On Mon, 7 Aug 2023 10:51:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The license file for JLine should only include 4-th party dependencies that we really use, and we don't use any of the mentioned, so I propose to remove the 4-th party dependencies listed.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15174#pullrequestreview-1565581967

From jlahoda at openjdk.org  Tue Aug  8 08:52:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Aug 2023 08:52:38 GMT
Subject: Integrated: 8313792: Verify 4th party information in
 src/jdk.internal.le/share/legal/jline.md
In-Reply-To: <VeGVSAhpOjrQfjjlodPdJqwF9ArhHfTzXaRYBz6f8Sc=.c838e600-b0c2-4f44-8211-1cb4fa6b924f@github.com>
References: <VeGVSAhpOjrQfjjlodPdJqwF9ArhHfTzXaRYBz6f8Sc=.c838e600-b0c2-4f44-8211-1cb4fa6b924f@github.com>
Message-ID: <oPWtQ04dznoKOjvCbWJSlGKgKOOc-QW-Y-6ZqIFsGFk=.c9a2dca6-13b0-450c-8967-a268d31a440e@github.com>

On Mon, 7 Aug 2023 10:51:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The license file for JLine should only include 4-th party dependencies that we really use, and we don't use any of the mentioned, so I propose to remove the 4-th party dependencies listed.

This pull request has now been integrated.

Changeset: 87a6acbe
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87a6acbeee1673526bfc5f8692e0949cb113e841
Stats:     253 lines in 1 file changed: 0 ins; 253 del; 0 mod

8313792: Verify 4th party information in src/jdk.internal.le/share/legal/jline.md

Reviewed-by: vromero

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

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

From archie.cobbs at gmail.com  Mon Aug 14 18:33:51 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 14 Aug 2023 13:33:51 -0500
Subject: Local execution - class loader & class path issues
Message-ID: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>

JShell experts,

I encountered an issue working with JShell that brings up a few questions...

Here's the story:

   - I have a running Java application. In my case, it's a web application
   running in Tomcat, but consider the general case.
   - I want to be able to connect to my running Java application via SSH
   and get a command line interface (CLI) where I can do stuff.
   - One of the commands I'd like to have is a "jshell" command which would
   fire up a JShell instance within the CLI (using local execution)
   - Within JShell I want to be able to access my application's objects,
   e.g., "com.example.MyAppSingleton.getInstance()"
      - More precisely: I want any classes visible to the current thread's
      context class loader to be visible to JShell

The last step is the tricky one for me. It seems like a reasonable thing to
want to do, but JShell seems to make it difficult.

Perhaps local execution is a bit of a neglected child... ?

Here are some observations (please correct me if I'm wrong) and a few
questions...

#0: There are two separate "paths" to worry about with JShell: the
compilation classpath and the execution class path. The first can be tested
with "com.example.MyClass" while the second can be tested with "
Class.forName("com.example.MyClass")".

#1: The --class-path flag affects both the compilation and the execution
class paths with remote execution, but only the compilation classpath with
local execution:

$ ls classes/test/Foo.class
classes/test/Foo.class
$ jshell --execution=local --class-path classes
|  Welcome to JShell -- Version 20.0.1
|  For an introduction type: /help intro

jshell> Thread.currentThread().getContextClassLoader();
$1 ==> jdk.jshell.execution.DefaultLoaderDelegate$RemoteClassLoader at 45283ce2

jshell>
Arrays.asList(((URLClassLoader)Thread.currentThread().getContextClassLoader()).getURLs())
$2 ==> []

jshell> Class.forName("test.Foo");
|  Exception java.lang.ClassNotFoundException: test.Foo

*Question*: Shouldn't LoaderDelegate.addToClasspath() have been passed the
--class-path flag at some point in the example above? JShell's L
ocalExecutionControl uses DefaultLoaderDelegate, which uses a class loader
of type DefaultLoaderDelegate.RemoteClassLoader. This would have added
classes to RemoteClassLoader's class path.

#2: The RemoteClassLoader that has the system class loader as its parent
loader, and this is not configurable. This fact combined with #1 means the
execution class path is simply not configurable with local execution,
except implicitly via JVM flags:

$ jshell --execution=local -J-classpath -Jclasses
|  Welcome to JShell -- Version 20.0.1
|  For an introduction type: /help intro

jshell> Class.forName("test.Foo");
$1 ==> class test.Foo

If you are running in a non-trivial class loader environment (e.g.,
Tomcat), using JVM flags is not feasible and so your application classes
can never be found in JShell.

*Question*: Shouldn't DefaultLoaderDelegate$RemoteClassLoader use the
current thread's context loader as its parent loader instead of defaulting
to the system class loader?

#3: Solving problem #2 would allow the execution class path to be properly
configured in any generic situation (that is, from the context class
loader). But we have the same problem for the compilation class path - so
the corresponding question is: given a class loader, how do you extract the
classpath that it's using?

This is easy if the class loader is an URLClassLoader, which most are.
Unfortunately the system class loader is not.

*Question*: Should JShell provide a way to "best effort" extract a
compilation class path from a given ClassLoader (and its parents)? It could
work for any URLClassLoader instances, but being part of the JDK it could
also take advantage of inter-module access to the system and other built-in
class loaders, which are all of type jdk.internal.loader.BuiltinClassLoader,
which has an internal URLClassPath field.

Or fix this in the JDK by defining some new interface that both
URLClassLoader and BuiltinClassLoadercould implement:

public interface HasUrlPath {
    URL[] getURLs();
}

Or: create a JavaFileManager implementation that wraps a ClassLoader (it's
been done), and modify JShell to allow configuration of an alternate
JavaFileManager (we can already do with JShell.Builder but not yet with
JavaShellToolBuilder... why not?).

Thanks for any thoughts & opinions on these questions.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230814/0021f1e1/attachment-0001.htm>

From jan.lahoda at oracle.com  Tue Aug 15 13:12:00 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 15 Aug 2023 15:12:00 +0200
Subject: Local execution - class loader & class path issues
In-Reply-To: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>
References: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>
Message-ID: <b50f1502-1568-4ffe-920e-c5715935951f@oracle.com>

On 14. 08. 23 20:33, Archie Cobbs wrote:

> JShell experts,
>
> I encountered an issue working with JShell that brings up a few 
> questions...
>
> Here's the story:
>
>   * I have a running Java application. In my case, it's a web
>     application running in Tomcat, but consider the general case.
>   * I want to be able to connect to my running Java application via
>     SSH and get a command line interface (CLI) where I can do stuff.
>   * One of the commands I'd like to have is a "jshell" command which
>     would fire up a JShell instance within the CLI (using local execution)
>   * Within JShell I want to be able to access my application's
>     objects, e.g., "com.example.MyAppSingleton.getInstance()"
>       o More precisely: I want any classes visible to the current
>         thread's context class loader to be visible to JShell
>
> The last step is the tricky one for me. It seems like a reasonable 
> thing to want to do, but JShell seems to make it difficult.
>
> Perhaps local execution is a bit of a neglected child... ?
>
> Here are some observations (please correct me if I'm wrong) and a few 
> questions...
>
> #0: There are two separate "paths" to worry about with JShell: the 
> compilation classpath and the execution class path. The first can be 
> tested with "com.example.MyClass" while the second can be tested with 
> "Class.forName("com.example.MyClass")".
>
> #1: The --class-path flag affects both the compilation and the 
> execution class paths with remote execution, but only the compilation 
> classpath with local execution:
>
> $ ls classes/test/Foo.class
> classes/test/Foo.class
> $ jshell --execution=local --class-path classes
> | ?Welcome to JShell -- Version 20.0.1
> | ?For an introduction type: /help intro
>
> jshell> Thread.currentThread().getContextClassLoader();
> $1 ==> 
> jdk.jshell.execution.DefaultLoaderDelegate$RemoteClassLoader at 45283ce2
>
> jshell> 
> Arrays.asList(((URLClassLoader)Thread.currentThread().getContextClassLoader()).getURLs())
> $2 ==> []
>
> jshell> Class.forName("test.Foo");
> | ?Exception java.lang.ClassNotFoundException: test.Foo
>
> *Question*: Shouldn't LoaderDelegate.addToClasspath() have been passed 
> the --class-path flag at some point in the example above? JShell's 
> LocalExecutionControl uses DefaultLoaderDelegate, which uses a class 
> loader of type DefaultLoaderDelegate.RemoteClassLoader. This would 
> have added classes to RemoteClassLoader's class path.


Possibly.


>
> #2: The RemoteClassLoader that has the system class loader as its 
> parent loader, and this is not configurable. This fact combined with 
> #1 means the execution class path is simply not configurable with 
> local execution, except implicitly via JVM flags:
>
> $ jshell --execution=local -J-classpath -Jclasses
> | ?Welcome to JShell -- Version 20.0.1
> | ?For an introduction type: /help intro
>
> jshell> Class.forName("test.Foo");
> $1 ==> class test.Foo
>
> If you are running in a non-trivial class loader environment (e.g., 
> Tomcat), using JVM flags is not feasible and so your application 
> classes can never be found in JShell.
>
> *Question*: Shouldn't DefaultLoaderDelegate$RemoteClassLoaderuse the 
> current thread's context loader as its parent loader instead of 
> defaulting to the system class loader?


If that was done from the beginning, maybe. Now, probably not, as that 
would be an incompatible change. Should be possible to have a custom 
ExecutionControl (an instance of or subtype of LocalExecutionControl), 
with custom LoaderDelegate (where, possibly, there could be a factory 
for DefaultLoaderDelegate taking a custom ClassLoader). Does not seem 
this should be very too difficult?


(I am a bit confused about the command line example - at least the 
"agent" (i.e. the DirectExecutionControl/LocalExecutionControl) must run 
inside your target VM.)


>
> #3: Solving problem #2 would allow the execution class path to be 
> properly configuredin any generic situation (that is,from the context 
> class loader). But we have the same problem for the compilation class 
> path - so the corresponding question is: given a class loader, how do 
> you extract the classpath that it's using?
>
> This is easy if the class loader is an URLClassLoader, which most are. 
> Unfortunately the system class loader is not.
>
> *Question*: Should JShell provide a way to "best effort" extract a 
> compilation class path from a given ClassLoader (and its parents)? It 
> could work for any URLClassLoader instances, but being part of the JDK 
> it could also take advantage of inter-module access to the system and 
> other built-in class loaders, which are all of type 
> jdk.internal.loader.BuiltinClassLoader, which has an internal 
> URLClassPath field.


Sorry, I don't think so. There has been some thinking some time ago on 
supporting compilation based on ClassLoaders, but it is fairly tricky, 
and very easy. Having heuristics inside JShell to read some data from 
some ClassLoaders does not sounds like a very good idea to me, sorry.


Jan


>
> Or fix this in the JDK by defining some new interface that both 
> URLClassLoader and BuiltinClassLoadercould implement:
>
> public interface HasUrlPath {
> ??? URL[] getURLs();
> }
>
> Or: create a JavaFileManager implementation that wraps a ClassLoader 
> (it's been done), and modify JShell to allow configuration of an 
> alternate JavaFileManager (we can already do with JShell.Builder but 
> not yet with JavaShellToolBuilder... why not?).
>
> Thanks for any thoughts & opinions on these questions.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230815/66485dfa/attachment.htm>

From archie.cobbs at gmail.com  Tue Aug 15 14:41:51 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 15 Aug 2023 09:41:51 -0500
Subject: Local execution - class loader & class path issues
In-Reply-To: <b50f1502-1568-4ffe-920e-c5715935951f@oracle.com>
References: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>
 <b50f1502-1568-4ffe-920e-c5715935951f@oracle.com>
Message-ID: <CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com>

Hi Jan,

Thanks for taking a look.

On Tue, Aug 15, 2023 at 8:12?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

>
> *Question*: Shouldn't LoaderDelegate.addToClasspath() have been passed
> the --class-path flag at some point in the example above? JShell's L
> ocalExecutionControl uses DefaultLoaderDelegate, which uses a class
> loader of type DefaultLoaderDelegate.RemoteClassLoader. This would have
> added classes to RemoteClassLoader's class path.
>
> Possibly.
>
Thanks for the mild endorsement :) If you don't object I may file a bug for
this.


>
> *Question*: Shouldn't DefaultLoaderDelegate$RemoteClassLoader use the
> current thread's context loader as its parent loader instead of defaulting
> to the system class loader?
>
> If that was done from the beginning, maybe. Now, probably not, as that
> would be an incompatible change. Should be possible to have a custom
> ExecutionControl (an instance of or subtype of LocalExecutionControl), with
> custom LoaderDelegate (where, possibly, there could be a factory for
> DefaultLoaderDelegate taking a custom ClassLoader). Does not seem this
> should be very too difficult?
>
Yes, it's not too difficult and I've already done it (link
<https://github.com/archiecobbs/java-console-toolkit/blob/main/jshell/src/main/java/org/dellroad/jct/jshell/LocalContextExecutionControlProvider.java>)
but it's still an annoying hassle...

But I think we can get the best of both worlds, by adding a new parameter
that LocalExecutionControlProvider would accept, e.g.
contextLoaderParent=true. This would obviate the need for writing custom a
ExecutionControl but also not change the current behavior. Do you see any
issue with this idea?

(I am a bit confused about the command line example - at least the "agent"
> (i.e. the DirectExecutionControl/LocalExecutionControl) must run inside
> your target VM.)
>
I was probably unclear. My point is that, if we're just looking at the
available JShell flags and parameters, you have zero control over the
execution class path when using local execution. The only control available
at all is the JVM classpath setting, which is what that example shows.

This is just a restatement of problem #1, i.e., the --class-path flag is
effectively broken when using local execution, because it affects only the
compilation class path, and not the execution class path.


>
> *Question*: Should JShell provide a way to "best effort" extract a
> compilation class path from a given ClassLoader (and its parents)? It could
> work for any URLClassLoader instances, but being part of the JDK it could
> also take advantage of inter-module access to the system and other built-in
> class loaders, which are all of type
> jdk.internal.loader.BuiltinClassLoader, which has an internal URLClassPath
> field.
>
> Sorry, I don't think so. There has been some thinking some time ago on
> supporting compilation based on ClassLoaders, but it is fairly tricky, and
> very easy.
>
I assume you meant "not very easy" there...

I'm curious to learn more.  Do you recall the upshot of that thinking? Does
it "work"? If not, what are the limitations?

> Having heuristics inside JShell to read some data from some ClassLoaders
> does not sounds like a very good idea to me, sorry.
>
I have to agree. This would be gross/hacky and I don't really like it
either (even though this is the workaround I'm currently being forced to
use).

For the sake of argument, suppose we found a reliable way to make a
ClassLoader look like a JavaFileManager. Then all that would be missing is
a way to configure it in the JavaShellToolBuilder.

Is there any particular reason why JavaShellToolBuilder couldn't have a
fileManager() method like JShell.Builder does?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230815/bad88fbc/attachment-0001.htm>

From jan.lahoda at oracle.com  Tue Aug 15 15:09:48 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 15 Aug 2023 17:09:48 +0200
Subject: [External] : Re: Local execution - class loader & class path
 issues
In-Reply-To: <CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com>
References: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>
 <b50f1502-1568-4ffe-920e-c5715935951f@oracle.com>
 <CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com>
Message-ID: <65bf0b68-11a1-4ea9-ade9-fe91ffb94bab@oracle.com>

On 15. 08. 23 16:41, Archie Cobbs wrote:

> Hi Jan,
>
> Thanks for taking a look.
>
> On Tue, Aug 15, 2023 at 8:12?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>
>>     *Question*: Shouldn't LoaderDelegate.addToClasspath() have been
>>     passed the --class-path flag at some point in the example above?
>>     JShell's LocalExecutionControl uses DefaultLoaderDelegate, which
>>     uses a class loader of type
>>     DefaultLoaderDelegate.RemoteClassLoader. This would have added
>>     classes to RemoteClassLoader's class path.
>
>     Possibly.
>
> Thanks for the mild endorsement :) If you don't object I may file a 
> bug for this.


Sure, please do!


>
>>     *Question*: Shouldn't DefaultLoaderDelegate$RemoteClassLoaderuse
>>     the current thread's context loader as its parent loader instead
>>     of defaulting to the system class loader?
>
>     If that was done from the beginning, maybe. Now, probably not, as
>     that would be an incompatible change. Should be possible to have a
>     custom ExecutionControl (an instance of or subtype of
>     LocalExecutionControl), with custom LoaderDelegate (where,
>     possibly, there could be a factory for DefaultLoaderDelegate
>     taking a custom ClassLoader). Does not seem this should be very
>     too difficult?
>
> Yes, it's not too difficult and I've already done it (link 
> <https://urldefense.com/v3/__https://github.com/archiecobbs/java-console-toolkit/blob/main/jshell/src/main/java/org/dellroad/jct/jshell/LocalContextExecutionControlProvider.java__;!!ACWV5N9M2RV99hQ!NLf38Yz7eZhnS-RW-sdl_Rq5zTa9_4oYqZrKGZEtJm0olgVuLNX3UGDo22Xtt2e0Fdi3pvudhaBLhh6m8YjX7jY$>) 
> but it's still an annoying hassle...
>
> But I think we can get the best of both worlds, by adding a new 
> parameter that LocalExecutionControlProvider would accept, e.g. 
> contextLoaderParent=true. This would obviate the need for writing 
> custom a ExecutionControl but also not change the current behavior. Do 
> you see any issue with this idea?


If a new constructor for LocalExecutionControlProvider taking (probably) 
the ClassLoader would work, that would be a very good solution, I think.


>
>     (I am a bit confused about the command line example - at least the
>     "agent" (i.e. the DirectExecutionControl/LocalExecutionControl)
>     must run inside your target VM.)
>
> I was probably unclear. My point is that, if we're just looking at the 
> available JShell flags and parameters, you have zero control over the 
> execution class path when using local execution. The only control 
> available at all is the JVM classpath setting, which is what that 
> example shows.
>
> This is just a restatement of problem #1, i.e., the --class-path flag 
> is effectively broken when using local execution, because it affects 
> only the compilation class path, and not the execution class path.
>
>
>>     *Question*: Should JShell provide a way to "best effort" extract
>>     a compilation class path from a given ClassLoader (and its
>>     parents)? It could work for any URLClassLoader instances, but
>>     being part of the JDK it could also take advantage of
>>     inter-module access to the system and other built-in class
>>     loaders, which are all of type
>>     jdk.internal.loader.BuiltinClassLoader, which has an internal
>>     URLClassPath field.
>
>     Sorry, I don't think so. There has been some thinking some time
>     ago on supporting compilation based on ClassLoaders, but it is
>     fairly tricky, and very easy.
>
> I assume you meant "not very easy" there...


Yes, sorry.


>
> I'm curious to learn more.? Do you recall the upshot of that thinking? 
> Does it "work"? If not, what are the limitations?


Generally, as far as I know, ClassLoaders can load a resource/class 
given a name, but cannot provide a list of things under a 
directory/package. This causes two problems, IIRC:

- given a file containing only:

import does.not.exist.*;

I believe the specification says there should be an error for this 
import - but for that, we would need to know if there's a class (or 
possibly source) file under 'does.not.exist' or not. (There are some 
similar constrains on exports and esp. opens, but those are not relevant 
to JShell.)

- when the code contains something like "java.util.List", javac won't 
try to load "java.util.List". It will rather list the content of the 
whole "java.util" package, and look if there's a "List.class" (or alike) 
inside. If I remember correctly from the time I was experimenting with 
this, it is probably not impossible to change, but not easy, and 
consequences are not completely clear.


Jan


>     Having heuristics inside JShell to read some data from some
>     ClassLoaders does not sounds like a very good idea to me, sorry.
>
> I have to agree. This would be gross/hacky and I don't really like it 
> either (even though this is the workaround I'm currently being forced 
> to use).
>
> For the sake of argument, suppose we found a reliable way to make a 
> ClassLoader look like a JavaFileManager. Then all that would be 
> missing is a way to configure it in the JavaShellToolBuilder.
>
> Is there any particular reason why JavaShellToolBuilder couldn't have 
> a fileManager() method like JShell.Builder does?
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230815/34425b0b/attachment.htm>

From acobbs at openjdk.org  Wed Aug 16 15:03:37 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 16 Aug 2023 15:03:37 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution engine
Message-ID: <JToy_lkQYUrC2Sc_fIj4Ms71103ThNycx2IDdV2KBIU=.c32cf606-103c-4ca2-8f58-6947b3514c33@github.com>

There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.

**Background**

JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.

For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.

Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).

**Issue 1**

The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.

**Issue 2**

JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".

However, the "local" execution engine ignores the remote VM options.

Here's a simple demonstration:


    $ ls classes/test/Foo.class
    classes/test/Foo.class
    $ jshell --execution=local --class-path classes
    |  Welcome to JShell -- Version 20.0.1
    |  For an introduction type: /help intro

    jshell> Class.forName("test.Foo");
    |  Exception java.lang.ClassNotFoundException: test.Foo
    |        at URLClassLoader.findClass (URLClassLoader.java:445)
    |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
    |        at ClassLoader.loadClass (ClassLoader.java:588)
    |        at ClassLoader.loadClass (ClassLoader.java:521)
    |        at Class.forName0 (Native Method)
    |        at Class.forName (Class.java:391)
    |        at Class.forName (Class.java:382)
    |        at (#1:1)

    jshell> Thread.currentThread().getContextClassLoader();
    $2 ==> jdk.jshell.execution.DefaultLoaderDelegate$RemoteClassLoader at 45283ce2

    jshell> Arrays.asList(((URLClassLoader)$2).getURLs())
    $3 ==> []

    jshell> new File("classes/test/Foo.class").exists()
    $4 ==> true


**Issue 3**

JShell defines a `LoaderDelegate` interface, and provides a perfectly reasonable default implementation in `DefaultLoaderDelegate`, but makes it impossible for anyone wishing to customize `LocalExecutionControl` to leverage any of the existing `DefaultLoaderDelegate` implementation, because the class is not public. Also, this class is non-trivial and so duplicating its tricky class loading function is tedious and error-prone.

There's no reason not to make `DefaultLoaderDelegate` a public class, because (a) it adds no API surface beyond what is already defined by the already-public `LoaderDelegate` interface, and (b) its current behavior is already being relied upon (it's always used), so by making it public no additional dependencies or expectations would be created beyond those that already exist.

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

Commit messages:
 - Make the DefaultLoaderDelegate class public.
 - Apply the "--class-path" flag to the "local" execution engine.
 - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
 - Allow specifying a parent class loader when creating a LocalExecutionControl.
 - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.

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

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

From archie.cobbs at gmail.com  Fri Aug 18 22:12:03 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 18 Aug 2023 17:12:03 -0500
Subject: [External] : Re: Local execution - class loader & class path
 issues
In-Reply-To: <65bf0b68-11a1-4ea9-ade9-fe91ffb94bab@oracle.com>
References: <CANSoFxs2W_Lq=Gqnvr8qxRJGQgnwSY96S59TtPpe3mM-=4CxXg@mail.gmail.com>
 <b50f1502-1568-4ffe-920e-c5715935951f@oracle.com>
 <CANSoFxtRzHvv1M8+XWL9i4gxy=UceRP8RaN_reqdUpvrQcY-wg@mail.gmail.com>
 <65bf0b68-11a1-4ea9-ade9-fe91ffb94bab@oracle.com>
Message-ID: <CANSoFxukeX8-JB=GhObS8hE+wMYKkty3HQ_n2wj0He5AXR_VGQ@mail.gmail.com>

On Tue, Aug 15, 2023 at 10:10?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> On 15. 08. 23 16:41, Archie Cobbs wrote:
>
> On Tue, Aug 15, 2023 at 8:12?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>>
>> *Question*: Shouldn't LoaderDelegate.addToClasspath() have been passed
>> the --class-path flag at some point in the example above? JShell's L
>> ocalExecutionControl uses DefaultLoaderDelegate, which uses a class
>> loader of type DefaultLoaderDelegate.RemoteClassLoader. This would have
>> added classes to RemoteClassLoader's class path.
>>
>> Possibly.
>>
> Thanks for the mild endorsement :) If you don't object I may file a bug
> for this.
>
> Sure, please do!
>

I've filed a bug <https://bugs.openjdk.org/browse/JDK-8314327> and
submitted a PR <https://github.com/openjdk/jdk/pull/15311> for this and a
couple of related issues.

Hopefully these are reasonable improvements - I'm of course interested in
any feedback.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230818/2605007b/attachment.htm>

From jwaters at openjdk.org  Tue Aug 22 03:09:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Aug 2023 03:09:41 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Is this all clear for sponsorship?

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687346705

From liach at openjdk.org  Tue Aug 22 03:56:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Aug 2023 03:56:35 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <AlfAhdlX5b-OhYqIu32-eSo1Eb_cIgbMSmciYIwR2_U=.3300557b-3b88-4eca-b0e4-fa4b4e01ffba@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Just curious, is it worth adding a test case where we call `super` multiple times or in a control flow, like

public Example() {
    if (Utilities.condition()) super();
    super();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687376391

From jwaters at openjdk.org  Tue Aug 22 04:02:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Aug 2023 04:02:46 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <6FRBjtyvfrUiQsRH4YUytfoCbCxHA-YY4yE-rqU0KT8=.707755ee-fb8e-436a-b13e-5eb1f7721c55@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Marked as reviewed by jwaters (Committer).

Approving in good spirit, but will not sponsor until I get the green light

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

PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1588233521
PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1687380426

From acobbs at openjdk.org  Tue Aug 22 14:08:18 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 22 Aug 2023 14:08:18 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
 <dfLWo5rApcH_80dR15-QjtJHt_oXIpvuyOimzezdgDs=.0ff3dd7c-8582-4546-9e55-90d164bb6792@github.com>
Message-ID: <ad5M707wv34gnLbS7LnkK04nK9NqLKakGLuiexmWyJo=.ad191f99-5325-432e-a2b8-acff211bbf27@github.com>

On Tue, 22 Aug 2023 03:06:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is this all clear for sponsorship?

Not sure if you're asking me or not, but from my perspective, yes - at least technically speaking.

> Just curious, is it worth adding a test case where we call super multiple times or in a control flow

Happy to add it if you like. That example fails two of the checks [here](https://github.com/archiecobbs/jdk/blob/e2f881373e8e01309b8d34802b4d13b4b8bf9efe/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java#L4043): (a) all `super()` invocations must be "top level", and (b) there can only be one `super()` statement.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1688213639

From jlahoda at openjdk.org  Wed Aug 30 11:00:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Aug 2023 11:00:38 GMT
Subject: RFR: 8314662: jshell shows duplicated signatures of javap
Message-ID: <bzZuccjCizCCiHXI4YD6jJqwdTrLLerQIuJawWstaQQ=.648e1d78-62fb-4379-9ceb-763f9a57f43d@github.com>

The Scope may contain duplicated entries (e.g. for duplicated static imports, as in this case), which may then show as duplicate signatures in JShell.

The proposal here is to avoid using the duplicates, by using `LinkedHashSet`.

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

Commit messages:
 - 8314662: jshell shows duplicated signatures of javap

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

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

From asotona at openjdk.org  Wed Aug 30 11:24:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 30 Aug 2023 11:24:10 GMT
Subject: RFR: 8314662: jshell shows duplicated signatures of javap
In-Reply-To: <bzZuccjCizCCiHXI4YD6jJqwdTrLLerQIuJawWstaQQ=.648e1d78-62fb-4379-9ceb-763f9a57f43d@github.com>
References: <bzZuccjCizCCiHXI4YD6jJqwdTrLLerQIuJawWstaQQ=.648e1d78-62fb-4379-9ceb-763f9a57f43d@github.com>
Message-ID: <JIu7XbcF2eoKMrrD-zyPOlYJ48UVmMKwv4tiH71tzyQ=.ac9f9067-edee-4e33-96fa-a45a1b9c4f8e@github.com>

On Wed, 30 Aug 2023 10:53:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The Scope may contain duplicated entries (e.g. for duplicated static imports, as in this case), which may then show as duplicate signatures in JShell.
> 
> The proposal here is to avoid using the duplicates, by using `LinkedHashSet`.

It looks good

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15489#pullrequestreview-1602477571

From cstein at openjdk.org  Wed Aug 30 11:30:12 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 30 Aug 2023 11:30:12 GMT
Subject: RFR: 8314662: jshell shows duplicated signatures of javap
In-Reply-To: <bzZuccjCizCCiHXI4YD6jJqwdTrLLerQIuJawWstaQQ=.648e1d78-62fb-4379-9ceb-763f9a57f43d@github.com>
References: <bzZuccjCizCCiHXI4YD6jJqwdTrLLerQIuJawWstaQQ=.648e1d78-62fb-4379-9ceb-763f9a57f43d@github.com>
Message-ID: <bAFnU1ERwX0boxZHvgiCGuKRSURu8uCnPrPCvQSmxds=.09902fb7-65b4-49ad-b70b-5b885f99d552@github.com>

On Wed, 30 Aug 2023 10:53:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The Scope may contain duplicated entries (e.g. for duplicated static imports, as in this case), which may then show as duplicate signatures in JShell.
> 
> The proposal here is to avoid using the duplicates, by using `LinkedHashSet`.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/15489#pullrequestreview-1602486587